Software Testing

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.

• Pretend to be the customer.
• Research existing Standards and Guidelines.
• Review and Test similar software.

• 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 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 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.