Strategies For Software Test Documentation

12,649 views

Published on

Strategies For Software Test Documentation by Suriya G of Vishwak.com for Anna University Workshop on testing

Published in: Technology, Education
1 Comment
8 Likes
Statistics
Notes
No Downloads
Views
Total views
12,649
On SlideShare
0
From Embeds
0
Number of Embeds
2,940
Actions
Shares
0
Downloads
505
Comments
1
Likes
8
Embeds 0
No embeds

No notes for slide

Strategies For Software Test Documentation

  1. 1. Strategies For Software Test Documentation <br />Suriya G<br />(suriyag at vishwak.com)<br />Vishwak Solutions Pvt. Ltd.<br />
  2. 2. Software Testing <br /><ul><li>Software Testing is a process of evaluating a system against the requirements.
  3. 3. The testing can be done either Manually or by using Automated testing tools.
  4. 4. By giving Quality deliverables, Customer satisfaction is ensured.</li></li></ul><li>Principle of Testing<br />Testing is the process of executing a program with an intent of finding error and it should be planned well before testing begins.<br />Objective of Software Tester<br /><ul><li>The goal of a Tester is to find defects.
  5. 5. The goal of a Tester is to find defects as early as possible.
  6. 6. The goal of a Tester is to find defects and fix them.</li></li></ul><li>What is Defects ?<br />There are various ways in which we can classify Defects. Below are some of the classifications:<br /><ul><li>Wrong: The specifications have been implementedincorrectly. This defect is a variance from customer / userspecification. (correctly mentioned in specification butwrongly implemented)
  7. 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. 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)</li></li></ul><li>Verification and Validation (V&V)<br /><ul><li>Verification: Refers to the set of activities that ensure the software correctly implements a specific function.</li></ul> "Are we building the product right "<br /><ul><li>Validation: Refers to a different set of activities that ensure the software that has been built is traceable to customer requirements.</li></ul>"Are we building the right product "<br />
  9. 9.
  10. 10. Software Testing Documentation<br />KISS principle  - Rule for testing processes<br /> (an abbreviation for Keep It Smart, Short )<br /><ul><li>Test Plan.
  11. 11. Test Case.
  12. 12. Test Procedure.
  13. 13. Test Log.
  14. 14. Test Report. </li></li></ul><li>Testing Process<br />Test Plan<br />Define<br /> Test Cases<br />Require Analysis <br />& Design<br />Create Test<br />Data<br />Track<br />Defects<br />Execute<br />Tests<br />Analyze<br />results<br />
  15. 15. Definition of Test Plan:<br /><ul><li>A document describing the scope, approach, resources, and schedule of intended testing activities. </li></ul> Table of contents of a test plan might contain the following.<br /><ul><li>Roles & Responsibilities
  16. 16. Testing Schedules (testing tasks and milestones)
  17. 17. Environment Needs (hardware and software)
  18. 18. Test Items (what should be tested)
  19. 19. Risk and Constraints
  20. 20. Test Recording procedures (test results must be systematically recorded)</li></li></ul><li>Sample Page for Test Case <br />
  21. 21. Definition of Test Case:<br /><ul><li>A set of test inputs, executions, and expected results developed for a particular objective.
  22. 22. Set of procedures written by a tester which execute in our system to find defect. </li></ul> -Positive test case.<br /> -Negative test case. <br /><ul><li>A test case is said to be effective only when both positive and negative cases are prepared. </li></li></ul><li>Definition of Test Procedure:<br /><ul><li>A document, providing detailed instructions for the [manual] execution of one or more test cases.
  23. 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. </li></li></ul><li>Definition of Test Log:<br /><ul><li>The Test Log records the details of what Test Cases have been run, the order of running, and the results of those tests.
  24. 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. 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.</li></li></ul><li>Depositary of Document: <br />There are many way to have the sources of the document. Like Google docs,share point , VSS(Visual Sources Safe), etc... <br />
  26. 26. Definition of Test Report:<br /><ul><li>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. 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. </li></li></ul><li>Bug life cycle<br />
  28. 28. Bug Life Cycle and Description<br /><ul><li>Open: Tester finds a ‘bug’ and posts it with the status OPEN. This bug is yet to be studied/assigned.
  29. 29. Assign: The assigned Developer’s responsibility is now to fix the bug and have it RESOLVED or give valid reasons.
  30. 30. Resolved: Developer fixes the bug that is ASSIGNED. Now, the ‘resolved’ bug needs to be verified by the Tester (retesting / regression .</li></li></ul><li><ul><li>Bug Life Cycle and Description
  31. 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. 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. 33. Closed: If bug is successfully resolved and verified by the tester then its status should be marked as CLOSED.</li></li></ul><li>Priority and Severity<br /><ul><li>Severity - Severity is how seriously the bug is impacting the application
  34. 34. Priority - Priority is the order in which developer has to fix the bug.
  35. 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. 36. High Priority & Low Severity: The spell mistakes that happens on the cover page or heading or title of an application.
  37. 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. 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).</li></li></ul><li>Summary<br /><ul><li>Software Testing - A process of evaluating a system against the requirements.
  39. 39. Software Tester - The goal of a Tester is to find defects as early and fix them.
  40. 40. Defects - Wrong,Missing and Extra
  41. 41. V&V - Verification "Are we building the product right " and Validation "Are we building the right product "
  42. 42. Testing Documentation - Test Plan, Test Case, Test Procedure, Test Log, Test Report.
  43. 43. Test Plan - A document describing the scope, approach, resources, and schedule of intended testing activities.
  44. 44. Test Case - A set of test inputs, executions, and expected results developed for a particular objective.
  45. 45. Test Procedure - A document, providing detailed instructions for the execution of one or more test cases.
  46. 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. 47. Test Report - while performing test actions if any ambiguity found then the tester should report the bug and notify the developer.</li></li></ul><li>Thank You !!!!!!!!<br />

×