UNIT-IV

By K . S h e ka r
A s s i sta nt p ro fe s s o r
D e p a r t m e nt : C S E

Ms V.Hema 1
 Topics:

Test Selection & Minimization for Regression

Testing, Regression Test process, Initial
Smoke or Sanity test, Selection of regression
tests, Execution Trace, Dynamic Slicing, Test
Minimization, Tools for regression testing, Ad
hoc Testing: Pair testing, Exploratory testing,
Iterative testing, Defect seeding.

Ms V.Hema 2
LECTURE-30
23-12-2020

Ms V.Hema 3
 Test Selection & Minimization
for Regression Testing
Software maintenance is an activity which includes
enhancements, error corrections, optimization and deletion of
existing features.

These modifications may cause the system to work

incorrectly.

Therefore Regression testing becomes necessary.

Regression testing can be carried out using following

techniques.

Ms V.Hema 4
Test Selection & Minimization for
Regression Testing

Ms V.Hema 5
Retest all: This is one of the methods for regression
testing in which all the tests in the existing test bucket
or test suite should be re-executed.

•This is very expensive as it requires huge time and

resources.

Ms V.Hema 6
•Regression Test Selection is a technique in which some
selected test cases from test suite are executed to test
whether the modified code affects the software application or
not.

Instead of re-executing the entire test suite, it is better to

select part of test suite to be run.

 Test cases selection can be categorized as 1) Reusable

test cases 2) Obsolete test cases.

 Reusable test cases can be used in succeeding regression

cycles. Obsolete test cases can’t be used in succeeding
cycles.

Ms V.Hema 7
Selecting the Test Case for regression testing is an art and not
that easy. Effective Regression Tests can be done by selecting the
following test cases -
a) Test cases which have frequent defects.
b) Functionalities which are more visible to the users.
c) Test cases which verify core features of the product.
d) Test cases of functionalities which has undergone more and
recent changes.
e) All Integration Test Cases.
f) All Complex Test Cases.
g) Boundary value test cases.
h) A sample of Successful test cases.
i) A sample of Failure test cases.

Ms V.Hema 8
Tips for selection of test cases:
1. Select test cases for Regression testing where there are recent
code changes or functional changes.
2. Select test cases that map to the business requirements.
3. Select test cases for Regression testing in areas with frequent
bugs/defects.
4. Select test cases for Regression testing of the areas which are
visible to the user.
5. Select all integration test cases for Regression testing.
6. Select all complex test cases for Regression testing.
7. Select test cases based on priorities for Regression testing.
8. Select test cases for Regression testing based on criticality and
impact of bug fixes.
9. Select a sample of successful and failed test cases for
Regression testing.

Ms V.Hema 9
Prioritization of Test Cases:

Prioritize the test cases depending on business impact, critical

and frequently used functionalities. Selection of test cases
based on priority will greatly reduce the regression test suite.

Ms V.Hema 10
LECTURE-31
23-12-2020

Ms V.Hema 11
 Regression Testing
REGRESSION TESTING is defined as a type of software
testing to confirm that a recent program or code
change has not adversely affected existing features.
This testing is done to make sure that new code changes should
not have side effects on the existing functionalities.

It ensures that the old code still works once the latest code
changes are done.

Also ensures that enhancements or defect fixes made to the

software works properly and does not affect the existing
functionality.

Ms V.Hema 12
.

Ms V.Hema 13
 Regression Testing(Continue)

In other words:
It is important to ensure that

1. The changes or additions work as designed,

and

2. The changes or additions do not break

something that is already working and should
continue to work.

Ms V.Hema 14
 Regression Testing(Continue)
Regression testing follows selective re-testing
technique.

Re-testing: Retesting is testing of a particular bug after it

has been fixed.

•Usually tester raises the bug when they find it while

testing the product or its component.

•This bug is assigned to a developer and he fixes it. Post

fixing the bug is assigned to the tester for its verification.
This testing is known as retesting.
Ms V.Hema 15
Ms V.Hema 16
 Regression vs. Re-testing
Regression testing is performed for passed test cases
while Retesting is done only for failed test cases.

Regression testing checks for unexpected side-

effects while Re-testing makes sure that the original
fault has been corrected.
“Retesting means testing the functionality or bug again to
ensure the code is fixed. If it is not fixed, Defect needs to be
re-opened. If fixed, Defect is closed.
Regression testing means testing your software application
when it undergoes a code change to ensure that the new
code has not affected other parts of the software.”

