Why is a dedicated QA team member necessary?

Question

I'm in a software development team where we are two developers often working on different things, but no dedicated QA team member.

Our support person sometimes handles testing or we try to test each others work, or our manager does it.

This is the only place I've worked that doesn't have a dedicated QA team member. I've found QA to be extremely beneficial and think it can help us but I must justify why.

The reasons I can think of are:

1. QA is being done by developers, taking time away from development.
2. No one person has the responsibility of domain knowledge of all our UI and other systems.
3. A dedicated QA who has chosen that as a career actually wants to do it, and be good at it.
4. A skilled QA will have knowledge of writing automated tests

What reasons am I missing?

Answer 1

First I would rephrase your reasons:

1. Testing being done by developers is good at the unit test level. A dedicated QA is likely to have more skill in finding and exploiting situations the developers didn't realize could be problematic (but customers can and will find).
2. A skilled QA will quickly gain knowledge of the entire application domain and then apply it to find situations that the developers with their deep but narrow expertise (which is necessary) can miss.
3. A dedicated QA who has chosen that as a career actually wants to do it, and be good at it. (I wouldn't change this at all - but I would add that it's not rare for developers to resent the need to constantly test and retest when they'd rather be coding).
4. A skilled QA may have knowledge of writing automated tests.

A few other reasons you can add:

• The person who wrote the code is often blind to its limitations because they are too familiar with it. Skilled testers know how to work to avoid allowing familiarity to blind them to problems.
• Skilled testers will deliberately do the wrong thing with the software. This can expose major problems developers would not think to test (personally, I've lost track of the number of times I've been able to force software into a state developers would have thought could never happen).
• Skilled testers will try to find and test every way to use the feature being tested. They won't find all of them, but that's only because every sufficiently complex piece of software has an infinite number of paths through it. I once tracked down a problem that only occurred at the end of something more than 50 steps.
• Skilled testers can help developers choose useful scenarios to automate in unit tests or other automated tests.
• Skilled testers can find problems with requirements documents and/or user stories before coding starts, saving time and money by avoiding rework.

If you're having to make an argument to management, you will want to focus on time/money savings. To do this you will need to do some digging into whatever tool you use to report issues and note the proportion of them (preferably an average over a specific time period) that you think would have been caught prior to release if you'd had a dedicated tester. If you have any numbers relating to the amount of time it took to fix those problems (again, an average per quarter or per month works), use them, and compare against the time that your team needed to fix problems that you found before you released. You can then make the argument that the difference is time your team could have been working on new functionality which is more profitable for the company than bug fixing.

Answer 2

There is also a different mindset that a tester (or a dedicated QA) would bring to the team: developer "builds things", tester "breaks things". (When speaking of a "break things" mindset: Of course, no one is trying to literally break the software, it is just about approaching it from another perspective.)

A tester is dedicated to finding out new information about the thing they are testing, information that might be hidden from everyone (including the developers that made the thing) until it is subjected to a test.

Answer 3

I'm going to take a slightly different focus on this question; my answer is: A dedicated QA team member isn't necessary, but a dedicated QA role is a good idea.

Consider a situation where you have a dedicated QA team member but he does a poor job (or doesn't do his job at all). In this case, you've got a particular solution in place, but the problem isn't being solved. You would need to move "up a level" and focus on the actual problem, rather than the details of a particular attempted solution.

Good QA is indeed extremely beneficial. If the problem is that you feel in your current project that you don't have good enough QA, you (and especially your management) should look at both how you might move some resources from elsewhere to QA and how you might add additional resources to the project for doing QA. Adding a dedicated QA person to the team is certainly one way of doing the latter, but not the only way.

Here are some other solutions you could consider:

1. Set aside one or two days a week for an existing developer (probably the one who's most interested in QA) to work specifically on that, rather than on developing new features.
2. Hire a new developer with a lot of expertise in QA, and have him do the above for part of the week and development for the rest of the week.
3. Hire a QA person who's learned a bit about development and is interested in learning more, have him spend some time on QA and some time on development. (Ensure you allocate some time and resources to training him in development!)
4. Bring an expert from elsewhere your organization into the project part-time to work on QA, especially on training full-time members of your project in QA.

You may choose to use a mix of these solutions over time, and move "focus on QA" around the time over time as well.

There are two advantages to these sorts of solutions:

1. You have more flexibility in terms of resources because you don't have a certain amount of work hours that can be used for QA only and isn't useful elsewhere. Being able to devote a "fraction" of a person to QA means that your manager doesn't have to face the decision of "I need to spend a lot or nothing at all," and risk ending up with the latter.
2. The QA knowledge tends to spread through the team, rather than being concentrated in one place, both reducing the bus factor and, more importantly, ensuring that developers are writing code and developing systems designed to support QA processes, rather than hinder them.

Regardless of who's doing it, during the time someone is focusing on QA he should not be thinking just "today I do manual tests of the system rather than coding," but "today I'm focusing on where we have quality issues and what we can change throughout the development process to mitigate these." This could include:

1. Studying QA to improve her skills at it, testing and trying out QA tools, and so on.
2. Developing tools and systems to help automate tests, at any level (unit to customer acceptance).
3. Analyzing current and past QA issues, and figuring out the most effective place to change systems to mitigate those issues. This could range from changing something developers are doing to changing part of the release process.
4. Training other developers in QA viewpoint and process, so that they tend to produce fewer problems for QA to catch and make systems where QA problems are easier to catch.

What I describe here is really a specific use of a more general agile principle that applies to DBAs, release engineers and all similar roles: everyone involved with the development team is a "developer" and should be allowed, even encouraged, to learn more about things outside their area of specialization so they can contribute in multiple ways to the project. (In other words, avoid "siloing." or having someone involved with your development team who's not supposed to work on development.) To do this you make specialists roles, rather than people, so that the the QA specialist "puts on her QA hat" rather than being "just the QA specialist."

To summarize: rather than making your dedicated QA, make it a role, and have someone dedicate time to that role. It doesn't have to be a lot of time (certainly not full time in a project with only two developers), but you need to ensure you remove pressure to work on anything else during the time dedicated to that role.

One further note, your issue that "No one person has the responsibility of domain knowledge of all our UI and other systems" also is bad, though that sounds to me as if it's a customer role rather than a developer role. Agile has similar solutions for this, too, though I won't get into them here.

Answer 4

Like many of the other roles (particularly in smaller teams) a dedicated person performing that role probably isn't actually necessary and may even be a point of inefficiency in some situations. That said just like with any other specialization in software development, having expertise, interest, and dedicated time to focus on a particular problem area will often enable the dedicated person to either bring their experience to bear on the problem or add insight when coaching their team to take on this mindset or the activities as part of their work.

Many development teams where I work are experimenting with either no-QA models or using QA much in the same way you might an agile coach. There's a lot of value to be added when you encourage a team to follow practices that result in higher quality outcomes whether or not you're doing testing yourself.

Answer 5

I would like to argue that a dedicated QA member is NOT necessary.

A very good developer is a also very good tester. Yes, you need to learn and practise switching between building, breaking and a user-centric mindset when validating that the software built works as expected.

The last four years I worked with three teams (of four developers) that had no dedicated testers. I functioned as their outside Testing Coach. They build better quality software then my current team which has three testers and three developers.

Keep in mind I am not against dedicated testers at all, but there are risks in handovers to dedicated QA-members. Mainly that quality is not a whole team approach. QA lags behind. Developer-QA issue ping-pong. Context switching. Crappy test automation. QA shortcuts under release time pressure.

There is some literature about this aswell, like in his book "The Clean Coder" Robert C. Martin writes:

QA should find nothing

Therefore, when you release your software you should expect QA to find no problems. It is unprofessional in the extreme to purposely send code that you know to be faulty to QA. And what code do you know to be faulty? Any code you aren't certain about!

Alan and Brent discussed this on their podcast and came up with the following Modern Testing princible, which also suggest that dedicated testers might not have a future:

We expand testing abilities and knowhow across the team; understanding that this may reduce (or eliminate) the need for a dedicated testing specialist.

https://www.angryweasel.com/ABTesting/modern-testing-principles/

Answer 6

Dedicated QA as a distinct element from the direct programmers achieves two critical things for software development:

1. It helps distance testing from coding, thereby reducing bias.

   • Smart programmers don't make bugs, all programmers like to assume they're smart, therefore programmers don't make bugs... Combine this with deadlines that programmers are driven meet, and you have a very nasty snowballing cycle where lots of little things are "Overlooked" with the idea they'll be quietly fixed 'some time later'.

2. Keeping QA as independent from Programming helps reduce the temptation to gloss over QA because the manpower resources are 'needed for code'.

   • By keeping a core team with a focus on QA as their primary job, they can maintain the freedom to actually test and explore the software, and dedicate time to long term QA development. When trying to have core programmers do the QA work along side development, then it is far easier to let the QA side slide and risk a snowballing nightmare.

   • However even then it is far too easy to allow QA to fall into "Rubber Stamp Mode" if they are understaffed and not allowed enough time between code 'completion' and release. Understaffed and under-supported QA teams are also a road to the snowballing nightmare.

Beyond that a good QA serves as a check and balance process to both design and code. They help highlight issues earlier in the process, thereby saving a project time and money.

• In my career I've seen half-hour meetings between QA and the Business Analyst team spot and help correct a flaw that would have accounted for months of development time.

Answer 7

As per my observation, the dedicated QA will help the below process:

1) QA can help the dev team to capture the different failure scenarios and breaking of the system.

2) If QA is a most senior person working with the junior dev team then he can guide the team to build the project or process.

3) Since dev team is working in different modules in a bit and byte of the pieces, QA can find the problem in the integration of the components and system.

4) If QA is the product specialist then it will help the dev team to get the info quickly instead of waiting from the business team or product owner

