There are often situations when testers find themselves made to compromise on some quality software testing standards. Testers are sometimes asked to approve the product’s quality before the product’s finished, to take on somebody’s work, etc. Given an increasing flexibility required from testers today, it’s even more important for them to know when it’s time to say ‘no’.
Here are 5 situations when we think software testing specialists shouldn’t agree to put their sign under the product’s quality.
- The project’s scope is changing.
Scope creep undermines the product’s health significantly if it’s not properly planned. If there’s no time for testing such scope changes, it’s an imperative for testers to inform the stakeholders of the possible outcomes of this situation and in mow way should he sign off on the quality as due.
- The tester is pressed to approve unrealistic exit criteria.
It’s all about meeting deadlines. Despite the current model of the project development process is agile and all, and testers are supposed to make QA checks regularly through the development rather than at the very end, pre-release quality checks are still keeping testers busy just the same. And because testers are still responsible for these finishing strokes before the launch, their part of job is the most vulnerable when the development schedule is tight. When forced to approve the exit criteria of the product with seriously compromised quality issues, testers should refuse to do this and explain his position properly.
- The defect management process became a mere formality.
Good testers shouldn’t agree to this degradation of defect management procedure. Instead, it’s their obligation to help their teams improve this process and make a proper use of it.
- Numbers are valued over test execution efforts.
It’s mistakenly considered that the quantitative aspect of testing prevails over qualitative. That is, the efficiency of testing is measured not in the number of tests performed or percentage of tests automated, but in the results and benefits to the project’s quality. The tendency of number racing is gradually disappearing and testers should help in this atop of just refusing to follow it.
- The tester is made to accept tasks interfering with his direct responsibilities.
Close collaboration and some extent of responsibilities’ integration in the team takes place widely as IT companies adopt new generation development management processes. And this is where it’s especially important to watch that this collaboration doesn’t interfere with your direct testing responsibilities assuming harmful effects to your productivity and the overall project quality.
In which situations do you think testers should say ‘no’ and why?