ajeng.savitri@teknokrat.ac.id https://teknokrat.ac.id/en/

1. MEETING 9
SOFTWARE TESTING STRATEGY
SOFTWARE TESTING
By : Ajeng Savitri Puspaningrum, M.Kom

2. OBJECTIVE
• Introduction to Software
Testing Strategy
• Learning Unit Testing

3. Introduction

4. 4
TESTING REVIEW
The main objective of software testing is
to design the tests in such a way that it
systematically finds different types of
errors without taking much time and
effort so that less time is required for the
development of the software.
That’s why we need to choose the best
testing strategy !

5. 5
SOFTWARE TESTING STRATEGY
• A software testing strategy is the set of
steps that need to be done to assure the
highest possible quality of an end-product.
• If you choose the strategy that your
project does not require to be perfect,
you waste time and resources for
nothing.

6. 6
VERIFICATION AND VALIDATION (V&V)
• Verification refers to the set of tasks that ensure that software
correctly implements a specific function.
• “Are we building the product right?”
• Validation refers to a different set of tasks that ensure that the
software that has been built is traceable to customer requirements.
• “Are we building the right product?”

7. 7
V&V ACTIVITIES
1. Technical Reviews,
2. Quality And
Configuration Audits,
3. Performance
Monitoring,
4. Simulation,
5. Feasibility Study,
6. Documentation
Review,
7. Database Review,
8. Algorithm Analysis,
9. Development Testing,
10.Usability Testing,
11.Qualification Testing,
12.Acceptance Testing,
And
13.Installation Testing.

8. 8
TESTING CHARACTERISTICS
• A number of software testing strategies are implemented to provide a
testing framework for software developers with the following general
characteristics:
1. Testing starts from the smallest component level until integration between
components in the entire computer system is achieved.
2. Testing techniques vary according to the time of use.
3. Testing is done by software developers and (for large projects) by an
independent test group.
4. Testing and debugging are separate activities, but debugging should be
accommodated in any testing strategy.

9. 9
TESTING STRATEGY

10. 10
TESTING STRATEGY ( cont…)
• Unit testing begins at the vortex of the spiral and concentrates on
each unit (e.g., component, class, or WebApp content object) of the
software as implemented in source code.
• Moving outward along the spiral to integration testing, where the
focus is on design and the construction of the software architecture.
• Encounter validation testing, where requirements established as
part of requirements modeling are validated against the software
that has been constructed.
• Finally, system testing, where the software and other system
elements are tested as a whole.

11. 11
SOFTWARE TESTING STEPS
Testing within the context of
software engineering
is actually a series of
four steps that are
implemented sequentially

12. 12
FIRST STEP
• Tests focus on each component individually,
ensuring that it functions properly as a unit.
• Called UNIT TESTING.
• Unit testing makes heavy use of testing techniques
that exercise specific paths in a component’s
control structure to ensure complete coverage and
maximum error detection.

13. 13
SECOND STEP
• Components must be assembled or integrated to
form the complete software package.
• INTEGRATION TESTING addresses the issues
associated with the dual problems of verification
and program construction.
• Test-case design techniques that focus on inputs
and outputs are more prevalent during integration,
although techniques that exercise specific program
paths may be used to ensure coverage of major
control paths.

14. 14
THIRD STEP
• After the software has been integrated
(constructed), a set of high-order tests is
conducted.
• Validation criteria (established during
requirements analysis) must be evaluated.
• VALIDATION TESTING provides final assurance that
software meets all functional, behavioral, and
performance requirements.

15. 15
FOURTH STEP
• The last high-order testing step falls outside the
boundary of software engineering and into the
broader context of computer system engineering.
• Software, once validated, must be combined with
other system elements (e.g., hardware, people,
databases).
• SYSTEM TESTING verifies that all elements mesh
properly and that overall system function and
performance is achieved.

16. Unit Testing

17. 17
DEFINITION
• Unit testing (or module testing) is a process of testing
the individual subprograms, subroutines, classes, or
procedures in a program. The motivations for doing
this are:
• Managing the combined elements of testing, since
attention is focused initially on smaller units of the program
• Eases the task of debugging (the process of pinpointing and
correcting a discovered error), since, when an error is
found, it is known to exist in a particular module.
• Introduces parallelism into the program testing process by
presenting us with the opportunity to test multiple
modules simultaneously

