Testing Tutorial
Types of Software Testing
Static Testing
Static testing refers to testing something that’s not running. It is
examining and reviewing it. The specification is a document and not an
executing program, so it’s considered as static. It’s also something that was
created using written or graphical documents or a combination of both.
High-level Reviews of specification
• Pretend to be the customer.
• Research existing Standards and Guidelines.
• Review and Test similar software.
Low-level Reviews of specification
• Specification Attributes checklist.
• Specification terminology checklist.
Dynamic Testing
Techniques used are determined by type of testing that must be conducted.
• Structural (usually called "white box") testing.
• Functional ("black box") testing.
Structural testing or White box testing
Structural tests verify the structure of the software itself and require
complete access to the source code. This is known as ‘white box’ testing
because you see into the internal workings of the code.
White-box tests make sure that the software structure itself contributes to
proper and efficient program execution. Complicated loop structures, common
data areas, 100,000 lines of spaghetti code and nests of ifs are evil.
Well-designed control structures, sub-routines and reusable modular programs
are good.
White-box testing strength is also its weakness. The code needs to be examined
by highly skilled technicians. That means that tools and skills are highly
specialized to the particular language and environment. Also, large or
distributed system execution goes beyond one program, so a correct procedure
might call another program that provides bad data. In large systems, it is the
execution path as defined by the program calls, their input and output and the
structure of common files that is important. This gets into a hybrid kind of
testing that is often employed in intermediate or integration stages of
testing.
Functional or Black Box Testing
Functional tests examine the behavior of software as evidenced by its outputs
without reference to internal functions. Hence it is also called ‘black box’
testing. If the program consistently provides the desired features with
acceptable performance, then specific source code features are irrelevant.
It's a pragmatic and down-to-earth assessment of software.
Functional or Black box tests better address the modern programming paradigm.
As object-oriented programming, automatic code generation and code re-use
becomes more prevalent, analysis of source code itself becomes less important
and functional tests become more important. Black box tests also better attack
the quality target. Since only the people paying for an application can
determine if it meets their needs, it is an advantage to create the quality
criteria from this point of view from the beginning.
Black box tests have a basis in the scientific method. Like the process of
science, Black box tests must have a hypothesis (specifications), a defined
method or procedure (test plan), reproducible components (test data), and a
standard notation to record the results. One can re-run black box tests after
a change to make sure the change only produced intended results with no
inadvertent effects.
| 