…..Splits a family in two.
What springs to mind when you hear the term gatekeeper?
The role of a tester can often become synonymous with that of a gatekeeper?
Is that symptomatic of buck-passing?
Whose responsibility is the quality of your product?
Who cares?
My first role as a tester was officially a Quality Assurance Technician, in a waterfall environment, sat in a different building to the development team. Direct communication via anything other than the bug tracker was forbidden and progress was slow. The bug feedback loop was slow, by the time they had filtered back to the dev team, they had moved on from that feature.
Whose responsibility was the quality of the code?
What was their definition of done?
Did I know? Heck no!
As time passed, I gained a greater level of understanding, the process was convoluted and very political.
Without visibility or an understanding of the process, it was very easy for a tester to become very demotivated.
If my inferred identity as a tester was to raise bugs, to be as nitpicky as is humanly possible, to assure quality, then what was my purpose if I entered bugs, then received either no feedback or had my bug closed as ‘won’t fix‘?
It is very easy to feel, as a tester, in that scenario, that you are the last bastion of quality, he (or she) who is there to maintain the quality of the software that is being released.
In that scenario, how would you approach your role as gatekeeper? Would you ever be satisfied? I’ve always stood by the fact that no software is bug free. I’ve even seen situations where a developer has handed a new feature to a tester, with the promise of cake if any bugs are found……guess what happened there?
I digress….
In Agile, we have self-organised teams, primarily of testers and developers, who have an agreed (and not static) definition of done. By those agreed criteria, we should have a ‘potentially shippable product’ by the end of each sprint. However, the third amigo, is the Product Owner.
I have often mentioned that the role of a tester is as an advocate for end-users, but within a development role, we can still have a bias, or even be blind to a product that we are so close to.
The product owner is responsible for communicating the vision of the product and product road map to the Scrum team. She is responsible for defining the order of the work items through the product backlog for a release and for deciding when the product has to be shipped. That means the product owner is responsible for defining and managing the releases. The initial release planning is done in the beginning of the project and readjusted at the end of each sprint, based on each sprint’s outcome. Hence the product owner should work with the team to estimate the number of product backlog items and determine the number of sprints needed to complete them for the release. If the date is missed, the opportunity is gone, and launching the product no longer makes sense.
Someone has to make the go/no-go call on a release. That role is the Product Owner.
I haven’t always had pride in the released software that I have worked on. But, there has to be a well-rounded call made to release a product. It isn’t something that we always get right, but knowing where the decision needs to be made means that we aren’t stuck in a perpetual loop over unreleased software development.
It can be an impossible task at times, it isn’t possible to please everyone. But, decisiveness informs and enables direction. They may not be popular, but I for one, am glad we have Product Owners.
Blog post title lyrics from: Under pressure – by Queen and David Bowie.
Find all the songs from my blog posts at this Spotify playlist.
Chris Armstrong 
2 responses to “Under pressure that brings a building down…..”
Of your earlier experience, you asked “Whose responsibility was the quality of the code?” Well, at the risk of seeming obvious, in that case the answer was “the developers”.
You’d done your job as a tester to the best of your ability. It wasn’t your fault that you were marginalised. If a dev sends a bug report back as ‘Won’t fix’, then they’re taking the responsibility for any fallout from that decision. I know that allocating blame is a very un-Agile thing to do, but if the organisation is prepared to allow that sort of behaviour, then it has to take the consequences. If the gatekeeper is told to keep the gate open, then they are not responsible for whatever passes through unchallenged.
You described that as being a very “political” environment. If managers and colleagues want that, then they have to realise that there will be fallout from that when things go wrong (as they inevitably will). As a professional tester, your only defence is to always do the testing in accordance with your professional ideals, make sure that you (and any other testers in your team) are as watertight as you can make yourselves, and wait for the organisation to realise the error of their ways. And if they don’t, then you might have to accept that you are too good for that particular organisation and move on to somewhere where you are more appreciated (preferably, but sadly not always, at a time of your own choosing).
LikeLike
[…] Under pressure that brings a building down … – Chris Armstrong – https://christestarmstrong.wordpress.com/2017/09/06/under-pressure-that-brings-a-building-down/ […]
LikeLike