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?

  • 3
    Quite simply, QA are cheaper than developers and are more skilled than developers at QA. It's like asking why do you hire an accountant to manage your accounting instead of getting your developers to do it instead. Developers are ill suited to the job of QA in the same way that they're ill suited to Accounting.
    – Stephen
    Jul 25, 2019 at 0:24
  • 1
    @Stephen Disagree with "more skilled than developers". I think what you mean is that they haven't been inducted into the insane groupthink that we impose on developers called "architecture" and "coding standards", which allows them to interact with the software in a very different mentality from a developer.
    – Aron
    Jul 25, 2019 at 1:45
  • 10
    @Aron So they're more capable than developers at doing the job they're being asked to do (QA). It doesn't matter what the reasons for it are, QA specialists are better at doing QA tasks than developers, whose primary task is development.
    – Stephen
    Jul 25, 2019 at 2:50
  • 2
    If two developers need a dedicated QA, y'all better both be goldenchild's and writing some very choice code that does things like launch space shuttles. I'll assume you aren't and that you don't, so good luck convincing your manager that a full 1/3 of your workforce should be ancillary. "justification" is the most important word in the post; if health and safety, or the company's reputation, aren't endangered if it's bad code, the only thing that justifies hiring more people is the prospect of making more money.
    – Mazura
    Jul 25, 2019 at 13:58
  • 2
    @Mazura it's company reputation at stake.
    – blarg
    Jul 25, 2019 at 15:48

10 Answers 10


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.

  • 4
    This is an excellent response.
    – blarg
    Jul 24, 2019 at 12:18
  • 8
    You touched on it, but maybe you want to add this angle specifically as it may speak to management's view: Being good at developing takes time and "brain capacity" and thus money. The same holds for testing. The skills are separate and most people can improve in either areas for all of their professional life. Time spent by developers trying to get better at testing isn't time spent developing or getting better at developing. Hiring a QA person means they already have the skills and instead of wasting money (time = money) on developers learning how to test, you save that money. Jul 24, 2019 at 20:00
  • 12
    To me the #1 reason is the problem of the developer being blind to the errors because he sees the code he wanted to write, not the code he wrote. Jul 24, 2019 at 22:30
  • 2
    I'd put a little more emphasis on the If you're having to make an argument to management, you will want to focus on time/money savings. part. If management is not technical at all, they may just hear "we want you to hire someone who will do part of our job for us*
    – Mars
    Jul 25, 2019 at 4:32
  • 1
    +1, but here is one more crucial one: QA is a separate set of eyes (and mind) reading the specs and flushing out unsaid assumptions - which might be different from what developer assumed. Jul 26, 2019 at 18:15

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.

  • 4
    This is a very common misconception, that can quickly fall apart with some thought. Testers didn't write It so they didn't break It, they tend to not change the program/code they are testing. So there's quite no way to break anything. Unlike a physical object that can be broken by dropping it or using it in an unexpected way, software can only be broken by those who created it. Testers just find places that are broken and report them. Sometimes, it isn't even actual breakage so much as something that doesn't work the way customers expect or want it to work. Jul 24, 2019 at 17:50
  • 1
    @MobileQA one could argue that little Bobby D. Tables actually broke the database. It stopped functioning in an case. I think a good tester will go beyond just finding broken things. At the very least I'd expect them to find things that might be working, but are unsafe in the sense they won't resist abuse, whether naive or intentional. This is different from most developers that focus on the happy path (can I achieve specs if I use my code properly, knowing exactly how it works) and don't necessarily attack the specs either.
    – ptyx
    Jul 24, 2019 at 22:58
  • 1
    @MobileQA I was speaking more 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.
    – Mate Mrše
    Jul 25, 2019 at 6:37
  • 2
    Unfortunately though, the "breaking things" way of describing a tester's perspective has a bad tendency of leading to even more illogical words and behaviors. For example, "We could ship this faster if those testers would stop breaking everything." We break assumptions, or as Michael Bolton often says, "We break illusions about the software". That is our mindset, but if we aren't clear in the way we discuss it, people can easily fall into illogical blame games, "shooting the messenger", etc., etc.
    – c32hedge
    Jul 25, 2019 at 17:16
  • 4
    Also see developsense.com/blog/2015/02/… for Michael Bolton's much better explanation than I could put in a comment :)
    – c32hedge
    Jul 25, 2019 at 17:17

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.


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.


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.


  • Niels, with respect I disagree with your point.This may be true for very mature organizations where Developers & testers are mostly on same level in both skills set but not in general mid to small size organizations where testers are not too technical and developers lack the domain knowledge and in general testing skills. Jul 27, 2019 at 15:23
  • @VishalAggarwal Fine, I have this discussion all the time with people. You have to experience a good Agile team with 100% test automation and decision making based on data to be really convinced. Still I think you can teach developers and in mature organisation have no more testers at all. Development teams should practise technical excellence, testing is a big part of that, but i truly think you do not need a separate role for it, nor special skills: less.works/less/technical-excellence/index.html Jul 27, 2019 at 18:00

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.

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


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.
  • 3
    Most good QA people I know are more expensive then the developers they work with. You would expect good developers are better at reporting defects, because they know which information they need to fix it. The you cannot test your own work is such an old-fashioned argument. Jul 25, 2019 at 14:22
  • 1
    Old-fashoned in what way? I meant that your mindset, and approach are different when defect-checking something you made. Developers knowing how to fix something, and explaining/documenting that are different things. (IME, programming skills and communication skills are inversely correlated in people)
    – bobsburner
    Jul 25, 2019 at 14:32
  • Good programmers are good communicators. "If you can't write it down in English, you can't code it." (Peter Halpern, Programming Pearls, CACAM Sept. 1985.) " Joel Spolsky, here and here says that native-language writing skills are one of the three most important things for a programmer to learn, and "I won’t hire a programmer unless they can write, and write well, in English."
    – cjs
    Apr 14, 2020 at 2:29

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.

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. :-)

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.