I hear myself say a lot of things when I’m working on a team as a tester. I’m going to try and blog about a few of them.
The information that you need to do the best testing you can will need you to get out of the way. Time to let the work flow. We need to learn this and live it too.
This blog comes from trying to crystallise a few things about my own software testing style. This one kept coming up. A tester should rarely be the reason a piece of work can’t flow through the board. Delaying the value add where it’s needed. I say often to the teams that I work with, “don’t wait for me, I will be there when it matters.” This is a vague statement I know and experiential. It’s very much like finding the “last responsible moment” to build something. Hard to know when this is, but very powerful when you get it right. As a tester of some experience I accept that this may not be something that is natural if you are starting out.
Lets break down the statement:
“Don’t wait for me”
This recognises that work within teams is fluid, what is on the board is a picture of whats going on. The work needs to progress to get more feedback, from being in later environments, or in front of beta groups. Much more valuable than my humble information, from my single point of view. Batch size also has an influence on this. Work in small batches. This enables gradual learning about what is being built. Making testing integrated batches more meaningful. For the small stuff, I tend to share test ideas with developers more than testing too hard myself. Then pick the right time to perform testing. Sometimes a little passive testing works well. Add a list of test ideas to the ticket beforehand and then discuss at various points. Tick off ideas that are relevant now, ideas that might be relevant later on. Plus those that clarify how something works or not. I can deliver some test ideas passively through analysis or actively through questioning. Or a little of both. What do you as a developer need?
There is also the question of access to source control. I make sure I have access to this. This means there is even less need to wait for a tester. This is where the live story of your project plays out. Couple this with a great relationship with your developers. With both you can test at the same cadence as the build of the product. Source control is a narrative for testing. Where threads of history play with claims about the present and future. Watching a Gource animation about who has worked when, where and on what is an illuminating experience. As a tester, it shows you where to go to test, rather than the words written in a ticket.
But what about issues leaking into Production? Well, I have long accepted that you can’t find them all, only strive to find the most important ones. Yes, the worst might happen. Sometimes it does take that to change a testing culture. Not saying its right, saying that is the way it is more often than not.
“I will be there when it matters”
To be there when it matters, you have to not be too busy to notice when it matters. That long queue of tickets to test that keeps you busy? Some of that matters but not all. It may matter more to deeply understand your context and technologies you are working on, rather than test that next ticket. If a developer says can I show you what I’m up to you say YES PLEASE (unless you are tired, fragile or about to go home). It matters being available when someone wants to do a story kick off.
It also matters to learn in some depth about the technologies and contexts you are testing in. No one is pre-programmed with the knowledge for a particular technology, technique or task. The context changes with each implementation. So, take the time to study deeply your problem space and to make being there when it matters really matter. This speaks to the many times I’ve seen testers turn up for architectural design sessions and not have anything to add. This in turn speaks how testing is taught in organisations and the wider world. Mostly not at all.
Testers would be much better appreciated if they were present when it mattered. As opposed to lurking in the outer reaches of the teams board. This is experiential. As a lot of how testers do testing still relies on individual intuition over technique. We do need to redress this balance. In the meantime, I’ll be picking out opportunities to get involved when it matters most. Deeply understanding context while letting work flow freely
Diagram Industries 