Software testing is one of the key steps done by Quality Assurance (QA) Engineers. For that reason, testers should be up-to-date with QA methodologies. I will give you some guidelines for good test specification from my perspective.

QA engineer can write a good test only if he or she is well familiarized with the problematic of the project.

Prior writing a test case, try to understand the user/business requirements. Also analyse the upcoming change that you will. Test Cases (TC) should be:

• clear, concise and well referenced;
• brief but comprehensive;
• contain easy understandable steps;
• a well-written test case should allow any tester to understand and execute the test;

The process of developing test cases can also help find problems in the requirements. When writing a test case make sure to:

1. Use clear Title of the Test Case

The title should be self-explanatory giving knowledge about the purpose of the Test Case. The title is the first thing everyone reads. For that reason, it needs to be concise and comprehensive.

2. Always Include Description

The description should be informational about what you are going to test. Also, you must included preconditions and Test Data.

3. Make all Test Steps Brief but Comprehensive

Test Steps should include data and information on how to execute the test. This is the main part of the test case. Try not to burden and overload the Test Steps with too much information and references. But also be careful not to leave out any necessary details.

4. Test cases should always be reusable

Reusable TC provides long-term value to the software QA team. This way the testing team saves time because re-writing is not needed.

Always try to make a good plan about the operations which you need to do in order to be more efficient in the whole process ofTest Specification. There are different ways and approaches of writing test cases.

Every tester has its own mindset. There are many methods and practises that can guarantee quality in Test Specification process.

While having the plan in mind, you should always focus on good coverage. Amount of testing performed by a set of test cases is called Test Coverage.

Coverage = Number of coverage items exercised/Total number of coverage items X 100%

100% coverage does not mean 100% tested. Coverage techniques measure only one dimension of a multi-dimensional concept. Two different test cases may achieve the same coverage but the input data of one may find an error that the input data of the other doesn’t.

We begin with Description; The summary of this field is used to tell the tester what is the purpose of exercising that test case. In the description, preferably we add Precondition. In some cases, when we want to reduce the test steps, we re-use another test case as precondition.

If your test case is a long to-do list and an error occurs, steps to reproduce the same issue might be exhausting. To be sure that the bug is fixed during retest, tester needs to do the same work all over again from the very beginning.

Not to find yourself in such situation, try to limit (if possible) the TC to max 15 test steps. Make more test cases but with less steps to be easier to follow and maintain.

Sometimes, there are test cases that only need one step and that’s it, they are done.

Test step: Action to be performed to get the desired results.
Test data: Used input or reference to a software program.
Expected result: Outcome of that verification step after the action is done.

Let’s say we are testing a website. First we need to open the page, then to login on the site and verify existing banners. So, we write the following steps in our very first Test Case:

1. Navigate to site http://www.testing-is-awesome.com;

2. Enter valid username and password and click Login button;

3. Verify that banner exist in bottom right corner;

For Test Data we write: Username = user12345; Password = pass12345; and for Expected Result we write: Page is opened, user is logged in successfully and expected banner is shown in bottom right corner.

Writing a good test case takes practice and knowledge of what you are testing. As long as you think as the end users and follow best practices that I have mentioned above, then you are on a good way.

What do you think, how helpful was this for you? Do you have some different techniques of how to write a good test case? You can share them with us for more effective results.

Best of luck and happy testing!

Cover photo by Artem Sapegin on Unsplash