> That’s because the testers’ role is to hunt for untidy coding and to ensure that any user interaction with your software is free from error. If the requireme

> That’s because the testers’ role is to hunt for untidy coding and to ensure that any user interaction with your software is free from error. If the requirement can be stated formally, in an ideal world, this should not be the case. You can write automated tests and verify systems with a level of precision that humans cannot rival and it's not expensive to do so. If your QA teams are catching errors of this variety it's a symptom of another problem: communication issues. Your QA people shouldn't be catching errors of this variety -- it's way late in the development process to realize that your developers didn't understand the requirements or didn't write tests to specify them. There are a lot of reasons why your QA team is doing this kind of work. Common causes are: 1. The development team is pressured to prioritize budgets and deadlines 2. The requirements are not communicated well, never gathered to begin with, or no single person knows what exactly is being built or why In the first case developers might not be given the time and space to scrutinize the requirements, write tests specifying the appropriate behaviors, and making the effort to build a system to that specification. Your QA department is basically picking up the slack: the development team pushes what they think meets the requirements and waits for the QA team to give them the thumbs up or down. The second is also pernicious and makes the former worse. In an ideal world the QA team should be saving their time and energy for informally-specified requirements and difficult to qualify goals such as, "It must look good in IE 11." There's no way to formally specify that requirement so it must be checked by a human who does understand what that means. I'd caution that if your QA team is growing with your development team then you should treat it as a symptom of a larger problem. In the real world QA teams end up doing a bit of both and development teams don't always have clear requirements. Aiming for the ideal goes a long way to keeping stress down.