Answer 8

To avoid restating what other answers have, this'll be brief.

• Developers usually cost more than QA people for the same amount of their time.
• QA and development can be done in parallel, if there's a separate team.
• Reporting defects in a way that's informative, and can be reproduced, is a skill in itself. Many developers are not skilled at this.
• When testing/debugging your own software, you have an idea of how it works internally. The target user does not. This makes self-testing a little unrealistic, especially for defects in the documentation.

Answer 9

For your team size, a dedicated QA member is probably not appropriate.

Doing the various aspects of QA well requires the proper skills, and in a sufficiently large team it might make sense to have specialists. But with just three "IT guys," counting the two devs and one tester, this isn't the case.

• If you have dedicated QA, you need a "senior QA guy" who can talk to "senior devs" and "senior architects" as a peer when it comes to budgets, timetables. and priorities. That's not just a job title, it is also a question of pay scales and influence within the company structure. A lone tester is just a tester, not a certified test manager or department head or whatever.
  • This becomes especially relevant if you want the QA to check on the work of the devs. That means you are creating a somewhat adversarial situation. Then the QA cannot report to the dev manager, it must be a direct report to someone higher up in the chain.
• If you tell one out of three that he or she "is the QA part of the team," then you tell the other two that they're not. They will test less and deliver more badly-tested code instead. And if the lone tester has a vacation or a sick day, you have a problem.
• I believe that test automation is a job for the devs on the team, possibly in cooperation with the test analyst if you have such a specialist. Having the devs also do the manual testing is a great incentive to automate what can be automated, instead of ignoring it as other people's problem.

Answer 10

If you're doing serious business in IT I think it's better to let your code check from a specialist in the QA field. Otherwise you risk delivering broken software to your clients which will result in a negative feedback loop (deliver bad software -> anger your clients -> you get less new clients -> you deliver bad software -> ...).

Plus, if you're using SCRUM as project management when developing your software, there is no QA tester role anymore. Testers are just part of the dev team and regarded as such (which in IMHO is very good and just logical). This should be a standard but it'll take some time for the industry to get to this point.

Yeah, and of course there is this "devs build, testers break things" thing. :-)