December 11, 2019 Test Case and Test Scenario: Things You Need To Know (Part 2)

Recently, there have been QA challenges in which participants are required to write test cases and test scenarios for specific webpages of our very own Topcoder website. We covered the ‘what’, ‘why’, and ‘who’ in the first part of this article. In this second part, we will get to know the ‘when, ‘how, and ‘best practices’ of test case and test scenario creation.

When Should You Create A Test Case and Test Scenario?

Before end users can use a product or avail a service, it has gone through several stages first, namely: Development, QA (Quality Assurance), UAT (User Acceptance Testing), and Production. Test Case and Test Scenario creation usually dominate the stage of QA where vital aspects of the product/service are tested before putting it into live production or introducing it to wide market reach. For UAT, the equivalent of test case and test scenario are user case and user scenario, respectively. They are written in a similar way to test case and test scenario but focus on user experience.

Sometimes, creation of test case and test scenario comes first before any actual development. This way, it helps clarify the requirements of the development. It is also beneficial for the tester as he/she will know how much time and effort he/she will need to test what the developers have done. However, test case and test scenario creation may not be necessary at all for projects that follow agile methodology because of frequent changes in scope, features and certain requirements which might be very difficult for testers to handle.

How to Create a Test Case and Test Scenario

There are several ways to create and format your test cases and test scenarios. These vary depending on the nature of the product/service, standard procedures of the QA team, or the required format of the client. First of all, read the requirements and figure out possible user actions and objectives. List all the scenarios that check each feature within the scope. Completed written test cases and test scenarios are then subject to review by the person responsible for that.

As for the case of recent Topcoder challenges, writing test cases and test scenarios is composed of several fields in which participants have to fill up in a spreadsheet.

• Scenario ID – composed of prefix ‘TS_’ and increment of number by 1 in 3 digits. 
• Test Scenario Description – this is the ‘What to be tested’. A short description of what needs to be tested and where should you start from.
• Test Case Summary – the more detailed information of test scenario. This is more of ‘How to be tested’ where only relevant information is shown such as a specific test scenario and expected result.
• Pre-Condition – any relevant condition that is required to be met before doing any testing steps.
• Test Data – for testing that needs input, this might be necessary for testers to know what kind is needed to test the specific scenario.
• Step Number – incremental step indicator for each instruction that leads to the completion of a test case.
• Step Description – step by step instructions on how the tester should complete the specific test.
• Expected Results – the normal outcome that the end-user should expect given that an action has been done.

Best Practices And Techniques

Here are some best practices and techniques used in creating a test case and test scenario document.

• Each test scenario should be tied to a minimum of one requirement or user story. As much as possible, keep it simple and easy to understand.
• Give clear details of the test scenario to avoid confusion among groups of testers. If it isn’t obvious, indicate directional details as well as specific tweaks a tester might need.
• Please keep in mind that in writing test cases, there should be no dependency or conflict with other test cases. Your test case and test scenario should be reusable and modular.
• Properly maintain your test document. That means update existing test cases and test scenarios if needed, remove items that are obsolete, and add relevant ones as per requirement.
• Do not make assumptions in any of the written test cases and test scenarios. The test document is built based on the reality of what was done and not based on speculation.
• You should consider using a technique to make your testing time efficient, and at the same time, create high-quality output. Here are some testing techniques that you might find useful:
  • Boundary Value Analysis (BVA): this testing ensures that boundaries (minimum and maximum) are completely covered. This is considered to make sure that the product or service doesn’t break at the edge conditions of testing. Generally break points are obtained at the extreme inputs by providing both valid and invalid boundary value in test data.
  • Equivalence Partition (EP): this technique uncovers classes of errors and validations which lead to the reduction of the number of test cases to be developed. It works by dividing input data into groups of equivalent data that are expected to exhibit certain behavior (similar or opposite).
  • Decision Table Testing: a technique which aims to test a feature using different combinations and their corresponding system behavior (output) are captured in a tabular form. It is a tabular representation of inputs versus rules/cases/test conditions.

Error Guessing Technique: if one thinks they are experienced enough in the field of QA, they are eligible to use this technique. This particular testing technique relies heavily on the experience of a tester to guess problematic areas within a product or service. It is not necessary to follow any specific rules in using this technique as the test cases would generally depend upon the kind of testing the tester was involved in the past.