When Testers Should Stand Up and Say No

[article]
Summary:

Testers often find themselves in predicaments where they may be asked to compromise on quality standards—whether it's pressure to sign off on a product before it's ready, getting involved in numbers games that value metrics above all else, or facing harassment to take on work that isn't theirs. Knowing when, how, and why to say no can improve your situation and gain respect for testers everywhere.

How often do we say “no” in our professional lives? The count really does not matter; what is more important is saying no at the appropriate times and saying it tactfully in order to accomplish our end goals. (You do have a goal, right?)

The difficulty of knowing when, how, and why to say no is not unique to the testing community—this is universally applicable to all disciplines, across all domains, and often stretching into an individual’s personal life, too. At the end of the day, rightfully saying no helps you draw your priorities and maintain sanity in the workload you handle day in and day out. It also helps improve judgment and prioritization skills while building self-confidence.

How to say no has been covered in many topics, but today, let’s discuss some situations for our specific roles—how to say no as a tester.

Scope Creep

Scope creep is a problem for the product’s health if not planned for and timed well. While every discipline will put forth its case on whether it is OK to take in scope changes, the tester who holds the responsibility to finally sign off on the product’s quality should learn to say no if scope changes wouldn’t leave enough time to test them thoroughly. However, when saying no in a situation like this, the tester needs to have done his due diligence and homework so he can explain the impact of such scope changes, especially when done later in the game. This is beneficial both from the standpoint of a tester’s workload as well as from the end user product acceptance standpoint.

Pressure to Sign Off on the Products Exit Criteria

Although testing as a discipline has moved upstream in the product development lifecycle and is no longer relegated to the final phase of a few weeks just before product release, the tester faces the same amount of pressure (if not even slightly more) compared to other teams at the time of signing off on product exit criteria. Quality checks are an important component of the exit criteria, and despite the current reality of commencing testing activities early on, a tester continues to be very busy at the time of sign-off, whether it is in finishing pending test execution efforts, or mapping back his test results to determine overall traceability, or regressing defects, or interpreting the overall test efforts to the product’s exit criteria.

While this is often done under tight deadlines, a tester needs to maintain his calm in objectively carrying on his work at this stage. Oftentimes there is undue pressure from various stakeholders and senior management, forcing the tester to sign off on the exit criteria prematurely to ensure the release timelines are not impacted. While the tester must be cognizant of the timelines and the external commitments made to the market, he should not fear refusing to sign off on criteria if he truly believes the product is not ready for the market. While this is a very sensitive area that may impact the tester’s reputation in the team, if he is able to justify his decision with information such as the end user impact, the team should appreciate the fact that he did not succumb to pressure.

User Comments

9 comments
Violet Weed's picture