Ms V.Hema 17
Ms V.Hema 18
Types:

1. Regular regression testing: Is done between test cycles to

ensure that the defect fixes are done and the functionality that
were working with the earlier test cycles continue to work.

2. Final regression testing: Is done to validate the final build

before release.

Ms V.Hema 19
Test-Automation:

An effective regression strategy, saves organization’s both time and

money. But in current time it more refers to the term Automate,
Automate, Automate.

Following are some automation tools:

 Quick test professional

 Rational functional tester

 Selenium

Ms V.Hema 20
LECTURE-32
28-12-2020

Ms V.Hema 21
Regression Test Process

Ms V.Hema 22
Process of Regression testing: (Continues)

•Firstly, whenever we make some changes to the

source code for any reasons like adding new
functionality, optimization, etc.

•Then our program when executed fails in the

previously designed test suite for obvious reasons.

•After the failure, the source code is debugged in order

to identify the bugs in the program.

Ms V.Hema 23
Process of Regression testing:

•After identification of the bugs in the source code,

appropriate modifications are made.

•Then appropriate test cases are selected from the

already existing test suite which covers all the modified
and affected parts of the source code.

• We can add new test cases if required.

•In the end regression testing is performed using the

selected test cases.

Ms V.Hema 24
LECTURE-33
29-12-2020

Ms V.Hema 25
 Initial Smoke or Sanity test
SMOKE TESTING, also known as “Build
Verification Testing”.

 Is a type of software testing that comprises of a

non-exhaustive set of tests that aim at ensuring that
the most important functions work.

The result of this testing is used to decide if a build is

stable enough to proceed with further testing.

Ms V.Hema 26
Smoke Testing
Smoke Testing is a software testing technique
performed post software build to verify that the critical
functionalities of software are working fine.

It is executed before any detailed functional or

regression tests are executed.

The main purpose of smoke testing is to reject a

software application with defects so that QA team does
not waste time testing broken software application.

Ms V.Hema 27
Smoke Testing:

Ms V.Hema 28
Advantages of Smoke Testing:
It helps to find faults earlier in the product lifecycle.
It saves the testers time by avoiding testing an unstable or
wrong build.
It provides confidence to the tester to proceed with testing.
It helps to find integration issues faster.
Major severity defects can be found out.
Detection and rectification will be an easy process.
The unstable build is a ticking time bomb. Smoke Testing
diffuses it.
Can be executed within a few minutes.
Since execution happens quickly, there will be a faster
feedback.
Security, privacy policy, performance, etc. can also be tested.

Ms V.Hema 29
 Sanity Testing
Sanity Testing is a subset of regression testing.

Sanity testing is performed to ensure that the code changes

that are made are working as properly.

Sanity testing is a stoppage to check whether testing for the

build can proceed or not.

The focus of the team during sanity testing process is to

validate the functionality of the application and not detailed
testing.

Sanity testing is generally performed on build where the

production deployment is required immediately like a critical
bug fix.

Ms V.Hema 30
Ms V.Hema 31
Functionality of Sanity Testing:

The major functionality of sanity testing is to determine

that the changes or the proposed functionality are working as
expected.

If the sanity test fails, software product is rejected by the

testing team to save time and money.

It is performed only after the software product has passed

the smoke test and Quality Assurance team has accepted for
further testing.

Ms V.Hema 32
Features of Sanity Testing:

Subset of Regression Testing:

Sanity testing is a subset of regression testing and focuses on the
smaller section of the application.
Unscripted:
Most of the times sanity testing is not scripted.
Not documented:
Usually sanity testing is undocumented.
Narrow and deep:
Sanity testing is narrow and deep approach of testing where limited
functionalities are covered deeply.
Performed by testers:
Sanity testing is normally performed by testers.

Ms V.Hema 33
Advantages of Sanity Testing:

Sanity testing helps in quickly identify defects in the core

functionality.

It can be carried out in lesser time as no documentation

is required for sanity testing.

If the defects are found during sanity testing, project is

rejected that is helpful in saving time for execution of
regression tests.

Ms V.Hema 34
Smoke Vs Sanity Testing

Ms V.Hema 35
Smoke Vs Sanity Testing

Ms V.Hema 36
 Smoke Vs Sanity Testing-Differences
