Writing manual tests is not rocket science, then why can’t we write good ones?

In the world of software testing, test cases play a big role. Whether we are talking about manual or automated testing, as QA engineers, we have to write test cases. This time I would like to touch the topic of manual test cases.

You might think, why to bother writing manual test cases when we are all driven by the idea of test automation? Yes, we all want to run our regression suite and wait when it gives us feedback. However, it won’t happen from day to day. If you are at the beginning of the test automation process, like our team, you need to have a good base of manual test cases, which you want to automate.

In my company, we are working on very complex business software. We have three development teams with a dedicated QA engineer per team. Most of our testing is performed manually. We use Test Management Software TestRail, where we create test cases and add test executions. This software allows us to organize and structure test cases and monitor the progress of testing.

The process looked good until we decided to start with test automation. Our idea was to take the existing test case database as a starting point — check all existing test cases, decide which ones have bigger business value and prioritize them so we can start to build an automated regression test suite. Simply as it is. But…

When we started to check our existing test cases, it looked horrible! Not clear test steps, missing expected results and titles which don’t even tell you which feature this test case is checking.

How could it happen? Is it so hard to write manual tests?

First of all, there are no rules or a style guide when it comes to writing manual test cases. Different teams organize their tests in their own way and use different tools for writing test cases. Unlike developers, they don’t review each other’s work. That leads to the point, that test cases are understandable only for the person, who wrote them.

After talking with our QA engineers, we’ve got feedback, that THEY KNOW what they are writing and it’s enough. The question is, will other team members understand what those test cases are about? Being a specialist in your domain is great. However, it shouldn’t be an excuse to write unclear test cases.

Let’s think about what is a good test case? From my point of view, a good test case should have a descriptive title, clear test steps, which can be reproduced by any team member and expected results, which verify that the system under testing is working according to the requirements.

Keeping this definition in mind can help you to structure test cases in a better way. Besides that, I have a strong opinion, that QA engineers should work closely with each other, collaborate and ask for another opinion.

Here are a few suggestions, which I believe can help manual QA engineers in the art of writing good tests:

• Start with a good title. When other people read the title of your test case, it should be clear, what is being tested and under which conditions. Try to include keywords in the title. Keywords will help others to find your test when regression testing is needed. Use at least one verb to describe the action, which your test case is verifying. It makes the title more human readable.
• When you write test cases, imagine yourself being a technical writer. Test steps and expected results should be understandable and clear. All needed information about the environment, setups and test dataset should be there. But keep it brief. Every step shouldn’t take more, than a few sentences.
• Think about other team members or even other teams. Would they understand your test case? Think about the most junior team member. would he or she be able to reproduce test steps? That should be your goal.
• Write your tests in a way, that they can be reused in the future. For example, instead of writing to test on specific product ID, use some generic characteristic, like Category name. However, don’t skip important parameters, which can affect test results.
• Ask another person from your team to review your test cases from time to time. Maybe they will give some suggestions on style or even functionality.
• Play a little game. Prepare some test cases and ask a colleague from another team to execute them. You will get feedback if everything was clear in your test cases, and this will give you a sense of the degree of detail in the test steps.

Remember, that you write test cases not for yourself, but for the team.

In the end, writing good test cases is not rocket science, but it’s definitely a skill. It requires some patience, knowledge, and practice. Of course, it’s important to be a specialist in your domain to write a good test case, but you don’t need to be one to execute them.

Thanks for reading.