Information Technology Reference
In-Depth Information
Test cases should focus on common fault areas, particularly tricky code seg-
ments, and areas with a low fault tolerance. This can be a challenging feat as test
plans should be drawn up before implementation begins. This assures that there are
appropriate resources (including time) to execute the necessary tests. Proactive test
planning normally fits very well with black-box testing where specifications are
used to design testing scenarios which are applied to the developed program's
segments and the results are compared to the expected results.
13.5.2 Quality Testing
Quality testing should be done methodically and comprehensively. Quality testing
is one of the few in roads to product quality assurance. Product testing normally
advances in three phases. The first phase in quality assurance is a quality
inspection. Before a quality inspection occurs, the inspection team needs to col-
laborate with the developers of the particular piece of code if possible, and derive a
checklist for the quality inspection. The development checklist that follows is
adapted from Ian Sommerville (Sommerville
1996
).
• Data Faults:
- Are all variables initialized before use?
- Have all constants been named?
- Lower array bounds checked?
- Are string delimiters required and verified?
• Control Faults:
- For each conditional statement is the condition correct?
- Are there any infinite loops?
- In case statements are all cases counted for?
• I/O Faults:
- Are all input variables used?
- Are unassigned variables output?
• Interface faults:
- Do all function and procedure calls have the correct amount of parameters?
- Do formal and actual parameter types match?
- Are the parameters in the correct order?
- Do components that access shared memory have the same shared memory
structure?
• Storage management faults:
- Has dynamic storage been allocated correctly?
- Has dynamic storage been deallocated correctly?
