Strategies For Software Test Documentation
Download as pptx, pdf10 likes11,459 views
Strategies For Software Test Documentation by Suriya G of Vishwak.com for Anna University Workshop on testing
More Related Content
What's hot (20)
Viewers also liked (19)
Similar to Strategies For Software Test Documentation (20)
Recently uploaded (20)
Strategies For Software Test Documentation
- 1. Strategies For Software Test Documentation Suriya G(suriyag at vishwak.com)Vishwak Solutions Pvt. Ltd.
- 2. Software Testing Software Testing is a process of evaluating a system against the requirements.
- 3. The testing can be done either Manually or by using Automated testing tools.
- 4. By giving Quality deliverables, Customer satisfaction is ensured.Principle of TestingTesting is the process of executing a program with an intent of finding error and it should be planned well before testing begins.Objective of Software TesterThe goal of a Tester is to find defects.
- 5. The goal of a Tester is to find defects as early as possible.
- 6. The goal of a Tester is to find defects and fix them.What is Defects ?There are various ways in which we can classify Defects. Below are some of the classifications:Wrong: The specifications have been implementedincorrectly. This defect is a variance from customer / userspecification. (correctly mentioned in specification butwrongly implemented)
- 7. Missing: A specified or wanted requirement is not in the built product. This can be a variance from specification, an indication that the specification was not implemented. (given in specification but missed out in application)
- 8. Extra: A requirement incorporated into the product thatwas not specified. This is always a variance fromspecifications, But this could be desired feature for the product. (Good to have)Verification and Validation (V&V)Verification: Refers to the set of activities that ensure the software correctly implements a specific function. "Are we building the product right "Validation: Refers to a different set of activities that ensure the software that has been built is traceable to customer requirements."Are we building the right product "
- 10. Software Testing DocumentationKISS principle - Rule for testing processes (an abbreviation for Keep It Smart, Short )Test Plan.
- 11. Test Case.
- 12. Test Procedure.
- 13. Test Log.
- 14. Test Report. Testing ProcessTest PlanDefine Test CasesRequire Analysis & DesignCreate TestDataTrackDefectsExecuteTestsAnalyzeresults
- 15. Definition of Test Plan:A document describing the scope, approach, resources, and schedule of intended testing activities. Table of contents of a test plan might contain the following.Roles & Responsibilities
- 16. Testing Schedules (testing tasks and milestones)
- 17. Environment Needs (hardware and software)
- 18. Test Items (what should be tested)
- 20. Test Recording procedures (test results must be systematically recorded)Sample Page for Test Case
- 21. Definition of Test Case:A set of test inputs, executions, and expected results developed for a particular objective.
- 22. Set of procedures written by a tester which execute in our system to find defect. -Positive test case. -Negative test case. A test case is said to be effective only when both positive and negative cases are prepared. Definition of Test Procedure:A document, providing detailed instructions for the [manual] execution of one or more test cases.
- 23. The procedure document describes how the tester will actually run the test, the physical set-up (Environment) required, and the procedures or steps that need to be followed. Definition of Test Log:The Test Log records the details of what Test Cases have been run, the order of running, and the results of those tests.
- 24. The results are either the test passed, meaning that the actual and expected results were identical, or it failed meaning that there was a discrepancy.
- 25. If there is a discrepancy than one or more Test Incident Reports are raised or updated, and their identities recorded on the Test Log.Depositary of Document: There are many way to have the sources of the document. Like Google docs,share point , VSS(Visual Sources Safe), etc...
- 26. Definition of Test Report:To gratify the customer or client’s demand; one must perform complete software testing activities on the application before the deployment as its stated that “No Software Exists Without a BUG”; while performing those actions if any ambiguity found then the tester should report the bug and notify the developer.
- 27. Elimination of bug from the software needs to follow the proper steps formerly known as BUG LIFE CYCLE; the structure of it varies from organization to organization but the basic flow will remain the same. Bug life cycle
- 28. Bug Life Cycle and DescriptionOpen: Tester finds a ‘bug’ and posts it with the status OPEN. This bug is yet to be studied/assigned.
- 29. Assign: The assigned Developer’s responsibility is now to fix the bug and have it RESOLVED or give valid reasons.
- 30. Resolved: Developer fixes the bug that is ASSIGNED. Now, the ‘resolved’ bug needs to be verified by the Tester (retesting / regression .Bug Life Cycle and Description
- 31. Deferred / Waived: If lead / verifier / developer considers that the bug is “Not valid” then they should give valid reasons to change the status to Deferred or Waived.
- 32. Re-Opened: If bug still exists not satisfied with the solution in the new build then tester should open the bug again by selecting the status as RE-OPENED.
- 33. Closed: If bug is successfully resolved and verified by the tester then its status should be marked as CLOSED.Priority and SeveritySeverity - Severity is how seriously the bug is impacting the application
- 34. Priority - Priority is the order in which developer has to fix the bug.
- 35. High Priority & High Severity: A show stopper error which occurs on the basic functionality of the application. (E.g.. A site maintains the student details on saving record if it doesn't allow to save the record then this is high priority and high severity bug.)
- 36. High Priority & Low Severity: The spell mistakes that happens on the cover page or heading or title of an application.
- 37. High Severity & Low Priority: The application generates a show stopper or system error but on click of link which is rarely used by the end user.
- 38. Low Priority and Low Severity: Any cosmetic or spell issues which is with in a paragraph or in the report (Not on cover page heading title).SummarySoftware Testing - A process of evaluating a system against the requirements.
- 39. Software Tester - The goal of a Tester is to find defects as early and fix them.
- 40. Defects - Wrong,Missing and Extra
- 41. V&V - Verification "Are we building the product right " and Validation "Are we building the right product "
- 42. Testing Documentation - Test Plan, Test Case, Test Procedure, Test Log, Test Report.
- 43. Test Plan - A document describing the scope, approach, resources, and schedule of intended testing activities.
- 44. Test Case - A set of test inputs, executions, and expected results developed for a particular objective.
- 45. Test Procedure - A document, providing detailed instructions for the execution of one or more test cases.
- 46. Test Log - The Test Log records the details of what Test Cases have been run, the order of running, and the results of those tests.
- 47. Test Report - while performing test actions if any ambiguity found then the tester should report the bug and notify the developer.Thank You !!!!!!!!