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.