There's a major change going on with work as I knew it. Half of my team's developers are moving to other work, and I'm bound to analyze on what I feel is the right ratio of testers - or rather, if it makes sense to double it.
Over the last four years, I've learned that one good exploratory tester can both help developers hit the mark better AND fill the backlogs with work undone (some might call these bugs) to an extent that it makes sense to add power to fixing, not testing. The information testing provides gives us little value if we are unable to react to the feedback. There's some types of information that is useful to know even if there was no fix applied. But that is more of a special case.
Since start of this year, my team has had not only a tester but another person with very similar goals, working on a more limited set of problems: UX (user experience). With an existing product and loads of ideas of improvement, I see the same pattern that emerged when I first joined. One person can easily fill the backlogs with work undone, this time from a UX viewpoint.
So all of this leads me to think of the idea that all too often, both testing and UX are backlog fillers. We create plans without action. We rely on developers to take the plans, fine-tune them into something that can actually be implemented without losing the value we hope for, and turn them into actions through code.
While it is worthwhile to try to figure out things before we're building it, there's still a whole lot of stuff we're figuring out as the product grows. This is true for both testing and UX perspectives.
Plans without actions make us backlog-filling specialties. I find it fascinating to seek for better ways to do this, where the effort won't go into building inventories and going through them for prioritizing them into the pipeline, but instead, have the expertise readily available. Unsurprisingly, the best mechanism I've seen for this so far is Mob Programming. No more plans without actions, but plans with actions and a good follow through.
If it only was easy to get people to do it, other than the practice sessions...
Over the last four years, I've learned that one good exploratory tester can both help developers hit the mark better AND fill the backlogs with work undone (some might call these bugs) to an extent that it makes sense to add power to fixing, not testing. The information testing provides gives us little value if we are unable to react to the feedback. There's some types of information that is useful to know even if there was no fix applied. But that is more of a special case.
Since start of this year, my team has had not only a tester but another person with very similar goals, working on a more limited set of problems: UX (user experience). With an existing product and loads of ideas of improvement, I see the same pattern that emerged when I first joined. One person can easily fill the backlogs with work undone, this time from a UX viewpoint.
So all of this leads me to think of the idea that all too often, both testing and UX are backlog fillers. We create plans without action. We rely on developers to take the plans, fine-tune them into something that can actually be implemented without losing the value we hope for, and turn them into actions through code.
While it is worthwhile to try to figure out things before we're building it, there's still a whole lot of stuff we're figuring out as the product grows. This is true for both testing and UX perspectives.
Plans without actions make us backlog-filling specialties. I find it fascinating to seek for better ways to do this, where the effort won't go into building inventories and going through them for prioritizing them into the pipeline, but instead, have the expertise readily available. Unsurprisingly, the best mechanism I've seen for this so far is Mob Programming. No more plans without actions, but plans with actions and a good follow through.
If it only was easy to get people to do it, other than the practice sessions...
