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 Product’s 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.
Defect Management Handled as a Mere Process
Defect management is a very important activity in a product development effort that touches multiple entities in the team. Given that several people get involved in this process, unless the team understands the true meaning of defect management, it can soon become a very mundane formality. I am not discounting the value of the defect management effort even when it becomes mundane; however, the tester as a champion of end user quality should then speak up and say no to help the team understand the true value of defect management and help them adopt a better approach.
For example, let us say that the final veto power for determining a defect’s resolution is with a certain individual, and that person continues to punt bugs to ensure the team’s workload is under control and that they are able to meet the cost and time constraints they have. If a tester truly believes these defects are important from an end user impact standpoint, he should have the courage to step up and say no to such factors—including the fact that the veto power rests with just one individual.
Pressure to Showcase Mere Numbers from Test Execution Efforts
Pressure to showcase mere numbers from test execution efforts is slowly changing in the industry, which is heartening. However, in several groups numbers still mean everything, including how many tests were executed on a given day, how many tests were designed, etc. Similarly, it is still not uncommon to see teams where test automation is purely looked at as a progressive number game: In the last release we automated 40 percent of the overall tests, so in this release, we will reach 50 percent.
It is high time the tester says no to such number games, which lack interpretation and alignment to product quality. However, rather than just saying no, if the tester is able to explain to the team what metrics really carry value and what the team’s automation strategy needs to be, there will be more acceptance to his “no” rather than his response being seen simply as a denial.
Direction to Take on Tasks That Interfere with a Tester’s Standards
Collaboration has become necessary in product development. Kanban styles of development that promote load balancing are being increasingly practiced in teams. While the team works together toward the common goal of a successful product release, if the “togetherness” means that the tester is often asked to take on tasks that interfere with his testing independence, he should learn to tactfully say no and draw a delineation between himself and the rest of the team’s responsibilities—especially those of the development team.
This advice is applicable not just to test teams within a core product team, but also to outsourced test teams, who often have the incorrect perception that saying no will lead to a bad reputation with their clients and the product teams. The more they exercise this power in the right ways, the testers will soon realize the client now sees them as strategic partners who really understand product quality as opposed to mere followers of tactical instructions.
The Results of Saying No
The above examples are by no means an exhaustive set of the varied situations when a tester will experience the need to say no. However, they are some of the important categories where most testers shun saying no that could result in consequences for the product’s quality and the tester’s work/life balance. The other adverse effects of not saying no in these situations are a dilution of the tester’s role, losing testing independence, and negatively impacting the respect a tester deserves on the product team.
Testers should think and act in these situations as is applicable in their roles. Doing so will not only boost the respect teams have for their own testers, but also help hold high the respect of the entire testing fraternity. In almost all situations the response may have to flow top-down in a test team, but if the entire team inculcates the mindset that it is not just OK, but important to say no at the right times, testers will earn a newfound respect that they and the profession deserve.
User Comments
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.) :)
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.
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.
Completely agree, Mark!
@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.
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.
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
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.
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.