Smoke Testing Sanity Testing
Smoke Testing is performed to ascertain that the Sanity Testing is done to check the new
critical functionalities of the program is working functionality/bugs have been fixed
fine

The objective of this testing is to verify the The objective of the testing is to verify the
"stability" of the system in order to proceed with "rationality" of the system in order to proceed
more rigorous testing with more rigorous testing

This testing is performed by the developers or Sanity testing is usually performed by testers
testers
Smoke testing is usually documented or scripted Sanity testing is usually not documented and is
unscripted
Smoke testing is a subset of Acceptance testing Sanity testing is a subset of Regression Testing

Smoke testing exercises the entire system from Sanity testing exercises only the particular
end to end component of the entire system

Smoke testing is like General Health Check Up Sanity Testing is like specialized health check up

Ms V.Hema 37
LECTURE-34
29-12-2020

Ms V.Hema 38
 Selection of Regression Tests
1. Select test cases for Regression testing where there are recent
code changes or functional changes.
2. Select test cases that map to the business requirements .
3. Select test cases for Regression testing in areas with frequent
bugs/defects.
4. Select test cases for Regression testing of the areas which are
visible to the user.
5. Select all integration test cases for Regression testing.
6. Select all complex test cases for Regression testing.
7. Select test cases based on priorities for Regression testing.
8. Select test cases for Regression testing based on criticality and
impact of bug fixes.
9. Select a sample of successful and failed test cases for
Regression testing

Ms V.Hema 39
LECTURE-35
29-12-2020

Ms V.Hema 40
 Execution Trace
“The execution traces present the order of the statements that
are touched during the execution of the test cases.”

It is a technique used for selection of test cases.

Procedure:
P-Program containing some functions.
P’- Added few more functionalities to the existing program.
T- Test cases (Performed to test the original program).

Goal is to test P’ to ensure that the changes made do not affect the
functionality carried over P.
This could be achieved by executing P’ against all the non-obsolete
tests in T.

Ms V.Hema 41
Obsolete & Non-Obsolete Tests:

Ms V.Hema 42
 Obsolete & Non-Obsolete Tests:
Tests(T)=To(Obsolete Tests)+Tu(Reduntant Tests)+Tr(Regression
tests).
Tno= (Tu U Tr)
We want to tested only those that are necessary to check if the modifications
do not affect functionalities common to P & P’.

Check each and every test against the P’.

This technique can be split into two Phases.

Phase-I: P is executed and the execution slice recorded for each test case
in Tno= (Tu U Tr)
(Finding out the Tno and executing them on the program P and finding out the
trace.)
Phase-II: The modified program P’ is compared with P and Tr by an analysis
of the execution slice obtained in the first phase.

Ms V.Hema 43
LECTURE-36
29-12-2020

Ms V.Hema 44
 Dynamic Slicing
Slicing: Program slicing is a technique for simplifying programs by
focusing on selected aspects of semantics.

Slicing or program slicing is a technique used in software testing

which takes a slice or a group of program statements in the
program for testing particular test conditions or cases and that
may affect a value at a particular point of interest.
 It can also be used for the purpose of debugging in order to find
the bugs more easily and quickly.

2 Types:

Static slicing

Dynamic slicing
Ms V.Hema 45
1. Static Slicing:

A static slice of a program contains all statements that may affect the
value of a variable at any point for any arbitrary execution of the program.
Static slices are generally larger.

•It considers every possible execution of the program.

2. Dynamic slicing:

A dynamic slice of a program contains all the statements that actually

affect the value of a variable at any point for a particular execution of the
program.

•Dynamic slices are generally smaller.

•Considers only a particular execution of the program.

Ms V.Hema 46
 Example:
int z = 10;
int n;
cin >> n;
int sum = 0;
if (n > 10)
sum = sum + n;
else
sum = sum - n;
cout << "Hey";
Static Slicing: Dynamic Slicing:
int n; int n;
cin >> n; cin >> n;
int sum = 0; int sum = 0;
if (n > 10) if (n > 10)
sum = sum + n; sum = sum + n;
else
sum = sum - n;
Ms V.Hema 47
 Example (Cont):

As it can be observed in the above example that static slice

takes all the possible execution (in this case it is 2) of the
program which may affect the value of the variable sum.

Whereas in case of dynamic slicing, it considers only a

