Test Cases Maintaining & Documenting


Published on

Published in: Technology, Business
1 Comment
  • helo it is good........... i need a copy of this pls send it to my mail id........ honey4u037@gmail.com
    Are you sure you want to  Yes  No
    Your message goes here
No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

Test Cases Maintaining & Documenting

  1. 1. Revant Pande and Ali Marjaie
  2. 2. WHAT IS A TEST CASE? IEEE Standard 610 (1990) defines test case as follows: A set of test inputs, execution conditions, and expected results developed for a particular objective, such as to exercise a particular program path or to verify compliance with a specific requirement.
  3. 3. DESIGN <ul><li>To conceive or fashion in the mind; invent: design a good reason to attend the STAR testing conference. To formulate a plan for; devise: design a marketing strategy for the new product. </li></ul><ul><li>To plan out in systematic, usually documented form: design a building; design a test case. </li></ul><ul><li>To create or contrive for a particular purpose or effect: a game designed to appeal to all ages. </li></ul><ul><li>To create or execute in an artistic or highly skilled manner. </li></ul>
  4. 4. COMPONENTS OF TEST CASES <ul><li>Well designed test cases are composed of three parts: </li></ul><ul><li>Inputs </li></ul><ul><li>Outputs </li></ul><ul><li>Order of execution </li></ul>
  5. 5. TEST CASE SPECIFICATION <ul><ul><li>Test Case Specification Identifier </li></ul></ul><ul><ul><li>Test Items </li></ul></ul><ul><ul><li>Input Specifications </li></ul></ul><ul><ul><li>Output Specifications </li></ul></ul><ul><ul><li>Environmental Needs </li></ul></ul><ul><ul><li>Special Procedural Requirements </li></ul></ul><ul><ul><li>Intercase Dependencies </li></ul></ul>
  6. 6. TEST CASE DESIGN <ul><li>It is the responsibility of the testers to design tests that </li></ul><ul><li>Reveal defects </li></ul><ul><li>Can be used to evaluate software performance, usability, and reliability. </li></ul><ul><li>BY AN EFFECTIVE TEST CASE WE MEAN ONE THAT HAS A GOOD POSSIBILITY OF REVEALING A DEFECT </li></ul>
  7. 7. ADVANTAGES OF EFFECTIVE TEST CASES <ul><li>If test cases are effective there is :- </li></ul><ul><li>A greater probability of detecting defects. </li></ul><ul><li>A more efficient use of organizational resources. </li></ul><ul><li>A higher probability for test reuse. </li></ul><ul><li>Closer adherence to testing and project schedules and budgets. </li></ul><ul><li>The possibility for delivery of a higher-quality software product. </li></ul>
  8. 8. BLACK BOX & WHITE BOX TESTING <ul><li>The Black Box Approach </li></ul><ul><ul><li>A tester considers the software-under test to be an opaque box. </li></ul></ul><ul><li>The White Box Approach </li></ul><ul><ul><li>Focuses on the inner structure of the software to be tested. </li></ul></ul>
  10. 10. HOW TO WRITE GOOD TEST CASES? <ul><li>Write a test plan and test cases </li></ul><ul><li>Use templates with caution </li></ul><ul><li>Assume that you will not be performing the test </li></ul><ul><li>Write the test objectives as hypotheses </li></ul><ul><li>Use a mix of valid and invalid tests </li></ul><ul><li>Documenting Test Results </li></ul>
  11. 11. INFORMATION REQUIRED WHILE DOCUMENTING TEST RESULTS <ul><li>Tester's name and department </li></ul><ul><li>Date and time the test was performed </li></ul><ul><li>Name & Version of the operating system </li></ul><ul><li>Full description of the results </li></ul><ul><li>Resolution of any problem </li></ul>
  12. 12. ADVANTAGES AND DISADVANTAGES OF DOCUMENTATION <ul><li>Advantages </li></ul><ul><li>1. Gives an approach, Description, Pre-conditions to achieve the expect result. </li></ul><ul><li>2. Test Cases are useful while writing Traceability Matrix. </li></ul><ul><li>3. It shows or avails the traceability of the entire requirements. </li></ul><ul><li>Disadvantages </li></ul><ul><li>1. Without or miswritten Test Cases or human errors in the Test Cases cause the project failure. </li></ul>
  13. 13. HOW TO PRIORITIZE TEST CASES <ul><li>There are two different methods to determine priorities: </li></ul><ul><li>  </li></ul><ul><li>  Using an informal method - Gathering the information and estimate the priority. </li></ul><ul><li>Using a formal method - FMEA. </li></ul>
  14. 14. METHOD 1 - INFORMAL <ul><li>         The following may be the example for the priority scale 1-4 </li></ul><ul><li>P1 - These are the test cases that are run first to determine if a given build is even testable. </li></ul><ul><li>       </li></ul><ul><li>P2 - These are the test cases that are executed the most often to ensure functionality is stable, intended behaviors and capabilities are working. </li></ul><ul><li>P3 - These are the test cases where the testing of a given functional area or feature is to get more detailed and the majority of aspects for the function are examined including boundary, error and configuration tests. </li></ul><ul><li>P4 - These are the test cases that are frequently tested. They are may or may not be tested. It does’nt mean those are not important but just that they are not run often in the life of the project. </li></ul>
  15. 15. Method 2 – FORMAL <ul><li>FMEA is a technique for systematically identifying potential failures in a system or process. It can also be used for understanding and prioritizing possible failure modes. But use FMEA only if it is appropriate. </li></ul>
  16. 17. <ul><li>Q? </li></ul><ul><li>THANK YOU </li></ul>