Basics of Software Testing

Structured-based or White Box

Techniques
Why do we need White Box techniques?
● Prove formal structure to testing code
● Enables us to measure how much of a component has been tested
● Examples:
○ < 100 lines of code
○ 100,000,000,000,000 possible paths
○ At 1000 tests per second would still take 3170 years to test all paths
Structured-based or White Box Techniques
● To plan and design effective cases requires a knowledge of the:
○ Programming language used
○ Database used
○ Operating system(s) used
○ And ideally knowledge of the code itself
White box test techniques
● Statement testing
● Decision Testing
● Branch Condition Testing
● Branch Condition Combination Testing
● Modified Condition Decision Testing
● Linear Code Sequence & Jump (LCSAJ)
● Data Flow Testing
Statement Testing and Coverage
● “A white box test design technique in which test cases are designed to
execute statements.”
● Test cases are designed ad run with the intention of executing every
statement in a component
● In component testing, statement coverage is the assessment of the
percentage of executable statements that have been exercised by a test
case suite
Statement Testing and Coverage - Example
A;

If (B)

C;

D;

Any test case with B TRUE will achieve full statement coverage.

NOTE: Full statement coverage can be achieved without exercising with B

FALSE
Decision Testing and Coverage
● A white box test design technique in which test cases are designed to
execute decision outcomes
● Is the assessment of the percentage of decision outcomes (e.g. True and
False options of an IF statement) that have been exercised by a test case
suite
● Test Cases designed to ensure all decision points are covered
Decision Testing and Coverage
● Is a form of control flow testing as it generates a specific flow control
through the decision points
● Decision Coverage
○ Is stronger than statement coverage:
■ 100% decision coverage guarantees 100% statement coverage
Decision Testing and Coverage - Example
A;

If (B)

C;

D;

100% statement coverage requires 1 test case (B = TRUE)

100% decision coverage requires 2 test cases (B = TRUE & B = FALSE)

Exercises
● How many tests are required to achieve:
○ 100% statement coverage
○ 100% decision coverage

Enter user ID
IF user ID is valid THEN
IF password is valid THEN
Display account screen
ELSE
Display “wrong password”
ELSE
Display “wrong ID”
END IF
Display time & date
Exercises
● How many tests are required to achieve:
○ 100% statement coverage
○ 100% decision coverage

READ AGE
IF AGE > 0 THEN
IF AGE = 21 THEN
PRINT “21st”
END IF
END IF
PRINT AGE
Other Structured-base Techniques
● Branch Condition testing, Branch Condition Combination testing &
Modified Condition Decision testing.
○ Condition testing is based upon an analysis of the conditional control flow within the
component
● LCSAJ
○ Linear Code Sequence and Jump
● Data flow testing
○ Tests the flow of data through a component
Basics of Software Testing
Experienced based Techniques
Experience-based Testing
● Is whenere the tests are derived from the tester’s skill and intuition and
their experience with similar applications and technologies
● When used to augment systematic techniques, these techniques can be
useful in identifying special tests not easily captured by formal
techniques, especially when applied after more formal approaches
● This techniques amy yield widely varying degrees of effectiveness,
depending of the testers experience
Error Guessing
● “A test design technique where the experience of the tester is used to
anticipate what defects might be present in the component or system
under test as a result of errors made, and to design tests specifically to
expose them.”
● A commonly used Experience based Technique
● A structured approach to the Error Guessing is to enumerate a list of
possible errors and to design tests that attack these errors
○ This systematic approach is called Fault atack
● These defects and failures lists can be built based on:
○ Experience
○ Available defect and failure data
○ From common knowledge about why software fails
Error Guessing - Used to guess where errors may be lurking
● Based on information about how the system has been put together and
previous experience of testing it
● Used to complement more systematic techniques not instead of
● Not ad-hoc testing, but testing that targets certain parts of the application
Error Guessing
● Based on the users or testers experience of the commercial aspects of the
system
○ Table based calculations such as calculating benefits payments
○ Where the user is allowed a high degree of flexibility in GUI navigation using multiple
windows
Error Guessing
● Error Guessing - experience of the developers or the development cycle
○ Knowledge of an individual “style”
○ Knowledge of the development lifecycle and especially the change management process
● Error Guessing - experience of the operating system used
○ It is known that Windows NT is better at storage management than Windows 95
Error Guessing
● Should still be planned
○ Is part of the test process
■ Should be used as a supplement to systematic techniques
○ Ad-Hoc testing can be encouraged if
■ The tester maintains a log of those tests performed & is able to reasonably recollect
what actions were performed
○ If you have the time to run and extra (ad-Hoc) test that passes there is little loss
■ If it finds a defect then that’s a bonus
Exploratory Testing
● Is a test execution, based on a test charter containing test objectives, and
carried out within time-boxes
● Is an approach that is most useful where there are few or inadequate
specifications and severe time pressure, or in order to augment or
complement other, more formal testing
● It can serve as a check on the test process, to help ensure that the most
serious defects are found
Exploratory Testing
● Can be a powerful approach to testing
○ Sometimes is much more productive than testing using scripts
○ Involves tacit constraints concerning which parts of the product are to be tested, or what
strategies are to be used
■ Still this are not test scripts
○ Every test is influenced by the result of the previous one
Summary
● In the Experience-based testing the tests are derived from the testers skill,
intuition and experience
● Error guessing - a technique where is used the testers experience
● Exploratory testing - An informal test design technique where the tester
actively controls the design of the tests
Basics of Software Testing
Choosing Test Techniques
Choosing Test Techniques
● The choice of which test technique to use depends on a number of
factors:
○ Th type of system
○ Level or type of risk
○ Thest objective
○ Documentation available
○ Knowledge of the testers
○ Time and budget
○ Supporting tools - for design and/or regression testing
○ Previous experience of types of defects found
Choosing Test Techniques
● The choice of a test technique may be made based on:
○ Regulatory standards
○ Experience and / or
○ Customer / contractual requirements
● Some techniques are more applicable to certain situations and test levels;
others are applicable to all test levels
Choosing Test Techniques
● Selection factors:
○ Product life cycle status
○ Previous experiences
○ Measurements on test effectiveness
○ International standards - many times they are industry specific
○ Customer/contractual requirements
○ Auditability/traceability
● A lot of information, skills necessary!
Choosing Test Techniques
● Summary
○ You can never do enough testing
■ The more tests that you can run, the more errors you may find
○ Error guessing can help ensure that areas where defects are likely to occur are fully
tested
○ Uses experience and gut feeling to supplement systematic testing techniques
○ Exploratory testing is most useful where there are a few or inadequate specifications or
severe time pressure