particular execution of the program which may affect the value
of the variable sum.

Hence, dynamic slice is always smaller than a static slice.

Ms V.Hema 48
LECTURE-37
30-12-2020

Ms V.Hema 49
Test Case Minimization

Ms V.Hema 50
Test Minimization

Ms V.Hema 51
 Test Case Minimization
Test suite minimisation techniques aim to identify
redundant test cases and to remove them from the test
suite in order to reduce the size of the test suite.

Test suite minimisation is a process that seeks to

identify and then eliminate the obsolete or
redundant test cases from the test suite.

Ms V.Hema 52
The Purpose of test case minimization is to generate
representative set from test suite that satisfy all the
requirements as original test suite with minimum
number of test cease.

Ms V.Hema 53
Test case minimization techniques are used to
minimize the testing cost in terms of execution time, resources
etc.

Main purpose of test case minimization techniques is to

remove test cases that become redundant and obsolete over
time.

These techniques can be categorized as

• Heuristic based.
• Genetic algorithm based approach.
• Integer Linear Programming based approach.
•Hybrid techniques.
•(Call tree and clustering based techniques).

Ms V.Hema 54
 Test case minimization techniques(Cont)
Heuristic based techniques
• Heuristic G
• Heuristic GE
• Heuristic GRE

Genetic algorithm

Integer Linear Programming

Hybrid techniques combine two or more techniques into single for

significant reduction in test suites and multi-objective optimization but
provide high complexity. More number of techniques can be incorporated
with existing hybrid techniques.

Ms V.Hema 55
Heuristic based techniques include Heuristic H(technique identified
redundant and obsolete test cases and removed them from test suite.),
GE(Heuristic GE is based on the greedy strategy and essential strategy. Firstly
essential strategy is applied i.e. all the essential test cases are added to
representative set. Then greedy strategy is applied on remaining test cases
repeatedly until the entire test requirements are satisfied. Heuristic GE
performed better than heuristic G since essential test cases are selected at first
stage) and GRE( This approach in based on three strategies - essential, 1-to-1
redundant strategy and greedy strategy-In this approach, firstly essential test
cases are selected and added to representative set, then 1-to-1 redundant test
cases are removed repeatedly and then greedy approach is applied on the
remaining test cases until all the requirements are satisfied. GRE guaranteed to
generate optimal representative sets.)

Genetic algorithm based approach uses production, mutation and crossover

to produce representative set.

Integer Linear Programming based approach uses equation form to find

minimal set.
Ms V.Hema 56
LECTURE-38
30-12-2020

Ms V.Hema 57
Tools for regression testing

Ms V.Hema 58
 Tools for regression testing(Cont)

1. Subject7 10. TestComplete

2. Cerberus Testing 11. IBM Rational Functional
3. Testimony Tester
4. Digivante 12. Katalon Studio
5. Testsigma 13. Ranorex Studio
6. TimeShiftX 14. TestDrive
7. Sahi Pro 15. AdventNet QEngine
8. Selenium 16. TestingWhiz
9. Watir 17. WebKing
18. Regression Tester

Ms V.Hema 59
LECTURE-39
30-012-2020

Ms V.Hema 60
 Adhoc Testing
“Adhoc Testing is an informal or unstructured software testing type
that aims to break the testing process in order to find possible
defects or errors at an early possible stage.”

 Is done randomly.

 It is usually an unplanned activity which does not follow any

documentation and test design techniques to create test cases.

Main aim is to to find defects by random checking.

Ms V.Hema 61
Adhoc Testing

Ms V.Hema 62
 Adhoc Testing(Cont)

Adhoc testing can be achieved with the Software testing

technique called Error Guessing.

Error guessing can be done by the people having enough

experience on the system to "guess" the most likely source of
errors.

Ms V.Hema 63
When execute Adhoc Testing?

Ad hoc testing can be performed when there is limited

time to do elaborative testing.

Usually adhoc testing is performed after the formal test

execution.

And if time permits, ad hoc testing can be done on the

system.

Ad hoc testing will be effective only if the tester is

knowledgeable of the System Under Test.

Ms V.Hema 64
Types of Adhoc testing
Forms of Adhoc Testing :

Buddy Testing: Two buddies, one from development team and one from
test team mutually work on identifying defects in the same module. Buddy
testing helps the testers develop better test cases while development team
can also make design changes early. This kind of testing happens usually
after completing the unit testing.

