The No’s in Testing

Why Say No?

Many think that saying “no” will make stakeholders believe they’re inefficient. However, saying “no” at the right time and in the right situation will only amplify your firm’s value. If you say “yes” when it must be a “no,” you will most likely fail the task. 

When to Say No

We cannot always say “no.” When we do so, we should be able to evaluate our response across specific criteria and justify our negative affirmation. Saying “no” without a reasonable justification will only project a poor image. When you have priority tasks assigned to you, avoid saying “no.” And as much as possible, if you intend to declare a “no,” do so in advance so the other party has adequate time to make alternate arrangements.

However, testers should not hesitate to say “no.” Saying “no” in Digital assurance solutions can be powerful and help build the firm’s reputation. Here is a list of occasions when it would be ok for you to say “no.”

NO regression, NO sign-off: Say “no” to ending a project without a regression. Consider a scenario in which you were requested to sign off on a build that underwent a regression test many builds before the final build. At that point, we must refuse to sign off until a regression test has been performed on the final build.

A detailed brief required: Occasionally, we may be asked to develop a test case with only a few requirements, and the expectation could be that we will get it right. Since this situation almost definitely sets us up for failure, it would be wiser to refuse the assignment.

 If you do write a test case with minimal information, in all likelihood, when all the information has been supplied, you will need to recreate the script and will have wasted your time and energy. Another downside to taking on tasks with incomplete information is that you may end up breaking hard-earned trust and goodwill. 

It is best, therefore, to refrain from taking on a task when you do not have sufficient information to complete it.

Smart timeline, smart outcome: Everything should be completed within a reasonable timeframe. If you need to complete a comprehensive regression, and it takes two days of effort from the entire team, trying to achieve the same outcome in just half the time will likely lead to disappointment. Compromising on the testing will only result in releasing a faulty, bug-ridden application.

As testers, we should not reach an agreement with developers. When you have discovered a bug, describe it to the developer over the phone, and if they have acknowledged that it is a bug, make sure you report it. Some developers may assure you that it will be fixed in the next release and may not want you to log the defect. However, documenting the issue is a best practice for better outcomes.

You might be interested in: Testing a bank application: A Success Story
Golden Rules While Saying No
Saying no can be difficult, as these professional instances can sometimes affect our dynamics with an individual. However, avoiding a confrontation in the short term could lead to significant issues that can escalate over time. Classifying your personal and professional dynamics is advisable, as is saying “no” when required.

Briefly describe the problem: Sometimes, letting the other person know our difficulties can resolve a lot of pressure. Occasionally, you will be granted a day to perform an automated regression. Some believe automated testing is as simple as clicking a button and receiving a report, but those who work on the ground understand the challenges.

In this circumstance, make sure that you explain the ground reality and provide an approximate timeline by which you can complete the task. Even if you do not receive the requested timeline, you will receive an extension from the prior timeframe, which is preferable.

Suggest an alternative solution: If you believe a request is not feasible, you should tell them “no” and explain why it is not achievable. Offer an option that is preferable to you and can work just as effectively for the requester. 

Always be straightforward: Provide straightforward responses, even if the information is unpalatable. When you want to say “no” to something, say so clearly rather than dodging the question. Clarify how much can be examined in a particular time or how much time is required to test it thoroughly.

Consequences of Saying No

Contrary to our fears, it is hardly likely that you will suffer loss when you say “no.” Instead, you stand to gain. Some benefits that you’ll see:

Improved reputation: People will be pleased to collaborate with you since your testing service will produce a high-quality product.

Increased billing: People will have a favorable opinion of your company, and there is a substantial probability that your business will expand.

Deliver high-quality goods: When you reply “no” with adequate justification, you will have sufficient time to examine the application thoroughly. When you have enough time to test, the product will be of the highest quality.

Adhere to the procedure: If you are willing to say “no,” you will adhere to the entire project process. You will have everything correctly aligned, tested, documented, and delivered on schedule.

Avoid team pressure: If you are willing to say “no,” you will be able to avoid team pressure, resulting in an adequately tested application.

Maintain strong relationships: When you are willing to say “no,” people may feel annoyed at the outset but will be pleased with the final output.

The relationship between you and the stakeholder will be solid, and they will have complete confidence in you.

To conclude, in the words of Steve Jobs, “Focusing is about saying no.”  Try introducing “no” at various phases of the SDLC and enjoy the incredible results