UNIT IV

TEST SELECTION AND MINIMISATION FOR REGRESSION TESTING

1. Regression testing
2. Regression Test Process
3. Initial Smoke or Sanity Test
4. Selection of regression tests
5. Execution traces
6. Dynamic Slicing
7. Test Minimisation
8. Tools for Regression testing
9. Ad hoc testing
10. Pair Testing
11. Exploratory Testing
12. Iterative Testing
13. Defect Seeding
 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.

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.

Regression Test Selection

It 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.
 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.

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.

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.

1. 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.

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.

Regression testing follows selective re-testing technique.

RE-TESTING:
It is testing of a particular bug after that 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.

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.”

Regression testing is required when there is a

 Change in requirements and code is modified according to the requirement
 New feature is added to the software
 Defect fixing
 Performance issue fix

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.

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

2. REGRESSION TEST PROCESS

• 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.

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.

3. 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.
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.
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.
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.
 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.

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.
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.
SMOKE VS SANITY TESTING

SMOKE VS SANITY TESTING

 SMOKE VS SANITY TESTING-DIFFERENCES

Smoke Testing Sanity Testing

Smoke Testing is performed to ascertain Sanity Testing is done to check the
that the critical functionalities of the new functionality/bugs have been
program is working fine fixed
The objective of this testing is to verify The objective of the testing is to verify
the "stability" of the system in order to the "rationality" of the system in
proceed with more rigorous testing order to proceed with more rigorous
testing
This testing is performed by the Sanity testing is usually performed by
developers or testers testers
Smoke testing is usually documented or Sanity testing is usually not
scripted documented and is unscripted
Smoke testing is a subset of Acceptance Sanity testing is a subset
testing of Regression Testing
Smoke testing exercises the entire system Sanity testing exercises only the
from end to end particular component of the entire
system
Smoke testing is like General Health Sanity Testing is like specialized health
Check Up check up
 4. 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.

5. 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.

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.

6. 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.
Types of slicing: a. Static slicing b. Dynamic slicing
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.

 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.

 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.

7. TEST CASE MINIMIZATION

 Large soft wares typically have a large number of tests and their complete runs teakes
several hours.
 For minimal changes, a complex software undergoes daily, a lot of these tests are only
testing what is already tested.
 These tests are run in nightly release process, for pre-check in requirements and check-
ns consuming time energy and money.
  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.
Purpose:
The Purpose of test case minimization is to generate representative set from test suite that
satisfies all the requirements as original test suite with minimum number of test cease.

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).
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.
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.

8. TOOLS FOR REGRESSION TESTING

 9. 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 find defects by random checking.

 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.
When shall we execute Ad hoc Testing?
 Ad hoc testing can be performed when there is limited time to do elaborative testing.
 Usually ad hoc 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.
Types of Ad hoc testing
Forms of Ad hoc 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.
Ways to make Ad hoc Testing More Effective
 Preparation.
 Creating a Rough Idea.
 Divide and Rule.
 Targeting Critical Functionalities
Using Tools.
 Documenting the findings
 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.
 Creating a Rough Idea: By creating a rough idea in place the tester will 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.
10. 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.
 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.
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.”

Best Combinations for the Pair Testing

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.”
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.
 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.
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.
11. 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.

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
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
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
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.”
 Pros and Cons of Exploratory Testing

Pro Con

• This testing is useful when requirement documents are not • This testing purely depends
available or partially available on the tester skills
• It involves Investigation process which helps find more bugs • Limited by domain
than normal testing- knowledge of the
• Uncover bugs which are normally ignored by other testing tester
techniques • Not suitable for Long
• Helps to expand the imagination of testers by executing more execution time
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

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.
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
12. 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.

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?
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

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.
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.
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

13. 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.
• 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
Indigenous Defects Total = ( Seeded Defects Planted / Seeded Defects Found ) *
Indigenous Defects Found
This technique suggests that Giga Tron 3.0 has approximately 50 / 31 * 600 = 967 total
defects.
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.
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.

oOo