Test management is a complex process that comprises many different phases which are part of the Software Testing Life Cycle (STLC). Each of these phases has its characteristics and requires defining the type of executed activities, as well as the mode of their realization together with all the attributes of a given phase.
When we concentrate on optimizing our testing process, we often forget about the basics that have a massive impact on other factors in our process. One of these things is test steps.
We can easily assume that a test case cannot exist without test steps. It doesn’t matter if we’re talking about automated tests or exploratory test sessions. In the former, we design test steps which are then executed by software. In the latter, we also carry out previously defined test steps – however, these are discrete tests which are created ad hoc. We can’t really say that a tester who uses the exploratory method is doing it blindly.
In this article, I will focus on the best practices for creating test steps for the purposes of manual testing.
First and foremost, test steps need to be clear and understandable. It’s not about going into as much detail as possible – instead, it’s best to formulate your thoughts in a way that is clear to other people who will be responsible for testing the software.
That type of focus and clarity will allow avoiding unnecessary questions and follow-ups where you dedicate time to explaining what you meant. You’ll be saving a lot of time and carry out the entire testing process more smoothly.
Expert tip: Remember that a test is often created once but executed many times. Any attempts at saving time (like using thought shortcuts or colloquial language) when writing test steps might lead to severe problems in later phases. Put in a little more effort and write detailed, accurate test steps. Trust me, everyone will appreciate it.
Fewer steps = better tests
This point applied to the general process of writing test cases, but it’s worth to pay attention to it already when you’re writing test steps. If your test case includes 200 steps, something isn’t right.
The most common issue with such vast and complex test cases is that they fail to identify a specific path for a given functionality but attempt to capture a more extensive process. So what happens when you get a negative result following the execution? Trust me, identifying the problem quickly will be next to impossible.
If you’re dealing with a task that includes a large number of steps, consider breaking it down into smaller cases that you’ll describe in detail. In my experience, this is a viable option most of the time. It’s worth remembering about that point already during the process of writing test steps. Personally, I always do my best to write a maximum of 15 test steps for a single test case.
They say a picture is worth a thousand words. When it comes to writing test steps, that holds true in some situations. Sometimes the action we want to describe is quite complicated and requires a long and detailed description. To make your life easier, just clarify the action that needs to be executed in that particular step by attaching a screenshot or an image. Naturally, you can follow that up with a description – when combined with a picture, it will work to your advantage.
Another smart use of attachments is when your test requires using a particular file. I’m talking about tests that check import mechanisms or REST endpoints that use files of a particular format (for example, JSON). Thanks to the file attached to a given test step, testers don’t need to create it on their own. As a result, executing the test will take less time.
A step is not a case
Sometimes we might encounter an approach of using test steps as test cases. Following that approach means that the name of a test case testing a particular functionality becomes a test step. The primary goal of that is saving time – that way we don’t have to focus on writing detailed instructions but only rely on titles instead.
If you’re working in an experienced team of testers, that approach might be advantageous. However, it’s always a little risky. Without well-defined test steps, we don’t know which path the tester will use to check a given test case. And more often than not, testers can follow several different paths to realize a software functionality. That’s why it’s a good idea to put in a little more work and write detailed test cases – that’s how you make sure that a particular path is tested accurately.
Use a testing tool
Writing test cases and test steps in Excel spreadsheets used to be very popular. Why is that? The tool used to be (and still is) widely used in many organizations together with the entire Office package.
Another factor behind the popularity of this method is the fact that testing software wasn’t as important as it is today. In fact, today testers have many different specialized tools at their disposal that allow efficient test process management. These can be either separate tools or solutions that are part of larger packages.
If your development teams use Jira Software to manage their projects, you can expand your instance to include a functionality for testing thanks to apps available on the Atlassian Marketplace that were designed specifically for testing purposes. A good example of such an app is TestFLO. The app includes a customizable field Steps where you can define columns and steps statuses. You can also add comments, attachments, and create defects on a single test step.
Writing test steps for test cases is one of the most basic activities during the process of testing software. However, it’s precisely because it’s so basic that we sometimes forget about it and don’t pay enough attention to the quality of our test steps. The consequences of that range from misunderstandings and unnecessary communication to inaccurate or false test results.
That’s why it’s worth to be precise when writing test steps, already considering that testers might end up be using them more than once. By doing that, you’ll ensure better test results and comfort of work for everyone involved in the process.
Do you have any questions about using Jira Software for testing? Reach out to me in the comments; I help organizations implement the most efficient testing processes with the help of specialized apps and solutions.
Test specialist, TestFLO Product Owner, Jira enthusiast. With a few years of experience in testing and Atlassian environment, he strongly believes that Jira combined with other Atlassian tools is a great place to design almost every process, not only test management. After hours a big fan of speedway and board games, also a homebrewer.