Until recently my team had a very simple set up for our sprint board, with just four steps: Tickets would start as “To Do”, move to “In Progress” when somebody started working on it, then put into “Code Review”, and when everything looked good the code was merged and the ticket marked “Done”.
This worked well until we started to have issues with tickets after merging. A separate team was responsible for building a release and deploying it. As we started to put more tickets through we started to find occasional issues at this stage, either just before deploying or soon after. These didn’t go unnoticed for long — we regularly check all our features in production — but they did show that we needed to pay more attention to the work between merging it and deploying it.
The natural inclination of the team was to do what most other teams in the department have already done: insert a “QA” column between Code Review and Done, where we can test the final build for anything unexpected.
I wasn’t on board with this plan. I think it’s too easy to start thinking that QA only happens when a ticket is in that column. Even if everybody says they know that’s not true, the board can reinforce that idea anyway. Following Richard Bradshaw‘s cue, I tried to explain that QA is something that happens, or should happen, throughout development. The problem is, I didn’t have a good alternative name for that new column:
To me, “Testing” is just as limiting as “QA” (should I not do any testing when something is in code review?) “Verification”, the other candidate, to me seemed too narrow for what would go on in that column. I would have been happy with anything but “QA”. But I’m not sure I really made my point—or they took it too literally—because we ended up with this as our board:
And from there it was a small step to this:
This has had one delightful side-benefit: at our daily stand-ups, instead of asking if a ticket is done yet, we can now legitimately ask: “Are you a wizard yet?”
I recently had a conversation with my team about what we should call the status between when work is passed “code review” but not yet “done”. The one thing I didn’t want to call it was “In QA”. One of the developers on my team had another idea that I decided to run with:
Let me explain.
Much like Richard Bradshaw says in this video on “QA” as a term, it doesn’t make much sense to me to name one stage of a feature’s development as if that was the only stage at which QA was done. Michael Bolton regularly insists that quality assurance isn’t even a thing testers do (or should do). (Although interestingly when I brought this up in Testers Chat, Michael was the one to ask whether the name we picked would even make a material difference.) The argument generally goes that testers don’t assure quality. We can do all sorts of other things to it—inform it, study it, encourage it, foster it—but we can’t guarantee or enforce it. We especially can’t do it after the code is written.
Maybe this one is better?
I’ve mentioned before that the terminology at my company is “QA” rather than “Testing”. Asking the difference between “QA” and “Testing” is another sure-fire way to spark debate but I don’t think a piece of development should ever be in a discrete “In Testing” phase either. Generally I’m not too concerned about calling it one or the other; I’m much more interested in what people are actually doing. I haven’t seen any of the dire warnings about using “quality assurance” come true where I am now, but I’m not going to risk encouraging it with an “In QA” phase.
Here’s a third attempt at a better name for QA:
The idea that the developer on my team had was this: if I was so set against calling it anything but “QA”, let’s just take synonyms for “quality” and “assurance” and come up with something that didn’t have all that baggage. He was joking, but I ran with it. I ran with it about 13 thousand times.
Here, come up with some of your own:
This is a little script that will randomly pick alternative terms for “quality assurance”. Very rarely it might actually suggest you stick with “quality assurance”. I do not vouch for any of these being good suggestions, but I think at this point I’m more interested in discussing the merits of “quirk investigation” vs “constitution corroboration” than I am hearing more complaints about “quality assurance” as a term.
The standalone link is here if you want to keep generating more ideas, and I even made a helpful Twitter robot that’ll tweet out a new idea every day. Hit me up on my Twitter or leave a comment if you want to make sure your favourite synonyms are included. Let the pedantry begin!