I love testing. I don’t love scripted, manual test cases. But the fact is that every job has elements you don’t enjoy, and every context needs something another doesn’t. Sometimes, scripted manual test cases are either the way to go, what the client wants, or both. So how do you write scripted, manual test cases when you hate scripted, manual test cases?
Work Test Cases into Your Test Strategy / Plan
A place for everything, and everything in its place. Why are test cases needed in this particular context? What will they be used for and when? Who will write and perform them? Will it always be this way?
Figure out where test cases fit into the big picture and make them part of your strategy / plan. This might even help you determine whether they’re really needed, or what purpose they serve / value they bring.
Focus on the Benefits
There can be upsides to having scripted test cases. Focusing on these instead of how much you dislike them in general will help you to write better quality test cases, since you’ll be motivated to optimise them for the advantages they can bring.
Potential upsides include:
- Expected behaviours of the SUT are clear and centralised
- Complicated / lengthy test steps which can’t be automated are broken down to reduce errors
- People from other areas of the business / teams / externals can easily follow scripted tests
- …
Use the Test Suite as a Model
I like to use things like feature maps and architecture diagrams to understand and visualise an SUT. A well-structured test suite can be used in the same way, and help you plan which tests to perform, when. It can also help you to better understand your test coverage, both in terms of what the suite covers, and what tests have been performed. This can be useful when providing what I like to call a “statement of quality” and confidence level of your assessment.
Test suites can also be very useful for onboarding purposes, since the key features, use cases, etc. are grouped and described so explicitly. Working through a test suite can be a great way to learn.
Let Test Cases Inspire Exploration
It could also be a great opportunity to explore. Sometimes, laying things out in such an explicit, logically structured way can help us to identify gaps and inspire us to think of other scenarios or missing information that we want to uncover. Perhaps things aren’t so clear, and writing these test cases helps you to realise that and prompts you to find the clarity you need.
When executing tests, we don’t have to blindly accept what’s in the scripts either. We can question the validity of what’s stated; why the test case instructs you to set up something in a particular way; why the test is being performed on this level (scripted test cases don’t always have to be executed at UI level).
Practise Risk-Based Testing and Adding Value
Figuring out which scripted, manual test cases to write can be a great opportunity to think about risks. Which tests do you want to start writing first, and why? What value will performing this test bring us? What risks would we expose ourselves to by not performing this test? What threats would issues in this area pose to our most important quality characteristics? Lean into those questions to make sure your test suite is actually benefiting the team as quickly as possible.
Write for Maintainability and Longevity
Think about what you’re really trying to determine with each test. If the specific user doesn’t matter, but the type of account they have does, for example, then just specify the account type in the test case. That way, if the user is somehow deleted or altered in such a way that it’s no longer suitable for the test, your test case will still make sense and won’t have to be unnecessarily maintained. Be specific enough so that someone else could successfully follow the test steps, but not so specific that that every minor change in the SUT would require constant adjustments.
And if your test management platform allows it, think of ways that you could “reuse” test steps or sequences, to reduce the number of places where the exact same updates need to be made. This could save you a lot of time (and boredom) in the future.
Keep an Open Mind
When faced with a task we don’t want to do, it can be very easy to apply our bias (dislike), become unmotivated, and end up not doing the best job as a result. Learning to appreciate the value that tests cases could bring in your context can help to add another tool to your belt, and help make you a better, more well-rounded tester. So if you need to write scripted, manual test cases, give them a chance and write the best quality test cases you can.
Get the point, but would still rather not use test cases? Check out my practical alternative: Introducing HISToW.
What other tips do you have for people who hate writing test cases? Share them in the comments.