The Illusion of Quality Assurance

When I first started testing my role description was Tester. In the numerous years that have rolled by since stumbling into the most satisfying phase of my career, I have been both Tester and QA. My previous role had me labelled Principal QA Analyst, my current role Senior Test Engineer. In official communication I will always use my current role title. Outside of that I’ll introduce my self as a tester. I’m proud of that title and what it means to me. I have, for a long time, rejected the QA title as being somewhat silly. Annoyingly it seems to be growing in popularity. More annoyingly it seems to me that those that are representing themselves as “QA” are also representing QA as more than, or superior to, testing. My problem is that when they describe “QA” they are describing what I model as credible, competent testing.

Is this representation of tester as QA now being driven by Agile? I don’t really have an answer to that question. I don’t think Agile was at the genesis of “QA mis-assignment” but based on what I heard at some testing based talks at LAST Conference, Agile is certainly fuelling the conflation of roles. I wont attribute the following to specific speakers but here’s a flavour of the commentary:

If you wait to test it’s too late to shift left
Testers are a gatekeeper of quality because of their mindset.
We are QAs, testers don’t do what we do. We make sure things are right.

The idea of a specific quality gatekeeper is completely contrary to the idea that the team is responsible for quality. In one session a question was written on a whiteboard “How would you test this?” Ten minutes later test was struck out and replaced with QA and the pronouncement “we do more than test, we QA”. In both presentations I questioned the QA over testing claim, how they assure quality. In neither case could the presenters actually explain it. The same hankering for QA is very evident on Linked in as well.

I work in a scrum team. My primary identified role is tester. Here’s an example of how things role in my world for a given story:

I attend grooming sessions. I question assumptions, I ask about how we can improve testability, I help get a focus on what mght be a risk, what we might not know. I work with my team mates to find potential problems as soon as possible. We make notes about things we might want to discuss or explore that are relevant to a story. So far no assurance but we do have a quality focus.

A developer picks up a story from the sprint backlog, a kick off is held. We discuss the story, do we have a common understanding of why we are doing this? Has anyone learnt anything between grooming and now that impacts our previous understanding? Do we need to investgate some uncertainties, are there previously missed ambiguities, do we know of recent system changes that might impact us? We go through a bunch of things, I’m not going to write about them all. Again, I’m involved, there is a quality focus, I’m not assuring a single thing.

The developer is coding while I check out some associated functionality. We became aware of a possible problem during kick off. Together we look for potential crossovers and impacts. We regather after a short while and discuss our findings. There is indeed a possible problem. We examine the nature of the problem and likelyhood. We decide the effort and risk of fixing outweighs the likelihood of it being encountered. If encountered we can actually deal with it pretty easily and the impact on a client is low. We have found a limitation, we can accept this and explain it to clients. This is good outcome. Lots of quality focus here, where’s the assurance. I’m not doing anything assurance role specfic.

The developer wants to add some unti tests to our build checks. We discuss what would be useful and what wouldn’t. I suggest a scenario he had not considered, that gets added. That scenario suggests another, I raise the idea. We discuss. It appears that we have that covered by a couple of others. We decide the risk we were concerned about has been mitigated. As far as I can tell I’ve done quite a bit of testing on this story, no code yet. How can that be? If you’re a tester, and not a QA, then by the time you start testing it’s too late to shift left. Are the QA believers selling a fallacy?

During the above process I’ve been thinking about how I might test the changes. I recently spent a few dollars an a whiteboard for my desk. Here’s my strategy:

The above represents discussions, things I’ve learnt playing with the software, possibilities based on observations, and, a little after I took this photo, I rejected some test ideas based on my discovery that a specific parameter setting meant the problem we were adressing could never happen within those test ideas. Of course that did kick off some other thinking that produced a couple of other ideas to consider. I shared the above photo with my team and the Support Manager who had a specific interest in this story. I was looking for someone to find a hole or two, feedback that would add more substance and bite. Equally they can respond with “looks good” or similar. I like the extra eyes and different ways of thinking engaging with my work. I feel like I’m testing. As a QA I’m probably doing a terrible job. What am I assuring here?

We execute the walkthrough. The developer demonstrates the changes. The Product Owner is cool with it and I can see that the acceptance criteria has been met. More to the point I can see that it has been met in one way, one scenario. I have one more chat to the Developer. We spoke a lot about these changes, just looking for anything that might be important we haven’t discussed. Seems like we covered anything that sticks out as important. The developer is happy with my ideas around testing, thinks that it will give us a good chance of finding any important problems.

It’s now time to execute some testing of the code. In the perfect world I’d report our conversations and examination of the software were so good that it was bug free. In reality my first test highlighted a circumstance where the reported problem still existed. It was luck that I found it first test, it could have been a few tests in. I just happened to select the combination of inputs that would trigger finding the problem. The important thing is that collaboration and exploration created a level of information and an approach that meant this issue was destined to be found and then fixed. I also reflect on how we might have identified this earlier. I feel like that is testing, pretty sure QA is sadly lacking from me.

I test, I am a tester. In doing my job, hopefully well, I get involved early. I challenge assumptions, I look for possible ommissions, uncertainties and the like. I don’t own this process, I am a part of it. I bring a certain set of skills, but then, so do the other people I work with. I work with people to help produce the best quality we can, not at the end, but throughout the cycle. I try to educate people on testing and have a genuine interest in learning what they do and how we can learn from each other. What I don’t do is assurance. I don’t guarantee anything. I don’t audit others, I don’t enforce or mandate specific practices, I’m not a gatekeeper. I suggest, I learn, I collaborate. Above all I work with people and we all contribute to building in quality as part of our professional commitment and accountability. I’m Quality Aware, I’m a Quality Advocate, I’m a Quality Assistant. I’m a tester, this is what I do.