Mfcttrf

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?

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.

There is also a different mindset that a tester (or a dedicated QA) would bring to the team: developer "builds things", tester "breaks things".

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.

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.

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.