DevEX - reference for building teams, processes, and platforms
Software testing
1.
2. Software testing is a formal process carried out by a
specialized testing team in which a software
unit, several integrated software units or an
entiresoftware package are examined by running the
programs on a computer. All the associated tests are
performed according to approved test procedures on
approved test cases.
3. Software testing (or “testing”) was the first software
quality assurance tool applied to control the software
product’s quality before its shipment or installation at
the customer’s premises.
4. 0 At first, testing was confined to the final stage of
development, after the entire package had been completed.
0 Later, as the importance of early detection of software
defects penetrated quality assurance concepts, SQA
professionals were encouraged to extend testing to the
partial in-process products of coding, which led to
software module (unit) testing and integration testing.
0 Common to all testing activities is their application
through the direct running of code, free of review of
development documents. Some authors tend to broaden
the scope of testing even further and consider all software
life cycle quality assurance activities as types of testing
activities.
5. Software Testing Strategies
0 Big bang testing : test the software in its entirety, once
the completed package is available;
0 Unit Test : test the software piecemeal, in modules, as
they are completed
0 Integration tests : test groups of tested modules
integrated with newly completed modules ().
0 Incremental testing : This process continues until all
the package modules have been tested. Once this
phase is completed, the entire package is tested as a
whole (system test).
6. Incremental Testing
0 In top-down testing, the first module tested is the
main module, the highest level module in the software
structure; the last modules to be tested are the lowest
level modules.
0 In bottom-up testing, the order of testing is reversed:
the lowest level modules are tested first, with the
main module tested last.
7. Software Test Clasifications
Classification according to testing concept:
0 Black box (functionality) testing. Identifies bugs only
according to software malfunctioning as they are revealed
in its erroneous outputs. In cases that the outputs are
found to be correct, black box testing disregards the
internal path of calculations and processing performed.
0 White box (structural) testing. Examines internal
calculation paths in order to identify bugs. Although the
term “white” is meant to emphasize the contrast between
this method and black box testing, the method’s other
name – “glass box testing” – better expresses its basic
characteristic, that of investigating the correctness of code
structure.
9. WHITE BOX TESTING
0 White box testing enables performance of data
processing and calculations correctness
tests, software qualification tests, maintainability
tests and reusability tests.
0 In order to perform data processing and calculation
correctness tests (“white box correctness test”), every
computational operation in the sequence of
operations created by each test case (“path”) must be
examined.
10. Data processing and
calculation correctness tests
Applying the concept of white box testing, which is based on
checking the data processing for each test case, immediately
raises the question of coverage of a vast number of possible
processing paths and the multitudes of lines of code. Two
alternative approaches have emerged:
0 “Path coverage” – to plan our test to cover all the possible
paths, where coverage is measured by percentage of paths
covered.
0 “Line coverage” – to plan our tests to cover all the program
code lines, where coverage is measured by percentage of
lines covered.
11. Correctness tests and path
coverage
Different paths in a software module are created by the
choice in conditional statements, such as IF–THEN–
ELSE or DO WHILE or DO UNTIL. Path testing is
motivated by the aspiration to achieve complete
coverage of a program by testing all its possible paths.
12. Correctness tests and line
coverage
The line coverage concept requires that, for full line
coverage, every line of code be executed at least once
during the process of testing. The line coverage metrics
for completeness of a line-testing (“basic path testing”)
plan are defined as the percentage of lines indeed
executed – that is, covered – during the tests.
13. Black Box Testing
0 Black box testing allows us to perform output
correctness tests and most classes of tests. Apart from
output correctness tests (if you are prepared to pay
the extra costs, these could be performed by white
box data processing and calculation correctness tests)
and maintainability tests (that could be performed by
white box tests), most of the other testing classes are
unique to black box testing.
