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:
- 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.
- 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
- 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!)
- 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:
- 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.
- 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
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:
- Studying QA to improve her skills at it, testing and trying out QA
tools, and so on.
- Developing tools and systems to help automate tests, at any level
(unit to customer acceptance).
- 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.
- 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.