18. 18
• Focuses on the smallest core of
software design namely modules
• Examples : the module itself as a unit,
GUI components (such as windows,
menus, and functions), batch programs,
online programs, and stored
procedures.
• Conducted to compare the function of
a module to some functional or
interface specification defining the
module.
• Usually white box oriented

19. 19
THE
ADVANTAGES
1. Permits the testing and debugging of
small units, thereby providing a better
way to manage the integration of the
units into larger units.
2. Testing a smaller unit of code makes it
mathematically possible to fully test
the code’s logic with fewer tests.
3. Facilitates automated testing because
the behavior of smaller units can be
captured and played back with
maximized reusability.

20. 20
TESTING STEPS
1. The module interface is tested to ensure that information properly flows
into and out of the program unit under test
2. Local data structures are examined to ensure that data stored
temporarily maintains its integrity during all steps in an algorithm’s
execution
3. All independent paths through the control structure are exercised to
ensure that all statements in a module have been executed at least once
4. Boundary conditions are tested to ensure that the module operates
properly at boundaries established to limit or restrict processing
5. And finally, all error-handling paths are tested.

21. 21
THE MODULE INTERFACE TESTING
CHECKLIST
• Is the number of input parameters equal to the number of
arguments?
• Is the attribute and parameter argument matched?
• Is the parameter and argument unit system compatible?
• Is the number of arguments passed to the called module the same as
the parameter attribute?
• Are the attributes of the arguments passed to
the called module the same as the attributes
of the parameters?

22. 22
• Is the system of units of the arguments transmitted to the called module
the same as the system of units of parameters?
• Is the number of attributes and the order of arguments to the built-in
functions correct?
• Any references to parameters that don't match the existing entry points?
• Was the input only argument changed?
• Is the global variable definition consistent with
the module ?
• Is the boundary being passed an argument?
THE MODULE INTERFACE TESTING
CHECKLIST (cont…)

23. 23
HOW WELL IS
THE TEST DONE?
• In performing the process of module testing, there are
two key considerations:
1. The design of an effective set of test cases,
2. The manner in which the modules are combined to form a
working program.

24. 24
TEST CASE DESIGN
• Two types of information needed when designing test
cases :
• A specification for the module : typically defines the
module’s input and output parameters and its function
• The module’s source code.
• Test cases should be designed to uncover errors in
categories :
• Irregular and inconsistent typing
• Incorrect initialization or default values
• Incorrect variable name
• Inconsistent data types
• Underflow, overflow and exception addressing

25. 25
THE COMBINED MODULES
• The manner in which the modules are
combined is important because it has these
implications:
• The form in which module test cases are written
• The types of test tools that might be used
• The order in which modules are coded and tested
• The cost of generating test cases
• The cost of debugging (locating and repairing
detected errors)

26. 26
THE APPROACH
1. Test a program by testing each module
independently and then combining the
modules to form the program, or
2. Combine the next module to be tested
with the set of previously tested modules
before it is tested
These approach lead us to
“THE INTEGRATION TEST”

27. Integration
Testing

28. 28
PREFACE
• After unit testing is completed, all modules must be
integration-tested.
• During integration testing, the system is slowly built
up by adding one or more modules at a time to the
core of already-integrated modules.
• The goals of integration testing are to verify that
each module performs correctly within the control
structure and that the module interfaces are correct.

29. 29
DEFINITION
• Integration testing is the process of verifying the
interactions among software components [5].
• Integration testing is a systematic technique for
constructing the software architecture while at
the same time conducting tests to uncover errors
associated with interfacing [1].

30. 30
THE GOALS
• To verify that each module performs correctly within
the control structure and that the module interfaces
are correct.
• To take unit-tested components and build a program
structure that has been dictated by design.

