2 Testing Process AnalyseDesignMaintainBuildTestInstal Software testing strategies Verification Validation System Testing / Quality Control
3 Master Test Plan 1. Test Approach Overview 2. Test Phase Definition Define staged testing processes to be employed to ensure full feature & function compliance with documented requirements and specifications relating to the project. Develop and establish structured testing environment Implement structured testing processes and controls which will improve defect detection, reduce iterative development This section provides a high level definition of the testing processes All aspects of testing should be included in this section
4 Master Test Plan 3. Participating Systems 4. Responsibilities 5. Resource Requirements Specify those systems which will incur change and those which will need to participate in Integrated Systems Testin Contact names and phone numbers should be indicated for each area of responsibility. Include project organization chart and matrix relationships. Specify individuals responsible for accepting the plan Provide a matrix of the estimated manpower requirements by month Specify any anticipated hardware / software costs for testing tools that have been indicated in the plan.
5 Master Test Plan 6. Schedules 7. Glossary of Terms Provide a high level schedule of the major testing milestones including each test phase start and end dates The Master Test Plan should include a glossary of terms to assist in providing clarity and understanding to the work to be performed, like: testing terminology acronyms application specific vocabulary
11 System Testing Once each of the individual modules has been tested & validated to correctly perform all the instructions assigned to it, the next step is to verify connectivity to related modules. The system test should detect any errors promoted between modules within the same system. As a result of a completed system test, all internal 'hand-shaking' will have been verified. Unit testing
12 Component Integration Testing Component System Integrated
13 Acceptance Testing If there is one customer, a series of acceptance tests are conducted (by the customer) to enable the customer to validate all requirements. If software is being developed for use by many customers, can not use acceptance testing. An alternative is to use alpha and beta testing to uncover errors.
14 Acceptance Testing Alpha Testing Beta Testing Alpha testing is conducted at the developer's site by a customer. The customer uses the software with the developer 'looking over the shoulder' and recording errors and usage problems. Alpha testing conducted in a controlled environment. Beta testing is conducted at one or more customer sites by end users. It is 'live' testing in an environment not controlled by the developer. The customer records and reports difficulties and errors at regular intervals. Software Accepted
15 Performance Testing For real-time and embedded systems, functional requirements may be satisfied but performance problems make the system unacceptable. Performance testing checks the run-time performance May require special software instrumentation.
16 Security Testing Systems with sensitive information or which have the potential to harm individuals can be a target for improper or illegal use. This can include: 1. attempted penetration of the system by 'outside' individuals for fun or personal gain. 2. disgruntled or dishonest employees
17 Security Testing During security testing the tester plays the role of the individual trying to penetrate the system. Large range of methods: 1. attempt to acquire passwords through external clerical means 2. use custom software to attack the system 3. overwhelm the system with requests 4. cause system errors and attempt to penetrate the system during recovery 5. browse through insecure data.
18 Recovery Testing Many systems need to be fault tolerant - processing faults must not cause overall system failure. Other systems require recovery after a failure within a specified time. Recovery testing is the forced failure of the software in a variety of ways to verify that recovery is properly performed.
19 Classic Testing Mistakes starting testing too late not testing the documentation not testing installation procedures. failing to correctly identify risky areas recruiting testers from the ranks of failed programmers physical separation between developers and testers. programmers can't test their own code. paying more attention to running tests than to designing them poor bug reporting And many more...