In my previous two posts I discussed how as testers we might work to protect ourselves from the various risks that face us in the current market, primarily those of outsourcing and developer only testing. Both of those posts focussed around the building of strong relationships in the organisation, firstly by getting engaged with the developers within the team, and secondly offsetting this with symbiotic relationships outside the team.

One key relationship for a tester that I haven't yet discussed, and one that is particularly relevant when working in an agile environment, is that of the product owner. In this post I'll review the idea of the agile product owner and the tester's relationship with them, and how the testing role can make an evolutionary step to help take on the product owner's responsibilities and address some of the challenges that can accompany that role.

Making Decisions

In his 2009 post The Mythical Customer Problem Gojko Adzic highlighted one of the potential flaws in the model of an Agile team. The notion of an individual who has all of the requisite domain knowledge to make all of the business decisions for the team is an optimistic one. Even if there was such an individual the chances are that someone with this level of knowledge is going to be in high demand and not available on a daily basis to furnish the team with all of the decisions required to progress their work. In my organisation the product owner is an extremely busy man working on customer engagements and management duties. If we deferred to him for every minor design decision then it would seriously compromise his ability to fulfil his many responsibilities. A product owner, almost by definition, needs other responsibilities which interface with the customers or users of the product to qualify them for the product owner role. These responsibilities may impact on their availability to the team. For many teams, as Gojko suggests and we have certainly found, the reality is that the team will evolve to take on the responsibility of making many of the day to day decisions on the project collaboratively, and referring to the valuable time of the product owner when the way forward is unclear or major tactical decisons need to be made.

An opportunity to shine

This process of "collaborative specificaton" affords testers with a fantastic opportunity. As covered in my previous post, by building strong relationships with customer facing roles testers can develop key knowledge on the customers and their demands and uses of our products. The product owner/customer falls into this category as well. As testers I believe we should work to build an excellent relationship with the product owner, to the extent that we can expand our remit as the 'proxy' to that role within the development team and help to make business related development decisions on the product owner's behalf.

One complaint that we regularly hear from testers in late stage testing projects is that they are not involved in the requirements early enough. Requirements in an agile process generally come in the form of user stories. User stories in the early development stages are little more than "placeholders for a conversation" and are far more fluid around the implementation details than traditional specifications. Small agile teams rarely have the luxury of a devoted business analyst, and I think this affords an excellent opportunity for the smart tester to extend their role. By getting involved the specification process the tester can evolve from a role of requirements verification to one of guidance, starting from the very early specification discussions.

In my organisation the excellent domain knowledge of the senior testers has helped us to become an key part of the elaboration meetings when discussing user stories. I'm not suggesting for a second that we manage the specification discussions, however there are many inputs needed into this process both from a product technical and a business perspective. With the developers providing the former the testers take on the responsibility for the latter based on information gained from the product owner and their other customer facing relationships. Where a detailed specification is lacking the tester will help to fill in the detail that is required based on their knowledge of customer implementations and priorities from the customer facing roles in the organisation.

In the area of bugs too we have evolved such that the product owner is often happy to delegate to the team on the decisions regarding bug priorities. We have a partner delivery model with many implementations in live use on various historical release versions. Myself and the other more experienced testers will often help choose between related risks and make the call whether or not to push fixes to release branches.

Potential pitfalls

There is inevitably a potential downside to increasing the remit of the tester's role. Testing is viewed by many in the profession as a position of information service provider. We are not there to make decisions, we simply furnish those that make the decisions with the information to do so. The advantage of such a position is that, should those decisions prove wrong, we are abstracted away from the responsibility for any failure through our lack of involvement in making them. The idea of involving ourselves in the specification process removes the safety net of blaming absence or poor quality of requirements in our inability to perform effective testing. By stepping up and involving ourselves in the decision making process we are exposing ourselves to far greater personal risk in terms of responsibility for failure.

My argument to counter these pitfalls would be this. I would rather commit to a project wholeheartedly and risk sharing in the responsibility for its failure than see it succeed having had the frustrations of others making the decisions and taking all of the risks. Engaging in the specification process helps to complete the picture of integrating the testing role fully into the product development stack. Refusing to do so may expose us to the greater risks that I've already discussed. Given the choice I'd always prefer to have more control over my own destiny than less, and the stresses of additional responsibility for me will always win out over the frustrations of being an afterthought in the decision machine.

Future of the Fit-Tester

I hope you've enjoyed this small series of posts. Needless to say these are my own opinions and I'm sure others see things differently. One thing is clear to me, and that is that the risks that I've discussed here do exist. Based on surveying UKTMF members Paul Gerrard last year predicted that 50% of UK testing jobs would be outsourced to other countries in the next 5 years. In the US recently Lanette Creamer blogged about a Selenium Meetup in San-Francisco where the "test lead" of a lean startup made proud claims of not needing a QA team at all. These are isolated instances, but give an indication of trends that can affect us if we are not aware of them. If those of us who consider ourselves "Testers" want to survive and thrive then we need to be prepared to evolve. In my this small series of posts I've discussed some of the directions in which I and my team have done just that in recent years, for better or worse. Personally I would rather face the problems that come with being aware of risks and taking positive action than those that come with being made redundant through maintained ignorance of those risks.

I'd be happy to respond to any comments you have below or on twitter. Additionally I'll be speaking on the subject of "Survival of the Fit-Tester" at the Ministry of Testing TestBash in Cambridge on 23rd March so please come and chat to me then if you can attend the event.