Revenge of the Gatekeeper
For the past couple of months I’ve spent half my time, which is in itself reduced following complications, as a “QA Champion”. A title I dislike. In particular I dislike how QA tends to be associated with the testing best described as “checking” and “QA monkeys” running “test scripts”.
The organisation that I joined as “QA Champion” (I’ve died a little more inside when writing that) has had quality issues, especially since a re-org tried to move us into a LeSS structure with dev teams taking on quality and testing. This was first done by getting rid of testers (well not quite) and trying to shift the QA left to do QA earlier. Everyone needs to be doing some QA, not just the QA teams that still sort of exist. We plan to solve this by automating all the QA.
Ignoring the “automation solves everything” part and the fact that we are working on an old tech stack that lacks testability, I have real issues with our approach.
Let’s have a quick prequel first.
My understanding is that our old methods were that testing was thrown over the fence to teams who ran lots and lots of test cases then produced reports and would be the authority on whether we can release. In other words QA as the gatekeepers of quality. To me this is the dark side and rightfully needs defeating.
So why the ranting, rambling blog post? Surely I should be happy that we’re abandoning this? Well no. I’ve found that the QA Champion is sod all to do with championing quality and we’re the new gatekeepers of quality.
What have I become?
A New Hope
As bleak as it may seem, a shift in the balance may be happening. I’m hoping that I’ve awakened something within the QA Champion group so that we can become a force for good.
I’ve started something of a rebellion. Through a tech talk I shared what I think continuous testing, shift left and quality engineering, all that goodness, could look like for us. With passionate discussion (or constant whining), I’ve got discussions going where I think that there is a strong alliance to bring around change.
My goal is built on two pillars right now.
First is with the teams that I immediately work with, we are looking to use practices to help us test continuously and build quality into our day-to-day. This hasn’t been a hard sell because:
- There’s a strong desire to improve quality where possible.
- I’ve said that I’ll have their backs in rejecting the initiatives coming from above (i.e. the ways of the dark side).
- Many of us have worked together. Some of them taught me what I’m now passing back.
Secondly I am continuing to raise the discussion on what I believe to be the right practice and challenging things like “let’s get teams producing reports detailing all their testing for an epic”. I hope to change the language and expectations from management so that they aren’t looking for the same sort of gatekeeping as before. If they want us to be potentially shippable, instead of going through the arduous and prolonged hardening and release processes seemingly non-stop, lets focus our energies on employing quality engineering.
A Force Awakened
So far I’ve had mixed feelings about my progress. There are moments of hope and feeling like there’s positivity and receptiveness to this, followed by a request for dev teams to run hundreds of manual test cases each in a hardening phase for an internal release.
However I’ve now shared our new approach in the latest sprint review. We’ve had lively and positive discussions about how we can actually get to this stage. Things may actually start coming together.
I will wrap up this post by saying that if the next month or so goes well, I hope to get my job title changed from Senior Test Engineer and get the QA Champion program re-branded.
Hopefully this tale will end with the rise of the Senior Quality Engineer.
(sorry)