I know I do heavy job crafting (article on that for Rosie Sherry's online publishing pending), meaning that I interpret my role in ways I find suitable for me and my organisation, so that some of the things I end up doing bear no resemblance to my job description. But the core of it stays: I evaluate product by learning about it through exploration and experimentation (Bach&Bolton definition of testing recently).
There's a whole bunch of critical thinking and hands-on empirical evidence gathering skills I apply. There's a wide pool of business-oriented knowledge that I've acquired over the years that help me see things that many developers around me are blind to. And several product owners over the years have personally thanked me for valuable contributions to the success of their products with the mix of knowledge and skills I provide.
As a tester, I've earned one employee of mine half a million of euros by finding ways to release sooner rather than later - exploring risks in layers rather than following a plan of what we would need to test.
As a tester, I've enabled creation of a server product that was supposed to take man-years to create in less than a man-month by putting the ideas together in a completely different way that was good enough for that time and purpose.
As a tester, I've saved numerous hours for my current product manager, who personally thanked me on helping him see that the software could actually work and fulfill more of his business needs than he had been told by the team of developers. With the hours he saved, he worked on other things that drove our business forward in relevant ways - opportunity cost matters.
As a tester, I've suffered from reimplementing the same feature three times before it hit the mark and helped my team to hit the mark with one main iteration of the feature.
I feel very upset for seeing tweets like this:
@jeremybush @LlewellynFalco @unclebobmartin Idealistically, should developers (and their tests) and the PO be able to assume those roles?
— Tim Allen (@TimAtQualtrax) December 8, 2014
. @LlewellynFalco When programmers do their jobs, testers find nothing.I wonder where these unicorn developers and product owners are, who don't need / appreciate help from someone who identifies herself as a tester, since whoever I've worked with, do appreciate it. There's programmers who do their jobs so that testers find nothing *they deem relevant* since it's all just new requirements - stuff that the product owners *should* identify (but don't without helping hand).
— Uncle Bob Martin (@unclebobmartin) December 8, 2014
I've spent a lot of time learning to be a great tester. I'm really, really good at what I do. However, on the work I do, there's much more resemblance to William Gill's list of the things Complete Product Owners would need to be aware of than to the simplistic ideas where all testing is placed in the development sandbox and automated. I'm more likely to be a product owner than a developer, but as a tester, I'm a very useful mix of those two worlds.
Like I just wrote for the talk I suggested for Scan Agile:
Testers don’t break your code, they break your *illusions* about the code (James Bach). Illusions may be about the code doing what it’s supposed to; about the product doing what it would need to; about your process is able to deliver with change in mind; and about the business growing with uninformed risks on the product and the business model around it.
I should add the illusion of the perfect developer and the complete product owner who don't need help on the list of illusions. I know great developers and great product owners, who can appreciate having an in-depth empirical analysis done by a tester so that together we create more value faster. They are hardly perfect - I'm not perfect. But together we're pretty damn good!
I also need to comment on this:
. @TimAtQualtrax @jeremybush @unclebobmartin PO => user stories; testers => abuser storiesI test different things in the same project differently - context matters. I don't create "abuser stories", except on rare occasions. There's plenty of work for testing without focusing on just the negative. I help create value more efficiently. So, please developers, stop putting me and the likes of me in a box just because you haven't met or observed in detail real skilled testers in your projects. There's so much the agile community should learn from the context-driven testing community. Trying to build bridges is tiring, when you need to all the time hear from people that regardless of your continuous contributions, there's a theory (based on bad research I might add) that tells that you will not be needed.
— Llewellyn Falco (@LlewellynFalco) December 8, 2014
Skilled testers breed from a culture of testing. Agile is doing pretty good job trying to kill that culture out of ignorance.