Pair Testing: Two testers are assigned the same modules and they share
ideas and work on the same systems to find defects. One tester executes
the tests while another tester records the notes on their findings.

Monkey Testing: Testing is performed randomly without any test cases in

order to break the system.

Ms V.Hema 65
Ways to make Adhoc Testing More Effective
Preparation.

Creating a Rough Idea.

Divide and Rule.

Targeting Critical Functionalities

Using Tools.

Documenting the findings

Ms V.Hema 66
Various ways to make Adhoc Testing More Effective
Preparation: By getting the defect details of a similar application, the
probability of finding defects in the application is more.
. a Rough Idea: By creating a rough idea in place the tester will
Creating
have a focused approach. It is NOT required to document a detailed plan
as what to test and how to test.
Divide and Rule: By testing the application part by part, we will have a
better focus and better understanding of the problems if any.
Targeting Critical Functionalities: A tester should target those areas that
are NOT covered while designing test cases.
Using Tools: Defects can also be brought to the lime light by using
profilers, debuggers and even task monitors. Hence being proficient in
using these tools one can uncover several defects.
Documenting the findings: Though testing is performed randomly, it is
better to document the tests if time permits and note down the deviations
if any. If defects are found, corresponding test cases are created so that it
helps the testers to retest the scenario.

Ms V.Hema 67
LECTURE-40
31-12-2020

Ms V.Hema 68
 Pair Testing

Pair Testing: Software development technique in which two

team members work together at one keyboard to test the
software application.

One does the testing and the other analyzes or reviews the
testing.

 This can be done between one Tester and Developer or

Business Analyst or between two testers with both participants
taking turns at driving the keyboard.

Ms V.Hema 69
Ms V.Hema 70
 Pair Testing(Cont)

A vital software testing technique, pair testing session

involves two individuals or team members, who work on a
single workstation/keyboard to test various aspects of a
software application.

This type of testing basically comes under ad-hoc testing and

aims at pairing two individuals to work on same software
product and on the same machine.

Ms V.Hema 71
 Pair Testing(Cont)
Procedure:

During pair testing, both the individuals are responsible for different
tasks that validate the quality as well as the functionality of the software.

While one of them executes the process of testing, the other member is
responsible for analyzing and reviewing the process.

Hence, with the assistance of this approach one can rapidly perform
thorough software testing, while saving time and money.
“Generally, one works on paper in taking notes
preparing scenarios, including reviews and analysis
of the test results, while another is responsible for
carrying out testing procedures on machines or
computer by making use of the other member's
output.”

Ms V.Hema 72
Pair Testing(Cont)-Procedure

Ms V.Hema 73
Best Combinations for the Pair Testing

Ms V.Hema 74
Pair Testing Features:
Responsible for generating effective test cases, quickly.

Time-saving approach.

Best method to train novice or new testers along with the task of testing, at
no-additional cost & time.

Bridges the gap and increases the coordination between developer and
tester.

Exchange and gain of knowledge, both by the testers and developers.

Not suitable, when the product needs automation.

“Pair testing can be related to Pair Programming and Exploratory Testing.”

Ms V.Hema 75
Advantages of Pair Testing:

•It promotes knowledge transfer.

•Ensures more angles of the software are tested.
•Improves the quality of the product, as it is validated by
two individuals.
•Helps save time and efforts invested in testing.
•Assists in improving interpersonal skills of the involved
individuals and breaks down barrier.
•Promotes communication among team members.
•It can be used as an opportunity to train different
employees.
•Helps identify the cause of defects without any hassle.
•Allows an expert and a novice to work together and
exchange knowledge.
•It does not require any special training.

Ms V.Hema 76
Challenges of Pair Testing:
Though, pair testing is an extremely beneficial testing technique,
there are few challenges that are encountered by the team while
executing its process.
These challenges are:
•As the bugs are reported after the culmination of the testing
process, it becomes time consuming and tedious for the team to
report and rectify them.

•It becomes difficult for the team to define the portions of the test
that has been performed.

•At times, it is difficult to find two individuals who are willing to

test the software together.

•This type of testing cannot be used during test automation.

Ms V.Hema 77
Tips to Improve Pair Testing:

following are some tips to improve pair testing:

•Before starting the process of testing, the team should create a

test plan or strategy.

•Test mission should be prepared based on the focus, scope, and

