Best Practices for Test Case Writing
- 1. Created by: Sarah Goldberg July 14, 2014 Version 1.0
- 2. A Test Case is simply a list of actions which need to be executed to verify a particular functionality or feature of your application under test. It might take more than one test case to determine the true functionality of the application being tested. Every requirement or objective to be achieved should have at least one test case.
- 3. • Level 1: In this level you will write the basic test cases from the available specification and user documentation. • Cover the entire positive scenarios first and then think about all possibilities of negative scenarios; these will effectively find most of the bugs. • Level 2: This is the practical stage in which writing test cases depend on actual functional and system flow of the application.
- 4. • Level 3: This is the stage in which you will group some test cases and write a test procedure. Test procedure is nothing but a group of small test cases maximum of 10. • Level 4: Automation of the project. This will minimize human interaction with system and thus QA can focus on current updated functionality's to test rather than remaining busy with regression testing.
- 6. Name your test cases in a way that makes sense to anyone who is going to refer the test in future. It should represent the module name or functional area you are going to verify in the test case. For example, if I am working on a project “Online” which has a functional area called “Login” and want to write a test to verify a simple check whether the user is able to login to the website using an email and password • Online_Login_ValidCredentials • Online_Login_InvalidCredentials Test Case Naming Conventions
- 7. Where you mention all the details about what you are going to test, and the particular behavior being verified by the test. The following information would be found in a well- written test case description: • Test to be carried out / behavior being verified • Preconditions and Assumptions (any dependencies) • Test Data to be used • Test Environment Details (if applicable) • Any Testing Tools to be used for the test Try to place yourself in the shoes of someone who is entirely unfamiliar with the function to be tested, and make sure they can successfully complete the test simply by following the procedure. As much as possible, without compromising comprehensiveness, try to write the test case such that it will not go 'stale'. Try to ensure your test case will be usable for a long time without regular editing. Description
- 8. Communicate all assumptions that apply to a test, along with any preconditions that must be met before the test can be executed. Below are the kinds of details that should be covered in this section: • Any user data dependency (e.g. the user should be logged in, which page should the user start the journey, etc.) • Dependencies on test environment • Any special setup to be done before Test Execution • Dependencies on any other test cases – does the Test Case need to be run before/after some other Test Case? Assumptions and Preconditions
- 9. A few pointers: • In many cases where you know the test data can be re-used over time, you can mention the exact Test Data to be used for the test. • If the test only involves some values to be verified, you can opt to specify the value range or describe what values are to be tested for which field. • Testing with every value is impractical, so you can choose a few values from each equivalence class which should provide good coverage for your test. • You could also decide to mention the type of data which is required to run the test and not the real test data value. This applies for projects where the test data keeps on changing as multiple teams use it and may not be in the same state when I use it the next time. Input Test Data
- 10. The test case steps should not only cover the functional flow but also each verification point which should be tested. By comparing your Test Case steps with the Requirement documents, Use Cases, User Stories or Process Maps given for your project, you can make sure that the Test Case optimally covers all the verification points. Cover Verification Points in Test Steps
- 11. Wherever possible you should attach the relevant artifacts to your test case. If the change you are going to test is very minor, you could consider mentioning it in the test step itself. Attach the Relevant Artifacts
- 12. A well-written Test Case clearly mentions the expected result of the application/system under test. Each test design step should clearly mention what you expect as outcome of that verification step. • mention in detail what page/screen you expect to appear after the test • any changes you expect to be done to any backend legacy systems or Database. Attach screenshots or specification documents to the relevant step and mention that the system should work as outlined in the given document to make things simpler. Expected Result
- 13. Consider breaking down the test cases into sets and sub-sets to test some special scenarios like browser specific behaviors, cookie verification, usability testing, Web Service Testing and checking error conditions etc. • For example, if you need to verify how the login feature for any application works with invalid input, you can break this negative testing for login functionality into sub tests for different values like: • Verify with invalid email-id • Verify with invalid password • Verify with blank email-id field and so on… Divide Special Functional Test Cases into Sets
- 14. When designing test cases, consider that they will not always be executed by the ones who design them. Write Test Cases that: • Are Simple and easily understandable by everyone • Are to-the-point. If a Test Case is going beyond a certain amount of steps, break it into a new Test Case • Still have enough coverage Legible & Easily Understandabl e by Others
- 15. With Test Cases playing an important role in Software Testing Life-cycle, making sure they are correct and conform to standards becomes even more necessary. Test case review can be done by peer testers, BA, developers, product owners or any relevant stakeholders. Review
- 16. Test Cases can be re-used in the future for other projects. Before writing a new test case for your project/module, look for existing test cases. This way you won’t risk repeating any test cases and can avoid any redundancies in Test Management Tools. If there is an existing test case written around the same module, you should be updating it instead of writing a new test case. If you need a particular test case to execute some other test case, you can simply call the existing test case in the preconditions or at the specific test design step. Reusable
- 17. It’s very important that test cases are always updated, as per the newly introduced changes in the application they apply to. • Always consider updating the existing Test Cases (if any) before you start writing New Test Cases. Reiterating reusability, in case of any changes to an existing page or functionality, consider updating the existing test cases instead of writing any new test cases hence avoiding redundancies to the existing set. This also makes sure you always have updated Test Cases for any ‘journey’ in your application. Maintenance & Updates
- 18. Post-conditions basically specify the various things that need to be verified after the Test has been carried out. In addition, post-conditions are also used to give guiding instruction to restore the system to its original state for it not to interfere with subsequent testing. • For example, mentioning the changes to be made to test data so it can be used for a later test case with the same functionality. Post Conditions
- 19. Use the Test Case Area Classification to ‘link’ the cases together and ensure they can easily be found both manually and automatically. You should always use the appropriate area whenever creating a test case in order to help people locate the test case in the future. Test Case Area Classification