We talk a lot about ownership, but sometimes I get a little tingle in my brain that makes me wonder if we're all using the same definition. It's very easy for a term to be used so much that different people end up feeling that the word means different things to them, and sometimes I have to admit, I'm the one who's getting it wrong!
It wasn't the first time, and it won't be the last that that I've gone into a dictionary sanity check my definitions. This is something I encourage everyone to do once in a while!
This was a little tricky as we were talking about ownership in the context of processes initially. It helped looking through several definitions, and not just choosing the definition you personally prefer, to make sure there's a consensus. I found the Wikipedia one was the best to talk around,
The process owner is responsible for designing the processes necessary to achieve the objectives of the business plans that are created by the Business Leaders. The process owner is responsible for the creation, update and approval of documents to support the process.
I'm currently overhauling our defect management process on a project trying to keep a balance of (a) reflecting the reality of what we do, and (b) to keep it as simple and straightforward as possible, whilst also giving it a level of flexibility it might need when issues don't fit comfortably.
The question came out "who owns the defect management process?". I don't just write the process and then go "that's that", and I don't really want to be the "defect management police" either. The process needs approvals from both the customer, and superiors within my company, but with the definition, "approval" does not equal "ownership". If the defect management process isn't working, if it fundamentally breaks down or needs nips and tucks, the person who needs to revisit it and work with parties suggesting alternatives isn't the approvers, it's me. And hence we all agreed that any reference to "the owner of the defect management process" refers to me.
Then came the second question, "who owns the defects?". In my many years of software testing, I've never heard the question phrased like that, and particularly with the prior discussion defining ownership, I found myself faced with a question which although seemed initially simple, I felt philosophically deserved some exploration.
My first emotional reaction was, who owns the defects - the test manager. Oops ... the test manager is responsible for the process used to report and even track bugs, fair enough. But are they responsible for "achieving the objectives" regarding defect resolution? I've almost put my foot in a common trap, that "testers are responsible for the bugs they find". Or in other words "you found them ... it's your fault ... why aren't they fixed". Oh dear.
My second thought sounded a bit too much like agile dogma, who owns the defects - the whole team. I like this one a lot. The whole team, from developers to testers are responsible for finding defects, and prioritising work so that the key important defects are fixed before any release to production. Certainly the whole team in that sense are responsible for working together to achieve the objectives.
Even so there are holes in that idea - in my definition there I talk about "key important defects". But who decides which ones are key? As test professionals we can use our experience to suggest which ones we think are more important than others.
But this is bordering on a key mistake many testers can make. Notice the important use of the word "suggest" there. We may like to think we make decisions about when a piece of software can go live, and I have read some test exit reports which have said so.
However in truth, all we can do is recommend. In the end the defects we have represent risks, and we don't wear the risks when we walk away from the project. This leads me to my third answer, who owns the defects - the customer. The customer is paying for the software you're delivering, and the defects are part of that system. Hence it could be said if they are owners of the software, they're also owners of the defects within. And hence as they own the risk, they should get an important say in the level of the risk they're prepared for - as long as we as testers have done our best to inform them what that risk may look like. There may be delivery or schedule deadlines which means it's better to release something now and update later if really required (especially if you want to be first to market). Likewise there might be a desire to "just get everything right first time", even if it means delays.
In the end I've answered the question with three answers. But it's a good question to explore, particularly with our relationships within the team and customer relationship with respect to defects. They're commonly associated with us as testers, but they impact the whole team in different respects,
- As testers we're responsible for finding and reporting defects
- As a whole team we use our experience to prioritise defect issues from our experience, but should seek customer involvement in this. As much as possible encouraging them to participate and have a voice in this
- As a whole team we're responsible for using our time and resources to investigate address and retest the most important of these
- The customer is ultimately the boss, but we have a responsibility to advise, whilst understanding that ultimately it's not our decision to make
