Unit-3

Software Testing Strategies

Misconceptions of testing

1) The developer of software should do no testing at all

Performs integration testing and builds software architecture.
2) The software should be “tossed over the wall” to strangers who will test it mercilessly
ITG removes inherent problems
3) Testers get involved with the project only when the testing steps are about to begin.
Software testing strategy

• The software process may be viewed as the spiral

• System engineering defines the role of software and leads to software
requirements analysis
• To develop computer software, you spiral inward (counterclockwise)
along streamlines that decrease the level of abstraction on each turn
Contd..

• Unit testing begins at the vortex of the spiral and concentrates on each unit of the software
• Testing progresses by moving outward along the spiral to integration testing, where the focus is on
design and the construction of the software architecture.
• Requirements established as part of requirements modeling are validated against the software that
has been constructed in Validation testing.
• Validation testing provides final assurance that software meets all informational, functional,
behavioral, and performance requirements
• Software and other system elements(people,hardware,database) are tested as a whole in system
testing.
• System testing verifies that all elements mesh properly and that overall system
function/performance is achieved
Contd..

• Testing within the context of software engineering is a series of four steps that are implemented
sequentially.
Criteria for Completion of Testing

“When are we done testing???”

“You’re never done testing it’s a continuous process”
“You’re done testing when you run out of time or you run out of
money.”
Testing strategies for conventional software

The unit testing focuses on the internal processing logic and data structures within the boundaries of
a component.
• The module interface is tested to ensure that information properly flows into and out of the
program unit under test.
• Local data structures are examined to ensure that data stored temporarily maintains its integrity .
• All independent paths through the control structure are exercised to ensure that all statements in a
module have been executed at least once.
• Boundary conditions are tested to ensure that the module operates properly at boundaries
established to limit or restrict processing.
• All error-handling paths are tested.
• 1,3,4,9,10,12,13,17,23,24,25,31,35,39,41,43,46,49,50,54,55,64
Contd..
The potential errors that should be tested when error handling is evaluated are:
(1) error description is unintelligible
(2) error noted does not correspond to error encountered
(3) error condition causes system intervention prior to error handling
(4) exception-condition processing is incorrect
(5) error description does not provide enough information to assist in the location of the cause of
the error.
Integration Testing

The major disadvantage of the top-down approach is the need for stubs and the
attendant testing difficulties that can be associated with them.
The major disadvantage of bottom-up integration is that “the program as an entity
does not exist until the last module is added.
Sandwich testing:
A combined approach that uses top-down tests for upper levels of the program
structure, coupled with bottom-up tests for subordinate levels
Regression Testing
• When a new module is added as part of integration testing, the software changes.(New data flow paths
are established, new I/O may occur, and new control logic is invoked).
• Regression testing is the re execution of some subset of tests that have already been conducted to
ensure that changes have not propagated unintended side effects.
• Regression testing helps to ensure that changes do not introduce unintended behavior or additional
errors.
• Regression testing may be conducted manually, by re executing a subset of all test cases or using
automated capture/playback tools.
• The regression test suite (the subset of tests to be executed) contains three different classes of test
cases.
-Tests for all Software functions
-Additional tests that focus on software functions that are likely to be affected by
the change.
-Tests that focus on the software components that have been changed
Strategic Issues
• Guidelines for systematic software testing are
• Specify product requirements in a quantifiable manner long before testing commences
verify for portability, maintainability, and usability
• State testing objectives explicitly
For example, test effectiveness, test coverage, mean time-to-failure, the cost to find and
fix defects
• Understand the users of the software and develop a profile for each user category
• Develop a testing plan that emphasizes “rapid cycle testing.”
• Build “robust” software that is designed to test itself
• Use effective technical reviews as a filter prior to testing.
• Conduct technical reviews to assess the test strategy and test cases themselves.
• Develop a continuous improvement approach for the testing process
Contd..

• As integration testing proceeds, the number of regression tests can grow quite
large.
• Therefore, the regression test suite should be designed to include only those
tests that address one or more classes of errors in each of the major program
functions.
Smoke testing

• Smoke testing is an integration testing approach that is commonly used when

product software is developed.
• It is designed as a pacing mechanism for time-critical projects, allowing the
software team to assess the project on a frequent basis.
• Software components that have been translated into code are integrated into a
build.
• A series of tests is designed to expose errors that will keep the build from properly
performing its function
• The intent should be to uncover “showstopper” errors that have the highest
likelihood of throwing the software project behind schedule.
• The build is integrated with other builds, and the entire product is smoke tested
daily. The integration approach may be top down or bottom up
Benefits of smoke testing

• smoke testing is likely to uncover functional errors as well as

architectural and component-level design errors. If these errors are
corrected early, better product quality will result.
• Integration risk is minimized-Tests are conducted daily.
• Error diagnosis and correction are simplified-new software
increments
• Progress is easier to assess.-More software integrated and more work
demonstrated