Projects close bugs for many reasons. Maybe it’s hard to reproduce. Maybe it’s a ‘Will not fix’. This is the end, really?

In the testers world, it’s in our nature to report problems:

“No it doesn’t work when I do this”
“No it doesn’t work when I test feature A and feature B together”
“No, the loading spinner just keeps going”

We say the word ‘No’ more than ‘Yes’. Did you know there is a “Yes, and…”, a rule in improvisational comedy? Here is how it is defined on wiki:

…a rule-of-thumb in improvisational comedy that suggests that an improviser should accept what another improviser has stated (“yes”) and then expand on that line of thinking (“and”).

Let me tell you the wrong way to use the “Yes and…”.

Bad customer support

Here is a recent experience for an online account registration:

Administrator: Thank you for registering with us. To proceed with the process, please review the attached pdf and install the relevant software. You can also click on the link here for the same document.
Email: No pdf attached. The link goes to a private Google Doc.
Me: (Worded in a nice way) What are you talking about Admin? There is NO attached pdf the email. The link doesn’t work for me either!
Administrator: Yes I double checked the document on my side, and I can access it fine.
Me (thoughts in brain): ARGH, HELP ME. That ain’t how ya supposed to use ‘Yes and’.

No, but…

In tester-speak, how about if we experiment with ‘No, but… (opportunity)’? Yes, I just made that up. We accept there is a problem, but we also leave the door open for more observations. When we ‘but’ (verb) more things, we can expand our minds and think differently about the problem:

No, but when I try it a different way…
No, but when I change the config slightly…
No, but if I check the test data I used, I noticed…

Maybe if the admin learned to say ‘No but’, they could’ve helped me. They could’ve tried to attach the pdf again or granted me access to GDocs. Instead, they left me grinding my teeth. If bug tickets were sentient beings, maybe this is how they would feel if they were closed.

Bug reporting

What can we learn from this? Well, I believe ‘Workarounds’ is underused in bug reporting. I’m guilty of this myself. Compare these simple bug reports that I just pulled from my imagination. Tell me how it makes you feel, listen to your heart.

Closed bug report 1 - No workarounds

Title: User unable to log in to install the fruits app (intermittent issue)
Steps to reproduce: Type in username and password, click submit. Go to the app directory and click install on the fruits app.
Actual Results: The loading spinner continues indefinitely, instead of a successful install.

Comments: Closed, this is expected behaviour for the fruits app.

Closed bug report 2 - Workarounds suggested

Title: User unable to log in to install the fruits app (intermittent issue)
Steps to reproduce: Type in username and password, click submit. Go to the app directory and click install on the fruits app.
Actual Results: The loading spinner continues indefinitely, instead of a successful install.
Workarounds:
- Check if the app is already installed by navigating to ‘Installed apps section’. (Confirmed)
- Check configuration for app permissions for that specific user (Confirmed)
- Clear the cache on the browser and try again (Confirmed)

Comments: Closed as the behaviour is due to technical limitations at this point in time. The workarounds are confirmed to solve the customer’s problems.

What are the benefits?

It helps with prioritising tickets - we closed this bug ticket because there is a workaround, here is the workaround.
It helps with solving customer problems - the IT technician read the bug report and told the customer how to solve their issue.
It helps to show you are a master tester - you have provided a solution, you’re not just playing the role of a reporter.

Consider using ‘Workarounds’ in the bugs that matter most, even if they are going to be closed. Say ‘No, but…’ and leave the door slightly ajar.