Why is a dedicated QA team member necessary?
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:
- QA is being done by developers, taking time away from development.
- No one person has the responsibility of domain knowledge of all our UI and other systems.
- A dedicated QA who has chosen that as a career actually wants to do it, and be good at it.
- A skilled QA will have knowledge of writing automated tests
What reasons am I missing?
First I would rephrase your reasons:
- 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).
- 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.
- 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).
- 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.