Test Case Writing Best Practices


Published on

How to Write Test Cases to make it more informative and clear

Published in: Technology, Business
No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

Test Case Writing Best Practices

  1. 1. ISO 9001:2000 Certified
  2. 2. <ul><ul><li>“ 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.” (IEEE) </li></ul></ul><ul><ul><li>In General a test case basically is a brief statement of something that should be tested </li></ul></ul>
  3. 3. <ul><li>The basic objective of writing test cases is to validate the testing coverage of the application. If you are working in any CMMI company then you will strictly follow test cases standards. So writing test cases brings some sort of standardization and minimizes the ad-hoc approach in testing. </li></ul>
  4. 4. <ul><li>Find defects </li></ul><ul><li>Maximize bug count </li></ul><ul><li>Block premature product releases </li></ul><ul><li>Help managers make ship / no-ship decisions </li></ul><ul><li>Minimize technical support costs </li></ul><ul><li>Assess conformance to specification </li></ul><ul><li>Conform to regulations </li></ul><ul><li>Minimize safety-related lawsuit risk </li></ul><ul><li>Find safe scenarios for use of the product </li></ul><ul><li>Assess quality </li></ul><ul><li>Verify correctness of the product </li></ul><ul><li>Assure quality </li></ul>
  5. 5. Information Objectives Test Attributes Testing Styles / Paradigms
  6. 6. <ul><li>Read Specification and Requirements Carefully </li></ul><ul><li>Be clear with the design and the implementation details </li></ul><ul><li>Analyze and Identify all possible scenarios </li></ul><ul><li>Identify the test environments and test types </li></ul><ul><li>Should have detailed information related and affected areas of the requirement </li></ul><ul><li>Should be clear of behavior under failure condition(invalid input, boundary values etc) </li></ul>
  7. 7. <ul><li>Easy to determine the result </li></ul><ul><li>Tests are viewed one after the other in quick succession, usually in groups of several hundred to a thousand. As such, it is important that the results be easy to interpret. </li></ul><ul><li>Quick to determine the result </li></ul><ul><li>The tests should need no more than a few seconds to convey their results to the tester. </li></ul><ul><li>Self explanatory </li></ul><ul><li>The tests should not need an understanding of the specification to be used. </li></ul><ul><li>Short </li></ul><ul><li>Tests should be very short (a paragraph or so) and certainly not require scrolling on even the most modest of screens, unless the test is specifically for scrolling or paginating behaviour. </li></ul><ul><li>Valid </li></ul><ul><li>Unless specifically testing error-recovery features, the tests should all be valid. </li></ul><ul><li>Cross-platform </li></ul><ul><li>Test should be as cross-platform as reasonably possible, working across different devices, screen resolutions, paper sizes, etc. Exceptions should document their assumptions. </li></ul><ul><li>Note: Properly written test cases helps both testers as well as developers while execution and debugging </li></ul>
  8. 8. <ul><li>Use Active Case say Do This, Do That </li></ul><ul><li>System Display this, Do That </li></ul><ul><li>Simple Conversational Language </li></ul><ul><li>Exact, consistent names of fields, not generic </li></ul><ul><li>Don’t explain windows basics </li></ul><ul><li>10-15 steps or less. In case of integration test cases try to provide references instead of explaining the functionality again and again </li></ul><ul><li>Always update your test case with the new build </li></ul><ul><li>Follow Naming Convention – Naming Convention helps you to differentiate between function, control, dbname etc . It help in easy identification of different controls, functions, Labels , hyperlink etc. </li></ul><ul><li>Note: The naming conventions and practices may vary from project to project. </li></ul>
  9. 9. <ul><li>The scenario/test case for different module should be mentioned in a single worksheet in a single file. The name of the excel file should be TypeofTesting_ModuleName </li></ul><ul><li>Module names should be in Capitals and Bold </li></ul><ul><li>Screen Names should be bold and have camel notation i.e., the first word in capital letters and rest all in small letters. </li></ul><ul><li>All the objects like textbox, listbox,Checkbox,radio buttons etc should be in italics and bold </li></ul><ul><li>The link names should be mentioned in Italics, bold and underline below the word e.g.,' Sign Out’ link should be mentioned as ‘ Sign Out ’ </li></ul><ul><li>Database table name should be in caps e.g.,Emp_Details table name should be EMP_DETAILS </li></ul>
  10. 10. <ul><li>Test Case Id – Must be Unique across the application </li></ul><ul><li>Test case description - The test case description must be very brief </li></ul><ul><li>Test Case Priority – Priority of the test case </li></ul><ul><li>Test case Type – To identify the type of test case </li></ul><ul><li>Precondition – what should be present in the system, before the test can be executed </li></ul><ul><li>Assumption or Dependencies – (Helps to identify related code or functionalities and features) </li></ul><ul><li>Test Inputs - The test input is nothing but the test data that is prepared to be fed to the system </li></ul><ul><li>Validation Input – step by step instructions on how to carry out the test </li></ul><ul><li>Expected Result– How the system must react based on the test steps </li></ul><ul><li>Actual Result – The actual output </li></ul><ul><li>Post Conditions – State after the test case is executed </li></ul><ul><li>Execution Result(Pass/Fail) – Your actual result based on expected and actual result </li></ul><ul><li>Build Number – To keep track of results </li></ul>
  11. 11. <ul><li>Write test cases before implementation of requirement </li></ul><ul><li>Test cases are written for all the requirements. Test case should map to current requirement and should not be an enhancement to the application. </li></ul><ul><li>Follow a standard template for all test cases </li></ul><ul><li>Use very simple English and general words </li></ul><ul><li>Format followed( Alignment, Naming convention etc) by test cases should be uniform for the entire application </li></ul><ul><li>All the scenario/Test Case should be easily understable,clear and to the point </li></ul><ul><li>Highlight important points by making text bold or assigning it a color or writing it in different font </li></ul><ul><li>You may add sections to a group of test cases to make it more informative </li></ul><ul><li>You may use double quotes for a particular display text </li></ul><ul><li>Maintain the test cases in a flow so that execution order is maintained and time is saved. Whenever a new scenario/test case is been added between two existing one it should be named after the previous scenario/Test case Id with decimal places ie.,if we have added new scenario between ID ST-SA–BKG-0015,then new scenario ID will be ST-SA-BKG-0015.1 </li></ul><ul><li>[ contd…] </li></ul>
  12. 12. <ul><li>Use bullet points for different steps </li></ul><ul><li>Specify Test case type and priority which would help in determining whether to run the test case in specific scenario or not(Shortage of time etc) </li></ul><ul><li>The prerequisite for the scenario/test case should be mentioned before the test case </li></ul><ul><li>Use a mix of both ‘positive and negative’ tests </li></ul><ul><li>Provide test data(if possible) </li></ul><ul><li>Write in details SQL Queries(it will save time while executing) </li></ul><ul><li>Add reference to bugs or requirement as per your needs </li></ul><ul><li>Defect ID of a Scenario/TestCase should match the Defect ID submitted against the defect in Defect Tracking System </li></ul><ul><li>Add some notes in case you want to convey additional information or explain the test case with example in case the scenario is not much clear </li></ul><ul><li>You can use build number next to your result to keep a track of results or determining defect density </li></ul><ul><li>Note:Test case should be such that any person going to execute it or read it gets a clear picture of what needs to be done without needing any explanations </li></ul>
  13. 14. <ul><li>There’s no simple formula or prescription for generating “good” test cases. </li></ul><ul><li>There are tests that are good for your purposes , for bringing forth the type of information that you’re seeking. </li></ul><ul><li>Given a purpose, we can evaluate tests as better or worse along several dimensions , in terms of how they advance that purpose. </li></ul><ul><li>Many test groups stick with a few types of tests. To achieve the broad range of value from our tests, we have to use a broad range of techniques, consciously selected to help us achieve our information goals. </li></ul>