I Got it Wrong – Did the How not the What
I’ve spoken a number of times about testing asking the “what” of something before jumping into the “how”.
- In using Triforce to define Acceptance Criteria I always say that we need to know how and not what.
- When writing a test approach I’ve said that we should work from the what and use that to work out how.
- Talking about exploratory testing I say to look for risks (what) and then test (how).
But recently I fell fowl of the very thing I talk about; when writing a new test approach I got too focused on the how and couldn’t see the what. I wrote and re-wrote the approach and each time I was focused too much on the specifics:
- Helping drive out ACs in Triforce.
- Using exploratory testing and [these tools] to uncover information.
- Capturing test notes on [this tool].
- Raising bugs and managing them via Jira.
I had gone too generic and basically was saying “I’d test stuff”, I hadn’t engaged with the state of the project or the risks that needed mitigating at all. This meant that my test approach wasn’t useful to actually documenting the risks that the project might face and wasn’t telling anyone what I needed or what I’d do to help mitigate those risks.
I’d made the mistake of not practicing what I preach. It’s super easy to lose track of how to do something in a way that’ll be useful and let your own knowledge blind you. I wasn’t sharing knowledge and was just trying to “get something done”.
It goes to show that even those of us who are senior or “look like we know what we’re doing” can fall into the same traps and make mistakes. That’s why it’s important to refresh yourself on the basics occasionally and remember to do the right thing, even if it seems obvious. And also be happy to call it out / have it called out when we do get it wrong.
Luckily, my awesome Test Manager was on hand to show what I’d done and remind me that we need to look at the risks of the project (the what) and then work to the how. Now the test approach has an awesome list of risks and what we need in order to be in a position to test them.
Callum Akehurst-Ryan's Testing Blog 