If the testing team is habitual of doing testing measurements at the end of the testing

life cycle, what major benefits they can have for future testing?
Ans:

Defect Analysis
Defect? Any test case that is failed, will be a defect.
Defect Analysis?.... There are several parameters to analyze defects.
Need for Defect Analysis....... Able to measure the quality of the application. Able
to measure work(team) quality.

Defect Metrics play an important role in defect analysis.

The application/Areas where we expect Zero Defects?
Answer: Financial Applications, Medical Science, Constructions Applications,
Aviation

Defect Analysis- Goals & Objectives

Why we do this? Defect sy related hum 3 chezein krna chahty hain,
1. Detection, defects jaldi detect ho jayein
2. Removal, defects jaldi remove ho jayein nikal jaye
3. Prevention, mtlb defects ayein hee naa... do not occur next time

High-Level Goals: we will achieve.....

1. Prevention from future occurrences of defects.
2. Defect Detection & Removal Process Improvement

Defect Analysis.....Preparation
Defect analysis krny k liye humaray pass kya chezein honi chahiye....

Phase 1. Collection of defects ( Reports and record/databases...from where we

can collect defects ) You can save the collection in these forms (DB, Excel, File)
 What we need to collect about defects
a. Defect type
b. Defect injection Point ( Kis point pr ye defect application mein inject huwa
hai, e.g. requirement gathering/desing/coding/planning/testing etc..)
c. Defect detection point (Normally it is detected at testing phase, Or at
Review time)
d. Methods used for detection (test/review) humara method konsa tha
detection krny ka
e. Impact of defect Correction on cost/schedule (e.g time zyda lga team
ka...cost increase hoi etc..)
f. Impact of defect Detection on cost/schedule
g. Defect Frequency (how many times the defect occur)

Phase 2. Remove Duplications

In this phase, we remove the duplications, like the same defects written two
times.

Defect Analysis- Analysis Technique

1. Pareto Chart: It indicates the frequency of defects and their cumulative impact.
Pareto chart used to prioritize defects to observe the improvement
Pareto chart use 80-20 rule (Pareto Principle) 20% inputs dy k 80% output hasil kr
skty hain , In contrast to this, 20% problems create 80% issues.
(According to Defects: 80% issues are present just because of 20% minor causes)
OR ( Only 20% defects/causes can create 80% problems)
If we solve those 20% root causes/defects, then we can overcome our 80% of
problems

2. Cause and Effect Analysis OR Fish Bone Analysis

It was devised by professor Kaoru Ishikawa, in the 1960s. This technique was
published in his book 1990 (Introduction to Quality Control)
Use it to;
Discover the root causes of Problem
Uncover bottlenecks in your processes
Identify where and why a process isn't working

Diagram: For understanding

In Diagram of Fish [ Most right Head, we put Defect, other body (Bones) will show
reasons and causes]

3. Simple Graph or Histogram

Plot defects on a graph according to injection points

x-axis > Injection Points

y-axis > No. of Defects

Different injection points (Requirement gathering,design, coding etc)...hume curve sy

pta chly ga kis injection point pr zyda defects aye....

[Advantage of Fish Bone Analysis before Pareto chart is, we can get Root Causes, it
will be helpful]

### Explore more analysis techniques at least 2 per student (Assignment given as
Self Study)
Test Driven Development - Refactoring

Refactor krny ka mtlb ap ny apny code ke quality ko improve kia hai design ko
improve kr k.....lkn apko Frontend mein koi khas change ni ati...
For example; Cohesion, coupling kamm ke hai...inheritence kr di hai...function ko
split kr dia etc,.....(Internal code/design ko improve kia ) outer koi change ni ati

Code ka Internal design/internal logic change krty hain...outer interface/functionality

pe koi impact Naa aye
Refactoring mein hum design level pr jo changes krty hain,..E.g cohesion,coupling,
splitting of function, unnecessary code lines ko remove krna...code efficient hojata
hai refactoring sy

Test Driven Development is like SDLC

It is Development Process

First we design Unit Test => Coding and then Refactoring

Procedure:
1. Write/design test case (automated)
2. Write some code
3. Run tests
4. Refactor Code
5. Repeat

Jo test case fail hoty...phir hum refactoring krty hain...dubara sy use cases likhty
hain...
Test Driven Development (TTD) is a programming practice that starts with the design
and development of tests for every function of a program.
This way you are forced to think about the specifications, requirements, or design
before you start writing code.
In other words, you write code to test your code before you write any code.

Jo test case fail huwe ..os code ko refactor kr lia...when you have done with
refactoring...and completed your code..then included in Final Build.

Test Driven Development Benefits

1. Forces you to think about the problem you're trying to solve before you start typing
code with no direction.
2. In the particular case of class-based OOP, it helps you to understand the contract
each class has. What were their responsibilities? What did they have to know?
This becomes even more relevant when you're aiming for low coupling and high
cohesion.
(TTD krny mein ap pehly he coupling or cohesion k baray mein sochna shru kr dety
hain ...)
3. Even though it might slow you down at first, in the long-run it saves your time by
minimizing the time spend debugging.
4. It encourages better desing, making code easier to maintain, less redundant (keep
it DRY), safe to refactor when needed.
5. It serves as living documentation-Just by looking at the tests, you can understand
what each unit should do, making code self-explanatory.
## TTD focus on unit-level....unit level test cases....Automated hoty hain,.... Its only
deal with Coding/Programming NOT OUTER INTERFACE
Unit Tests properly documented

Test Driven Development Vs Testing Phase

Differences .....OR....Similarities
Similarities...
Dono kaam Bugs/Defects ko find krna hai...
Dono mein he Autmated testing kr skty hain
Dono mein test desing hoty hain.....

Differences
Normal testing Phase mein hum aisy test case likhty jo functionality pr zyda focus kr
rhy hoty hain...Validity or invalidity
Interface pr focus krty hain...

Jab k TTD mein Developer unit test case bna rha for particular piece of code...

Test Driven Development Levels

1) Acceptance TTD
Write a single acceptance test. Application is developed as per the test. In case the
test case fails..refactoring is done to pass the test case.
ATDD focuses on the behavior of application. (MCQs) Ans: Behavior of Application

2) Developer TDD
Developer writes a unit test first of all. Then writes the code or program to fulfill the
requirement of that unit test.

Test Driven Development Overall Advantages

1. Early bug detection
2. Better Desing, Cleaner Code
3. Improve developer's Capability of Refactoring

Why TTD different from other developments?

Answer: Its because other development’s focus point is whole application. ( pori
application k test case bna rhy hoty..desing krty hain)
While in TTD developer focus point fixed only on one code. (When your focus is
limited, you can think how much it will be good to desing/code) TTD focus
individually...