Yes-Man

Yes-Man Testers: When Is It Time to Stop?

Yes-ManThere 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.

  1. 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.

  1. 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.

  1. 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.

  1. 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.

  1. 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?


TestFort Blog

About TestFort Blog

TestFort blog is an official blog of TestFort QA Lab company and is dedicated to various QA and software testing issues.


3 comments

  1. July 9, 2014 @ 10:22 am Mr.Hack

    It would be great if testers really could refuse to cooperate in such situations. However it’s not up to them most of time, or doing this requires much courage and authority. Great insight anyway!

    • July 25, 2014 @ 2:38 pm Incision

      Here’s an example on how to refuse (to cooperate) in such situations :-

      In one of my previous roles, when I was asked to do a 5 day Test in only 3 days

      HOW DID I REFUSE ?….. I simply presented the coverage to the manager and ALLOWED HER TO DECIDE (i) the 60% that WILL be covered, and (ii) the 40% that WON’T.

      I then presented her the RISKS of the 40% coverage that SHE, THE MANAGER (not me) had to decide to neglect!

      Once signed off, it was all on email for a future audit trail!! .. hence my mind was at rest, and I simply put my feet up and relaxed – but more importantly than that, I did it all REFUSING to show any regret or apology whenever gremlins went out to the Live environment! .. whilst getting entertained thoroughly at the egg on her face after redirecting all criticism & concern back to her!

      Quenching!

      • Testfort blog

        July 29, 2014 @ 7:11 am Testfort blog

        Thanx for your story!
        That well illustrates the sad situations where testers are forced to neglect the product quality which is their first responsibility.. I’m glad you managed to communicate your problems to the manager and take off the responsibility for that uncovered 40%. That’s the major thing I advocate testers should do in the first place.


Would you like to share your thoughts?

Software testing & QA blog by TestFort © 2017

×