Interesting but naive perspective. It is NEVER EVER EVER up to a TESTER to stand up and say 'no'. The testers are not 'standing in the gap' for Quality. The role of the tester is simply to verify the state of quality, as much as possible, by testing inside and outside the 'black lines'. To verify what works and what does not work. I know that testers would like to be able to stand up and issue forth a rallying cry: "No, this product shall not be released! It does not pass our basic quality metrics; ergo, must not 'go live'." Alas! That is not the role of testers. The role of software testing is to provide testing results to the test management. The test management then analyzes the testing results in order to evaluate the state of quality of the product under test, then provides the stakeholders with that educated evaluation. It is up to the STAKEHOLDERS to say "no", not to individual testers on a team. Thinking that testers or developers have the endgame regarding release/no release is a classic misstep that can happen when the software development company or branch of an organization is using 'agile methodology'. It is not up to the developers or testers to determine if a product will be released in its current state of quality. There are many reasons to release a less than top quality product, if / when everyone understands the risks, has blocked the defective code (and features) and the customers accept the risk too. Of course I am not talking about a new and improved safety software controlling a nuclear power plant or weapon. But I've been in QA for the past 30 years and now understand what testing is for. To determine a product's state of quality, not to decide the fate of that product. (Yes, it's in my book.) :)

May 28, 2014 - 1:54pm
Mukesh Sharma's picture

 

Firstly, thanks for taking the time to read the artcile and share your thoughts. I respect your experience in the discipline and your views on this topic. My stand here is that, as a tester when you send your results to test management, the focus should not be on just sending back pure results from the tests, but actionable data based on the results with your viewpoints especially, if you strongly believe the quality is in bad shape. If you see I have mentioned in the article that the tester needs to be “cognizant of the timelines and commitments made to the market” encouraging the tester to understand the big picture too. However, the takeaway I am insisting is for testers to come out of a pure “I execute tests – here are the results-I don’t have anything more to do with these” mindset to “Here are actionable results from my tests – if I believe the product’s quality is not ready for release I will provide justification including points such as user impact” so it will help my management and stakeholders know why I am not signing off on my test exit criteria. This will empower them make that final educated release decision taking into account several other factors which the tester may not be privy into.

 

May 29, 2014 - 5:46am
Mark Jones's picture

As I see it, the test function can seek to influence stakeholders on whether or not to release, providing a measure/evidence one way or the other. I do seek to release a 'top quality product' and such a product gets my seal of approval. Anything less doesn't get that and receives my recommendation that it needs more time. If there is a determination to release (often for commercial reasons, and, as you say Violet, with the customer accepting the risk) then I've got a raft of evidence to prove I didn't back that decision and a list of known defects is supplied. That way everybody knows where they stand and there shouldn't be any recriminations.

May 29, 2014 - 10:40am
Ramon Es's picture

@Violet Weed

It depends if the role is defined as "software testing / quality control" or as "quality assurance". When a tester is tasked with quality control then I agree with you. The goal then is to report the health of the product in its current state.

Quality assurance is a different thing. The person is asked to assure quality and in that case there has to be some level of decision and veto power. Also, the involvement starts early on in the requirements phase where as quality control compares only the requirement with reality.

When the goal is to deliver high quality product then there is absolutely no way around quality assurance. A quality expert in that role has to be equipped with the power to say "No". In fact, that is exactly what this role is supposed to do.

 

June 4, 2014 - 11:36am
Mukesh Sharma's picture

Thanks for sharing your views Ramon. Agreed. And given how the push has been for testers to move from a pure QC function to a QA-QC function, it is becoming more important for them to understand they have the right to say "no" when required and use it judiciously.

June 7, 2014 - 12:29am
Harry Bowen Jr.'s picture

As I continue to say to folks who listen at any job I'm at:

!. The bugs drive the schedule (to a point)

2. QA just produces the facts, we don't decide a go/no-go on our own

If we present the facts, it's up to the stakeholders to determine their level of comfort in accepting the risks involved in releasing something with potential issues as our facts can show

June 9, 2014 - 1:37pm
Mukesh Sharma's picture

Thanks Harry for your inputs. I agree the tester does not own the product release decision. That is a desicion dependent on several extrinsic and intrinsic factors that he is not privy into. It is not his job either to take that decision. However, when he turns in his test results, if the quality is not in good shape he needs to speak up for it and share what potential end user impact would be. This will show up in the test exit criteria that the testing discipline owns helping the stakeholders take an informed decision on the product release.

June 11, 2014 - 6:11am
Louanne Poisson's picture

Loved the article.  I wish more software testers had the guts to make candid assessments to stakeholders. Maybe I wouldn't stand out so much, thus getting my head knocked off at regular intervals.  Thanks for the article; made my day.

July 7, 2014 - 7:47pm

About the author

Mukesh Sharma's picture Mukesh Sharma

Mukesh Sharma created QA InfoTech with a vision to provide unbiased Quality Assurance (QA) solutions for business partners worldwide. As CEO, he is responsible for the company’s global operations, marketing, sales, and development efforts. Under Mukesh's leadership, QA InfoTech has grown to five centers of excellence, 600 employees, and over $15 million in revenue.

Mukesh’s career spans DCM Data Systems, Quark Inc., Gale Group, and Adobe Systems in software quality engineering and test management roles. Mukesh is an active test evangelist.

AgileConnection is one of the growing communities of the TechWell network.

Featuring fresh, insightful stories, TechWell.com is the place to go for what is happening in software development and delivery.  Join the conversation now!

Upcoming Events

Nov 09
Nov 09
Apr 13
May 03