31. 31
INTEGRATION TESTING STRATEGY
• Classical : used with hierarchically structured software such as topdown
and bottom-up
• Modern : typically architecture-driven, which involves incrementally
integrating the software components or subsystems based on identified
functional threads
• Often an ongoing activity at each stage of development during which
software engineers abstract away lower-level perspectives and concentrate
on the perspectives of the level at which they are integrating.
• For other than small, simple software, incremental integration testing
strategies are usually preferred to putting all of the
components together at once—which is
often called “big bang” testing.

32. 32
“BIG BANG” TESTING
• In the big bang approach, all components are combined
in advance and the entire program is tested as a whole.
• Chaos usually results!
• Errors are encountered, but correction is difficult because isolation of
causes is complicated by the vast expanse of the entire program.
• The emergence of new errors when the previous errors were addressed,
thus creating an endless cycle.
• Taking the big bang approach to integration is a lazy
strategy that is doomed to failure.
Incremental integration is the antithesis of the big bang approach !

33. 33
INCREMENTAL TESTING
• The program is constructed and tested in small
increments
• Errors are easier to isolate and correct;
• Interfaces are more likely to be tested completely; and
• A systematic test approach may be applied.
• Integrate incrementally and testing as you go is a more
cost-effective strategy.
• When it has been demonstrated that a module performs
properly with the program structure, another module is
added, and testing continues.
• This process is repeated until all modules have been
integrated and tested.

34. 34
SAMPLE
• The rectangles represent the six modules
(subroutines or procedures) in the program.
• The lines connecting the modules represent
the control hierarchy of the program, that is:
• module A calls modules B, C, and D;
• module B calls module E;
• And so on.
SO, HOW DO WE DONE THE TEST?

35. 35
• BIG BANG TESTING :
1. First, a module test is performed on each of the six
modules, testing each module as a stand-alone entity.
• The modules might be tested at the same time or in succession,
depending on the environment and the number of people
involved.
2. Finally, the modules are combined or integrated to
form the program.
• INCREMENTAL TESTING :
• The next module to be tested is first combined with the
set of modules that have been tested already.
• Adding the next module to the set or subset of
previously tested modules, is continued until the last
module (module A in this case) is tested.

36. 36
COMPARISON
BIG-BANG TESTING INCREMENTAL TESTING
Requires more work
• Five drivers and five stubs must be prepared
(assuming we do not need a driver module for
the top module).
Required Less work
• The bottom-up incremental test would require
five drivers but no stubs.
• A top-down incremental test would require five
stubs but no drivers.
Modules do not ‘‘see one another’’ until the end
of the process
Programming errors related to mismatching
interfaces or incorrect assumptions among
modules will be detected earlier
The errors will not surface until the entire program
has been combined
• Difficult to pinpoint the error, since it could be
anywhere within the program.
Debugging should be easier
• Easier to pinpoint the error, because it is likely
that the error is associated with the most
recently added module

37. 37
COMPARISON(cont…)
BIG-BANG TESTING INCREMENTAL TESTING
The testing of a module will affect only to that
module itself
The testing might result in more thorough testing.
• Although a module should have been
thoroughly tested previously, perhaps executing
it as a result of other module test will invoke a
new condition, perhaps one that represents a
deficiency in the original test.
Use less machine time Use less machine time
More opportunity for parallel activities
• Might be of significance in a large project (many
modules and people), since the headcount of a
project is usually at its peak at the start of the
module test phase.
Less opportunity for parallel activities

38. NEXT MEETING…
• Integration Testing (cont.)
• Continues Integration Testing
• System Testing

39. References
Lewis, W. E. (2009). Software Testing And Continuous Quality
Improvement ed. 3rd. Auerbach publications.
02
Majchrzak, T. A. (2012). Improving Software Testing: Technical And
Organizational Developments. Springer Science & Business Media.
03
Myers, G. J., Sandler, C., & Badgett, T. (2012). The Art Of Software
Testing. John Wiley & Sons.
04
Roger, S. P., & Bruce, R. M. (2019). Software Engineering: A
Practitioner’s Approach Ed.9th. McGraw-Hill Education.
01
Bourque, P., Dupuis, R., Abran, A., Moore, J. W., & Tripp, L. (2014).
The guide to the software engineering body of knowledge. IEEE
software.
05

40. THANK YOU
Insert the Subtitle of Your Presentation