The Art of Writing Good Test Cases

In Software Testing, terms like test cases and bugs are heard mentioned often. Even while planning for application testing, it is estimated that seventy percent of the effort goes towards test case design and test case execution.

However, what exactly is a test case? We define a test case as being a written document that provides comprehensive information on what, and how to test. A test case contains details such as the objective, description, exact steps, and most important of all, the expected output of the planned test.

How can writing good Test Cases be beneficial?

Finding a tester who is unaware of the importance of test cases is a rare case but not every tester considers test case writing to be an essential phase of the QA cycle. Sometimes test cases are written as though they were just a regular routine task with little to no care, which leads to poor quality test cases. Writing strong and complete test cases offer numerous benefits to the individual running the test case, as well as to the overall project in the following ways:

• Reduces review and execution effort – A well-written test case is easy to understand, and thus takes less time to review and execute. In a team, it is quite likely that the test case execution will be performed by a team member other than the creator of the test case, hence having good test cases always saves time and reduces back and forth communication among testers.
• Identifies gaps early in the project lifecycle – Test Case design requires the capturing of all positive as well as negative scenarios. Documenting those details requires an organized thought process and a complete understanding of the application under test (AUT) which in turn helps in identifying gaps for design and functionality upfront.
• Helps achieve maximum test coverage  – Test Cases are the primary indicator of the planned test coverage. In process-oriented projects, each test case is reviewed by the business owners to determine scope and coverage before it can be approved for execution. A complete test case with full path coverage always leave a good impression on the reviewer and so will receive less feedback.

What to include when creating a Test Case

Organizations tend to follow one of the two main protocols when capturing test cases; some use spreadsheets to document test cases, and some use online test management tools. Irrespective of the method followed for designing and maintaining the test cases, the standard template must include:

1. Test Case Name/Title – Each test case must be given a unique name.
2. Objective/Purpose of the test case –  Specify the purpose of the test case.
3. Preconditions – Add all preconditions, such as dependency or steps already completed.
4. Test Data required for executing that particular test, if any –  This may not be needed all the time, but some test cases require specialized roles and privileges; hence it is good to add the test data details used for that test case.
5. Test Steps – Add detailed steps without missing even a single step.
6. Expected Results –  Add expected output.
7. Pass/Fail Status – This field is updated only after the test case execution.
8. Comments – if any.

Here’s an example of a test case for a Guest Checkout on an E-commerce Website.

1. Test Case Name/Title – Guest User Checkout using a credit card
2. Objective/Purpose of the test case –  Verify the Guest User can Checkout successfully using a valid credit card.
3. Preconditions –  User must not be already logged in to the application
4. Test Data required for executing that particular test, if any – N/A
5. Test Steps –
   1. Launch the application
   2. Add products for purchase
   3. Proceed to Checkout and provide all valid details
   4.On the Payment step, pay using a valid credit card
6. Expected Results – User must be able to purchase the product without any error.

If the test passes, the comment can be updated to reflect the transaction number for future reference, as shown below.

• Pass/Fail Status –  Pass
• Comments – Order Id #123 created successfully.

If the test fails, the status can be updated to Fail, along with the reason in the comment section.

• Pass/Fail Status – Fail
• Comments – User noticed payment failure error. Related defect # xx created for the same.

Tips for writing good Test Cases

• Each Test Case must only have one objective –  Test Cases are written to cover main, as well as all, alternate flows. Every test case must aim to achieve only one purpose. Collective goals in one test case may lead to incorrect results, tracking and could impact testing metrics. A prime example would be the testing of choice with the option of a Yes/No. In this case, creating a separate test case can ease the tracking of pass/failure depending on the provided input.
• Every Test Case must be complete –  This means that even if the steps are mentioned in any other test case of a related module, they still need to be included in all the test cases despite it being repetitive. The idea is that each test case must be independent and must be able to be executed with ease by anyone.
• Don’t make Assumptions while creating a test case –  A written test case based on assumption leads to problems during execution. Test Case coverage requires the inclusion of different input conditions, but keeping close to real events is what’s needed by the business owners. It’s bad practice and economics to cause owners to spend on a situation which has almost zero probability.
• Involve Senior Testers/Domain Experts in writing Test cases – Complete and to the point full coverage test cases are the product of experience. If the team is comprised of experienced members, it is recommended you utilize them for creating test cases.

Conclusion

Test Case writing is a time-consuming and quite often repetitive task, but if done sincerely, taking the trouble to create a testing process roadmap can reduce the effort needed for the rest of the QA cycle, which makes the test execution process easier and more efficient.