Stop writing step by step test cases!
In a fast paced delivery environment you should rethink the value that step-by-step cases have. Could you create more value from lighter documentation and focusing on interactions with your team? The main goal is to build the best product, so you need to have this at the forefront of your mind.
First of all, we need to understand the benefits of writing formal tests. My two thoughts are below — can you think of any others?
- A new member coming onto the team — formal test cases can be a way of them getting to know the product quickly.
- Other team members understanding what has been tested.
Feature maps
Instead of writing out tests consider using a feature map. I discovered this in a blog this year and decided to adapt it slightly to ensure that there was still some light weight documentation for any new person coming into the team. You have three columns — feature / success criteria / testing tips.
Imagine we have to create a new feature that allows users to upload files. In the feature column you map out the requirements, the second columns tracks where you are with the testing and the final column gives the testing tips.
I found this useful for the whole team as any team member could update this and we could see exactly where we were at.
This strategy with test documentation allowed me to free up my time to ensure I had more time interacting with my team.
Value
Where I would argue the most value comes from is different perspectives coming together to create a winning product. You need to be present in real time with your team.
You can add a lot of value when it comes to all types of considerations like usability, security, performance, accessibility — I have seen time and again products not baking in things like usability from the start, which can create an overwhelming tech backlog.
Take time in the design stage and free up your time for thinking space / asking questions, then in the long term you will be saving the company a lot of time from sorting out the tech debt created.
Test cases are not a sign of quality
As a team if you have deemed test cases as a deliverable, then something may be going wrong.
- Are you working in parallel with team members?
- Are you working together to figure out the tests you need to run for happy paths, edge cases or regression impact?
- Are you sharing the exploratory notes with your team?
- Does your team understand testing?
Most customer bugs are edge cases or ones going off script. You need to increase your time for thinking time and playing with the application. Learning from previous production bugs and where your customers are finding issues may be a good place to start.
Maintenance overhead
Consider the maintenance effort you’ll have to make with rewriting test steps as the feature evolves. I can guarantee you that this will happen — is it worth creating that debt of work to do in the future?
There are other things you can consider doing such as using BDD/Cucumber, automating as you go — maybe you have some other ideas too?
Thanks for reading :)