aim of the test.

•The team should focus on testing critical areas, where the

possibility of finding bugs is high.

•New functionality of the software should be tested after the end

of an iteration.

Ms V.Hema 78
LECTURE-41
31-12-2020

Ms V.Hema 79
 Exploratory testing
EXPLORATORY TESTING is a type of software testing where Test
cases are not created in advance but testers check system on
the fly.

They may note down ideas about what to test before test
execution.

The focus of exploratory testing is more on testing as a

"thinking" activity.

Exploratory Testing is widely used in Agile models and is all

about discovery, investigation, and learning.

 It emphasizes personal freedom and responsibility of the

individual tester.
Ms V.Hema 80
Ms V.Hema 81
 How to do Exploratory Testing?
Following is a step by step process on How to do
Exploratory Testing which is also called session based test
management (SBTM Cycle):

1.Create a Bug Taxonomy (classification)

• Categorize common types of faults found in the past
projects
• Analyze the root cause analysis of the problems or faults
• Find the risks and develop ideas to test the application.
2.Test Charter
• Test Charter should suggest
a. what to test.
b. how it can be tested.
c. What needs to be looked
• Test ideas are the starting point of exploration testing
• Test charter helps determine how the end user could use
the system
Ms V.Hema 82
3.Time Box
• This method includes a pair of testers working together not
less than 90 minutes
• There should not be any interrupted time in those 90 minutes
session
• Time box can be extended or reduced by 45 minutes
• This session encourages testers to react on the response from
the system and prepare for the correct outcome

4.Review Results:
• Evaluation of the defects
• Learning from the testing
• Analysis of coverage areas

5.Debriefing:
• Compilation of the output results
• Compare the results with the charter
• Check whether any additional testing is needed

Ms V.Hema 83
What to do during Exploratory Testing?

The mission of testing should be very clear

Keep notes on what needs to be tested, why it needs to be

tested and the assessment of the product quality

Tracking of questions and issues raised during exploratory

testing

Better to pair up the testers for effective testing

The more we test, more likely to execute right test cases for
the required scenarios

Ms V.Hema 84
It is very important to take a document and monitor the
following

•Test Coverage - Whether we have taken notes on the coverage

of test cases and improve the quality of the software

•Risks - Which risks need to be covered and which are all

important ones?

•Test Execution Log - Recordings on the test execution

•Issues / Queries - Take notes on the question and issues on the

system

“Smarter exploratory testing finds more

errors in less time.”
Ms V.Hema 85
 Pros and Cons of Exploratory Testing
Pro Con
•This testing is useful when requirement •This testing purely depends on the tester
documents are not available or partially skills
available •Limited by domain knowledge of the
•It involves Investigation process which tester
helps find more bugs than normal testing- •Not suitable for Long execution time
•Uncover bugs which are normally
ignored by other testing techniques
•Helps to expand the imagination of
testers by executing more and more test
cases which finally improves productivity
as well
•This testing drill down to the smallest
part of an application and covers all the
requirements
•This testing covers all the types of testing
and it covers various scenarios and cases
•Encourages creativity and intuition
•Generation of new ideas during test
execution

Ms V.Hema 86
Challenges of Exploratory Testing:

There are many challenges of exploratory testing and those are

explained below:

•Learning to use the application or software system is a

challenge
•Replication of failure is difficult
•Determining whether tools need to be used can be challenging
•Determine the best test cases to execute can be difficult
•Reporting of the test results is a challenge as the report doesn't
have planned scripts or cases to compare with the actual result
or outcome
•Documentation of all events during execution is difficult to
record
•Don't know when to stop the testing as exploratory testing has
definite test cases to execute.

Ms V.Hema 87
When use exploratory testing?

Exploratory testing can be used extensively when

The testing team has experienced testers

Early iteration is required

There is a critical application

New testers entered into the team

Ms V.Hema 88
LECTURE-42
05-01-2021

Ms V.Hema 89
 Iterative testing
“Iterative testing refers to making small, gradual changes or
updates to a product based on insights (e.g., test results and user
feedback) from previous changes and testing them against
predefined baseline metrics.”

It is commonly practiced in a UI/UX context but can be used in

the context of product management.

Iterative Testing or Iteration is a common and effective strategy in

software development

– features are designed, deployed, analyzed and improved upon

throughout the lifecycle on many products and services.

