Test case writing
Download as PPTX, PDF2 likes537 views
Test cases are documents that contain test data, preconditions, test steps, expected results, and postconditions to verify a specific requirement. They provide a starting point for test execution and leave the system in a defined state. Good test cases are accurate, economical, traceable, repeatable, reusable, simple, objective, relevant, avoid duplication and dependency. Test cases should be written based on requirements documents and cover both positive and negative scenarios using clear language. An ideal test case includes an ID, use case ID, test objective, preconditions, test data, test steps, expected results, actual results, cycle, date, tester, status, severity, and resolution status.
Test case writing
- 2. What is Test Case? ■ A test case is a document, which has a set of test data, preconditions, test steps, expected results and post conditions, developed for a particular test scenario in order to verify compliance against a specific requirement. ■ Test Case acts as the starting point for the test execution, and after applying a set of input values; the application has a definitive outcome and leaves the system at some end point or also known as execution post condition. ■ The process of developing test cases can also help find problems in the requirements or design of an application. ■ In general we can say that a test case tells us what need to be done to test a system. It gives us the steps which we execute in a system using the input data values which we enter in the system, it also gives us the expected results which should come when we execute a particular test case.
- 3. Issues to remember while writing test case As far as possible, write test cases in such a way that you test only one thing at a time. Do not overlap or complicate test cases. Attempt to make your test cases ‘atomic’. Ensure that all positive scenarios and negative scenarios are covered. Language: – Write in simple and easy to understand sentences. – Use active voice: Do this, do that. – Use exact and consistent names (of forms, fields, etc.). – Avoid writing multiple and complex sentences. – Make sentences specific and to the point. – Write relevant values. (for test data) – Avoid redundant sentences.
- 4. CHARACTERISTICS OF A GOOD TEST CASE – Accurate: Exacts the purpose. – Economical: No unnecessary steps or words. – Traceable: Capable of being traced to requirements. – Repeatable: Can be used to perform the test over and over. – Reusable: Can be reused if necessary. – Simple: Test steps should be simple and easily understandable. – Objective: Test case should be objective and should only give the specific outcome. One test case should not give multiple outcomes. – Relevant: Test case should not be irrelevant and should be within the context of the system. – Duplication: Test case should not duplicate other test cases. – Dependency: Test case should not depend on other test cases. – Correspondent: Test case should follow the preconditions and test data.
- 5. Resources ■ The resources that are generally used for writing test cases are: – Business Requirements Document (BRD) – Functional Requirements Document (FRD) – System Requirements Specification (SRS) ■ A good test case cover the aspect of the requirement described in these documents and checks whether the purpose of the requirement is met successfully or not. A good test case ensures that the goal of a particular requirement is met in the way as it is told. That is, besides checking whether the requirement is fulfilled or not, a good test case also maintains the flow of the process to reach the goal of that particular requirement via its test steps. ■ There can be test cases that are outside of the context of these documents as documents sometimes lack some specifications of the application. But test cases must be within the context of the application.
- 6. Importance of Test Case Test cases organize the whole testing process. If the test cases are prepared keeping in mind the requirements of a particular system then they really helps a lot in checking whether the requirements are fulfilled or not. While doing ad hoc testing, one may neglect or skip functionality or a bug which will definitely be caught when the system or site will be live or when it will be tested from the client’s end and it is going to affect the company’s credibility. We have heard from Big Brains that no software is bug free. But care should be taken so that all the possible bugs are eliminated from the system before it goes live. Test cases help a lot in this. With the help of proper test cases, a Quality Assurance Engineer should make sure that the system’s features & functionalities are working fine and are bug free.
- 7. Ideal Test Case Steps Test Case Id. ■ Unique Test Case Identification Number. This id can be combined of many sections. ■ Example: SF_MIS_LOGIN_001 Use Case ID ■ Unique Use Case Identification Number from the requirement documents like BRD or SRS. Test Objective ■ What is the main purpose or target of this test case. ■ Example: Suppose you are going to test the login page. So one of the Test Objective can be like “To test the login page’s remember me option”.
- 8. Pre-Conditions ■ Sometimes there can be some dependency to execute the test case, then that dependency can be considered as Pre-conditions. ■ Example: If any system provides report & gives an option to export it in an excel sheet, then configuring excel support in the device is a pre-condition to test this option. Test Data ■ Test Data is some pre-defined or fixed data to check any option or test case. ■ Example: A numeric field only takes even number. So before start testing process we can fix the inputs like 2n+2. So 2, 4, 6, 8… are the test data for this test case. Test Steps ■ Details of the procedure to continue the test case process. ■ Example: In any system the objective of the test case is “Appears application splash screen as the first screen”. So the Test Steps can be 1. Launch the application. 2. Check if texts are appearing correctly as referred to the UX Specification document.”
- 9. Expected results ■ The output of the process we have done while executing test case. ■ Example: If the process is “2*2”, then the expected result would be “4”. Actual results ■ The result system gives a tester after executing a test case. Cycle ■ A system can be tested several times. So tester can maintain a cycle number for better understanding the changes of the testing process. Date of execution ■ The day of executing the test case Tested by ■ Name of the tester
- 10. Test Status ■ Passed or Failed. When “actual results = expected results” the executed test case is passed. Otherwise failed. Attachment ■ Taking the screenshot or make the video of the process while testing related with the test case. It is better to mark the fault point on the image or video. Defect Severity ■ The degree of impact that a defect has on the development or operation of a component or system. This step is for failed test cases. There is several level of the failure for any test case. These levels are a) Critical, b) Major/High, c) Medium, d) Minor/Low.
- 11. Critical: The defect affects critical functionality or critical data. It does not have a workaround. Example: Unsuccessful installation, complete failure of a feature, Showing development level pages on the front end. Major/High: The defect affects major functionality or major data. It has a workaround but is not obvious and is difficult. Example: A feature is not functional from one module but the task is doable if 10 complicated indirect steps are followed in another module/s. Medium: The defect affects minor functionality or non-critical data. It has an easy workaround. Example: A minor feature that is not functional in one module but the same task is easily doable from another module. Minor/Low: The defect does not affect functionality or data. It does not even need a workaround. It does not impact productivity or efficiency. It is merely an inconvenience. Example: Petty layout discrepancies, spelling/grammatical errors.
- 12. Defect Status (QA) – Open / Reopened / Retest In Production / Closed – Open: Initial status of any failed test case. Generally it occurs in cycle 1 testing. – Reopened: If the test case again fails in cycle of retesting, then the defect status will be changed into “Reopened”. – Retest In Production: Testing process on going state. – Closed: When the failed test case passes, then the status will be changed into closed. Resolution Status (developer) – This field will be updated by the developing team. The status can be Fixed / Future/ In- Progress/ Not A Fault. – N.B.: Only this field will be used by the developing team.
- 13. Date of closing ■ The date when a failed test case finally passed. Comment ■ If there is anything more to say about the test case. It can be used by both QA & Developing team.