1. WebApp content model is reviewed to uncover errors.
2. Interface model is reviewed to ensure all use-cases are accommodated.
3. Design model for WebApp is reviewed to uncover navigation errors.
4. User interface is tested to uncover presentation errors and/or navigation mechanics problems.
5. Selected functional components are unit tested.
6. Navigation throughout the architecture is tested.
7. WebApp is implemented in a variety of different environmental configurations and the compatibility of WebApp with each is assessed.
8. Security tests are conducted.
9. Performance tests are conducted.
10. WebApp is tested by a controlled and monitored group of end-users (looking for content errors, navigation errors, usability concerns, compatibility issues, reliability, and performance).
· Focuses on visible user actions and user recognizable outputs from the system
· Validation tests are based on the use-case scenarios, the behavior model, and the event flow diagram created in the analysis model
- Must ensure that each function or performance characteristic conforms to its specification.
- Deviations (deficiencies) must be negotiated with the customer to establish a means for resolving the errors.
· Configuration review or audit is used to ensure that all elements of the software configuration have been properly developed, cataloged, and documented to allow its support during its maintenance phase.
· Making sure the software works correctly for intended user in his or her normal work environment.
· Alpha test – version of the complete software is tested by customer under the supervision of the developer at the developer’s site
· Beta test – version of the complete software is tested by customer at his or her own site without the developer being present
· Series of tests whose purpose is to exercise a computer-based system
· The focus of these system tests cases identify interfacing errors
· Recovery testing – checks the system’s ability to recover from failures
· Security testing – verifies that system protection mechanism prevent improper penetration or data alteration
· Stress testing – program is checked to see how well it deals with abnormal resource demands (i.e. quantity, frequency, or volume)
· Performance testing – designed to test the run-time performance of software, especially real-time software
· Deployment (or configuration) testing – exercises the software in each of the environment in which it is to operate
· The symptom and the cause may be geographically remote (symptom may appear in one part of a program).
· The symptom may disappear (temporarily) when another error is corrected.
· The symptom may actually be caused by non-errors (e.g., round-off inaccuracies).
· The symptom may be caused by human error that is not easily traced.
· The symptom may be a result of timing problems, rather than processing problems.
· It may be difficult to accurately reproduce input conditions (e.g., a real-time application in which input ordering is indeterminate).
· The symptom may be intermittent. This is particularly common in embedded systems that couple hardware and software inextricably.
· The symptom may be due to causes that are distributed across a number of tasks running on different processors.
· Debugging (removal of a defect) occurs as a consequence of successful testing.
· Some people are better at debugging than others.
· Common approaches (may be partially automated with debugging tools):
· Brute force – memory dumps and run-time traces are examined for clues to error causes
· Backtracking – source code is examined by looking backwards from symptom to potential causes of errors
· Cause elimination – uses binary partitioning to reduce the number of locations potential where errors can exist)
Bug Removal Considerations
· Is the cause of the bug reproduced in another part of the program?
· What “next bug” might be introduced by the fix that is being proposed?
· What could have been done to prevent this bug in the first place?