Writing good test cases

Introduction

1. 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.
2. Attempt to make your test cases ‘atomic’.
3. Ensure that all positive scenarios and negative scenarios are covered.
4. Language: Write in simple and easy to understand language.
5. Use active voice: Do this, do that.
6. Use exact and consistent names (of forms, fields, etc).

Characteristics of a good test case:

1. Accurate: Exacts the purpose.
2. Economical: No unnecessary steps or words.
3. Traceable: Capable of being traced to requirements.
4. Repeatable: Can be used to perform the test over and over.
5. Re-usable: Can be reused if necessary.

Tips for Writing Effective Test Cases for Any Application:

1. Test Case Naming Conventions: Name the Test Cases so to represent the module name or functional area you are going to verify in that test case.
2. Description: Enter as much information as possible in Description!
3. Assumptions and Preconditions: Make sure to add as much information as possible for any conditions to be met before running the test case.
4. Input Test Data: To make your life easy as a tester (and your fellow-testers!), wherever applicable, you can give Test Data to be used for the Test Case within TC Description or with the specific Test Case step. This saves a lot of time in the long run as you won’t have to hunt a new test data every time you need to execute the test.
5. Cover all Verification Points in Test Design Steps: The Test Design Steps should not only cover the functional flow but also each verification point which should be tested!
6. Attach the Relevant Artifacts: Wherever possible you should attach the relevant artifacts to your test case.
7. Expected Result: Each test design step should clearly mention what you expect as outcome of that verification step. So, while writing test cases, mention in detail what specific page/screen you expect to appear after the test and or any changes you expect to be done to any back-end legacy systems or Database. You can also 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.
8. Legible & Easily Understandable by Others: You should write Test Cases that: Are to-the-point! You don’t have to be writing essays! (wherever you feel any Test Case is going beyond a certain amount of steps, feel free to break it into a new Test Case) Still have enough coverage
9. Review: Review can be done by peer testers (termed as ‘Peer Review’), BA, developers,PM, product owners or any relevant stakeholders.
10. Re-usable: You should write test cases keeping in mind that they could be re-used in the future for some other project/teams. On that note, before writing a new Test Case for your project/module, always try and find out if there are Test Cases written already for the same area. That really saves a lot of time!
11. Maintenance & Updates: Always consider updating the existing Test Cases (if any) before you start writing New Test Cases!
12. Post Conditions: 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 instructions to restore the system to its original state for it not to interfere with subsequent testing.