Software Testing (Usability Testing of Website)
Download as PPT, PDF2 likes772 views
The document discusses various aspects of software testing including: - The importance of testing to find errors and the limitations of testing. - Good testing practices such as focusing on error detection, avoiding self-testing, and thoroughly inspecting test results. - Different levels of testing from unit to acceptance testing. - Methods for test planning, estimation, development of test cases and scripts, and reporting of results.
Software Testing (Usability Testing of Website)
- 1. Software Testing Inam Ul Haq OOA/D, BSIT Inam.bth@gmail.com Guest Lecture OOA/D, BSIT-5th, Univesity of Education Okara 1
- 2. Observations about Testing “Testing is the process of executing a program with the intention of finding errors.” – Myers “Testing can show the presence of bugs but never their absence.” - Dijkstra OOA/D, BSIT-5th, Univesity of Education Okara 2
- 3. Good Testing Practices A good test case is one that has a high probability of detecting an undiscovered defect, not one that shows that the program works correctly It is impossible to test your own program A necessary part of every test case is a description of the expected result OOA/D, BSIT-5th, Univesity of Education Okara 3
- 4. Good Testing Practices (cont’d) Avoid nonreproducible or on-the-fly testing Write test cases for valid as well as invalid input conditions. Thoroughly inspect the results of each test case As the number of detected defects in a piece of software increases, the probability of the existence of more undetected defects also increases OOA/D, BSIT-5th, Univesity of Education Okara 4
- 5. Good Testing Practices (cont’d) Assign your best people to testing Ensure that testability is a key objective in your software design Never alter the program to make testing easier Testing, like almost every other activity, must start with objectives OOA/D, BSIT-5th, Univesity of Education Okara 5
- 6. Levels of Testing Unit Testing Integration Testing Validation Testing Regression Testing Alpha Testing Beta Testing Acceptance Testing OOA/D, BSIT-5th, Univesity of Education Okara 6
- 7. Unit Testing Algorithms and logic Data structures (global and local) Interfaces Independent paths Boundary conditions Error handling OOA/D, BSIT-5th, Univesity of Education Okara 7
- 8. Why Integration Testing Is Necessary One module can have an adverse effect on another Subfunctions, when combined, may not produce the desired major function Individually acceptable imprecision in calculations may be magnified to unacceptable levels OOA/D, BSIT-5th, Univesity of Education Okara 8
- 9. Why Integration Testing Is Necessary (cont’d) Interfacing errors not detected in unit testing may appear Timing problems (in real-time systems) are not detectable by unit testing Resource contention problems are not detectable by unit testing OOA/D, BSIT-5th, Univesity of Education Okara 9
- 10. Validation Testing Determine if the software meets all of the requirements defined in the SRS Having written requirements is essential Regression testing is performed to determine if the software still meets all of its requirements in light of changes and modifications to the software Regression testing involves selectively repeating existing validation tests, not developing new tests OOA/D, BSIT-5th, Univesity of Education Okara 10
- 11. Alpha and Beta Testing It’s best to provide customers with an outline of the things that you would like them to focus on and specific test scenarios for them to execute. Provide with customers who are actively involved with a commitment to fix defects that they discover. OOA/D, BSIT-5th, Univesity of Education Okara 11
- 12. Acceptance Testing Similar to validation testing except that customers are present or directly involved. Usually the tests are developed by the customer OOA/D, BSIT-5th, Univesity of Education Okara 12
- 13. Test Methods White box or glass box testing Black box testing Top-down and bottom-up for performing incremental integration ALAC (Act-like-a-customer) OOA/D, BSIT-5th, Univesity of Education Okara 13
- 14. Test Types Functional tests Algorithmic tests Positive tests Negative tests Usability tests Boundary tests Startup/shutdown tests Platform tests Load/stress tests OOA/D, BSIT-5th, Univesity of Education Okara 14
- 15. Test Planning The Test Plan – defines the scope of the work to be performed The Test Procedure – a container document that holds all of the individual tests (test scripts) that are to be executed The Test Report – documents what occurred when the test scripts were run OOA/D, BSIT-5th, Univesity of Education Okara 15
- 16. Test Plan Questions to be answered: How many tests are needed? How long will it take to develop those tests? How long will it take to execute those tests? Topics to be addressed: Test estimation Test development and informal validation Validation readiness review and formal validation Test completion criteria OOA/D, BSIT-5th, Univesity of Education Okara 16
- 17. Entrance Criteria for Formal Validation Testing Software development is completed (a precise definition of “completed” is required. The test plan has been reviewed, approved and is under document control. A requirements inspection has been performed on the SRS. Design inspections have been performed on the SDDs (Software Design Descriptions). OOA/D, BSIT-5th, Univesity of Education Okara 17
- 18. Entrance Criteria for Formal Validation Testing (cont’d) Code inspections have been performed on all “critical modules”. All test scripts are completed and the software validation test procedure document has been reviewed, approved, and placed under document control. Selected test scripts have been reviewed, approved and placed under document control. OOA/D, BSIT-5th, Univesity of Education Okara 18
- 19. Entrance Criteria for Formal Validation Testing (cont’d) All test scripts have been executed at least once. CM tools are in place and all source code is under configuration control. Software problem reporting procedures are in place. Validation testing completion criteria have been developed, reviewed, and approved. OOA/D, BSIT-5th, Univesity of Education Okara 19
- 20. Exit Criteria for Validation Testing All test scripts have been executed. All SPRs have been satisfactorily resolved. (Resolution could include bugs being fixed, deferred to a later release, determined not to be bugs, etc.) All parties must agree to the resolution. This criterion could be further defined to state that all high-priority bugs must be fixed while lower-priority bugs can be handled on a case-by-case basis. OOA/D, BSIT-5th, Univesity of Education Okara 20
- 21. Exit Criteria for Validation Testing (cont’d) All changes made as a result of SPRs have been tested. All documentation associated with the software (such as SRS, SDD, test documents) have been updated to reflect changes made during validation testing. The test report has been reviewed and approved. OOA/D, BSIT-5th, Univesity of Education Okara 21
- 22. Test Estimation Number of test cases required is based on: Testing all functions and features in the SRS Including an appropriate number of ALAC (Act Like A Customer) tests including: Do it wrong Use wrong or illegal combination of inputs Don’t do enough Do nothing Do too much Achieving some test coverage goal Achieving a software reliability goal OOA/D, BSIT-5th, Univesity of Education Okara 22
- 23. Considerations in Test Estimation Test Complexity – It is better to have many small tests than few large tests. Different Platforms – Does testing need to be modified for different platforms, operating systems, etc. Automated or Manual Tests – Will automated tests be developed? Automated tests take more time to create but do not require human intervention to run. OOA/D, BSIT-5th, Univesity of Education Okara 23
- 24. Estimating Tests Required SRS Reference Estimated Number of Tests Required Notes 4.1.1 3 2 positive and 1 negative test 4.1.2 2 2 automated tests 4.1.3 4 4 manual tests 4.1.4 5 1 boundary condition, 2 error conditions, 2 usability tests … Total 165 OOA/D, BSIT-5th, Univesity of Education Okara 24
- 25. Estimated Test Development Time Estimated Number of Tests: 165 Average Test Development Time: 3.5 (person-hours/test) Estimated Test Development Time: 577.5 (person-hours) OOA/D, BSIT-5th, Univesity of Education Okara 25
- 26. Estimated Test Execution Time Estimated Number of Tests: 165 Average Test Execution Time: 1.5 (person-hours/test) Estimated Test Execution Time: 247.5 (person-hours) Estimated Regression Testing (50%): 123.75 (person-hours) Total Estimated Test Execution Time: 371.25 (person-hours) OOA/D, BSIT-5th, Univesity of Education Okara 26
- 27. Test Procedure Collection of test scripts An integral part of each test script is the expected results The Test Procedure document should contain an unexecuted, clean copy of every test so that the tests may be more easily reused OOA/D, BSIT-5th, Univesity of Education Okara 27
- 28. Test Report Completed copy of each test script with evidence that it was executed (i.e., dated with the signature of the person who ran the test) Copy of each SPR showing resolution List of open or unresolved SPRs Identification of SPRs found in each baseline along with total number of SPRs in each baseline Regression tests executed for each software baseline OOA/D, BSIT-5th, Univesity of Education Okara 28
- 29. Validation Test Plan IEEE – Standard 1012-1998 1. Overview a. Organization b. Tasks and Schedules c. Responsibilities d. Tools, Techniques, Methods 2. Processes a. Management b. Acquisition c. Supply d. Development e. Operation f. Maintenance OOA/D, BSIT-5th, Univesity of Education Okara 29
- 30. Validation Test Plan IEEE – Standard 1012-1998 (cont’d) 3. Reporting Requirements 4. Administrative Requirements 5. Documentation Requirements 6. Resource Requirements 7. Completion Criteria OOA/D, BSIT-5th, Univesity of Education Okara 30
- 31. Practical Usability Testing Capture whole page including web address Write briefly and clearly Point only main issues (bugs) Point one screenshot per issue Make final reporting document (RD) for bugs RD: http://jmp.sh/meF4kMP check test case demo, choose a website and report bugs. Graded assignment, ask questions on ComputingForum as well OOA/D, BSIT-5th, Univesity of Education Okara 31