Ms V.Hema 90
Iterative testing(Cont)

Ms V.Hema 91
 Iterative testing(Cont)

The intended changes need to be tested thoroughly

•Does everything work as designed?

•Are edge cases handled properly?

•Does the design itself work well, or are there areas that
may confuse users?

Ms V.Hema 92
Benefits
Here are a few of the benefits of iterative testing for product managers:

1. Manage and Test Easily

2. Identify Issues Early

3. Get Better Insight

4. Deliver a Better Product

5. Maintain Flexibility

6. Get Stakeholder Buy-In

Ms V.Hema 93
1. Manage and Test Easily
Iterative testing enables product teams to make
incremental, evidence-based changes to a feature
or product. It allows them to roll changes out
quickly, and then gather user feedback to shape
product decisions. Because the changes aren’t
sweeping ones, they are easier to manage and test.
2. Identify Issues Early
Gradual tweaks made to the product help product
teams identify and eliminate bugs or usability issues
and correct them early on. Getting ahead enables
an organization to deliver a better product to users.
3. Get Better Insight
Iterative testing gives product managers actionable
insights via test results and user feedback, which
they can use to improve the product.

Ms V.Hema 94
 4. Deliver a Better Product
Product managers want to achieve product excellence by
developing a significant or impactful product or feature and
getting it to market quickly. Iterative testing helps product
managers get to the heart of how users will engage with a
product. It gives insight into whether or not the product hits
the desired mark
5. Maintain Flexibility
Making small, gradual changes to a product helps product
managers adapt to users’ changing needs. They can keep close
tabs on how users react to and feel about those changes. These
valuable insights, in turn, help guide future product decisions.
6. Get Stakeholder Buy-In
Because iterative testing is evidence-based (i.e., real data and
user feedback), product decisions are more comfortable to
justify. This ultimately helps product managers make their cases
with stakeholders.

Ms V.Hema 95
Best Practices for Iterative Testing

Here are a few things you’ll want to keep in mind as you

conduct iterative testing:

•Outline objectives and define the criteria for each testing

phase.
•Test as early as possible
•Track all usability issues
•Don’t lose sight of your product vision and product strategy
•Keep changes small and manageable (i.e., don’t try to solve
everything at once)
•Engage the entire team to help build customer empathy
•Document all iterations and the reasons behind each
change

Ms V.Hema 96
LECTURE-43
05-01-2021

Ms V.Hema 97
 Defect seeding
“Defect seeding is a practice in which defects are
intentionally inserted into a program by one group
for detection by another group.”

The ratio of the number of seeded defects

detected to the total number of defects seeded
provides a rough idea of the total number of
unseeded defects that have been detected.
Ex:
Suppose on GigaTron 3.0 that you intentionally seeded the
program with 50 errors.
•For best effect, the seeded errors should cover the full breadth of
the product’s functionality and the full range of severities—ranging
from crashing errors to cosmetic errors.

Ms V.Hema 98
•Suppose that at a point in the project when you believe testing to
be almost complete you look at the seeded defect report. You find
that 31 seeded defects and 600 indigenous defects have been
reported.

We can estimate the total number of defects with the formula:

{Total Latent Defects = (Total seeded defects / Defects seeded

found)* Original defects found}
or
IndigenousDefectsTotal = ( SeededDefectsPlanted /
SeededDefectsFound ) * IndigenousDefectsFound

This technique suggests that GigaTron 3.0 has approximately

50 / 31 * 600 = 967 total defects.

Ms V.Hema 99
 Defect seeding(Cont)

Important points:
To use defect seeding, you must seed the defects prior to
the beginning of the tests whose effectiveness you want to
ascertain.

 If your testing uses manual methods and has no

systematic way of covering the same testing ground twice,
you should seed defects before that testing begins.

If your testing uses fully automated regression tests, you

can seed defects virtually any time to ascertain the
effectiveness of the automated tests.

Ms V.Hema 100
 Challenges:
•A common problem with defect seeding programs is forgetting
to remove the seeded defects.

•Another common problem is that removing the seeded defects

introduces new errors.

•To prevent these problems, be sure to remove all seeded defects

prior to final system testing and product release.

•A useful implementation standard for seeded errors is to require

them to be implemented only by adding one or two lines of code
that create the error; this standard assures that you can remove
the seeded errors safely by simply removing the erroneous lines
of code.

Ms V.Hema 101