QA Role in Development Team

As developers, we love to hate on QAs. I’m just kidding, of course. I love my QA. I love that they find bugs in my team’s code. It’s my favourite part of the agile waterfall development that we have. But, in all seriousness, let’s talk about a QA’s (Quality Assurance) role in your development team. Do you even have one on your development team? If you don’t, why not? Do you actually need one? Let’s dissect a little.

Why Should You Have a QA on Your Team?

I’ve been in teams that have had QAs and some that have not had QAs. Also, some who have had a dedicated QA team — but let’s not get into that now. Let’s start with why you should have a QA from my experience.

• 
  

  QAs know your program/website inside out. In my experience, QAs tend to keep every little detail and quirk of your program in their head. You know that little feature you developed twelve months ago? They’ll remember that and mention it as a potential side effect of your new feature. Can’t remember what table connects to what UI? They’ll usually have that information nearby.

• 
  

  QAs will test every little corner of it before your new feature goes live. One thing I notice, when developers test, is that we tend only to test the happy path. And that’s fine. We don’t want to break our system; we want to validate that it works as we programmed it to. You can see where I’m going here, right? As a developer, you’re likely not to catch the bugs in your system. You know the code, and so you know how it should work.

• 
  

  QAs can make your development faster if they’re involved earlier in the process. You might not know the whole project. QAs tend to be curious and want to know what every single button will do. If you involve them earlier (i.e. before you want to release), they’ll help you with some of the architecture, find bugs and potentially missed requirements or misunderstandings.

Why Should You NOT Have a QA on Your Team?

So, as I said above, I’ve been in environments where we haven’t had a QA. We still shipped working software. There weren’t many bugs. What gives?

• 
  

  QAs can be blockers. Sometimes, you don’t want to wait for the QA to test because the feature needs to be out today. Usually, if you have a QA, they need to test before your work can go live. That can be frustrating if the QA is busy testing something else or is away. Obviously, you can get around this by releasing without testing — but do you really want the ire of a colleague?

• QAs will test every little corner of it before your new feature goes live. You and I both know that this new feature is so small — you only need to check if she can click a checkbox. But wait for just a second — the QA needs to double check that the whole happy flow still works.

• 
  

  QAs can be replaced with good automation. This last point is very bad. Like so bad. I’ll probably get death threats. But in all seriousness, if you have a good (and by good I mean perfect) set of automation tests (Selenium etc.), then you may not need a manual check QA.

• 
  

  You’re a very small team/startup. I would say you don’t need one yet. Sure, quality is great — but sometimes speed is better. Especially when you’re in your initial stages releasing an MVP. Your customers won’t mind a few bugs features while you deliver them new value.

What I’m not trying to do is prescribe one way or the other. But I do want you to avoid having a separate QA team. This is bad because it will slow your development down and take you off the agile approach. Imagine the waterfall model. This is what will happen if your have a separate QA team who picks up work when it’s handed to them. It may look like you’re working agile, but really you’re just pretending to be agile.

I’ve found, the bigger the company gets, the more likely you’ll find QAs. Sure, the dev team and put on a QA hat, but will they find a bug that team b introduced when they merged their code four days ago? Probably not. Like I said, developers tend to only test happy paths. But — we should always try to aim for some sort of automated testing. Even with QAs. That’ll reduce the burden on the QAs to test every path and speed up their process of giving you a big stamp because they trust you.

On a side note, you should also eventually train your QAs in code. They don’t need to know the ins and outs — but if they could write the automation tests themselves (with your help of course), then everyone will be better off. You’ll have QAs who can continuously improve your coverage and therefore quality while reducing the amount of manual effort they’ll need to do per story.

Summary time!

I think there’s inherently more trust in a system when there is kind of gate-keepers (in this case QAs). But, you would only need one if you’re finding the number of bugs that are being reported is increasing and your developers are becoming stressed that they don’t really trust their own code anymore. This becomes more serious when you have a lot of legacy code. No one wants to touch that stuff. If you can have a QA to document the functionality — that’d help everyone long term. QA = Good. QA team = Bad.

Originally published at www.alexaitken.nz on June 25, 2018.