6 Things You Should Never Say to a Software Tester
Not long ago, we covered the ten things that software testers should never say. But what about the flip side to that? What should members of the non-testing world know about conversing with testers and quality professionals? I think I might have a few ideas.
Whether you’re a co-worker, colleague, friend, foe or relative, here are 6 things you should probably never say to a software tester. You’ve been warned!
1. “Can you hurry up and finish testing soon? We’re under a very tight deadline.”
Good testing cannot be rushed. Ideally, testing should begin with the design phase of a project and continue all the way through. Software testing is ultimately about validating the design requirements, but to be effective at that, the testing process must begin with the design stage itself. When testing is started later, it can be less effective. Designers must sync with testers, developers must sync with testers, and valuable time is wasted getting teams and technology expectations to mesh. This is a recipe for delays, confusion, and budget overruns.
Starting the testing process with design lets testers be involved from the beginning. They can contribute early, get to know the product early, and be involved early. That makes for better testing and that makes for a better product.
2. “Promise me there’s no bugs in this, okay?”
It’s been argued (correctly, in my opinion) that the role of testing is not “quality assurance” but rather “quality assistance.” I believe that phrase originated with Jon Bach, but don’t quote me on that. Basically, quality cannot be tested into a product, thus a tester’s job is not to verify that a product is error-free, but that it has passed (or failed) to meet a certain set of standards, which vary from company to company. Leave the outlandish promises to the marketing and sales departments. Keep testing in the realm of reality.
3. “You must be bored out of your mind.”
This is a huge myth of software testing, but one that’s easy to dispel. Go to a testing conference, read a few blogs and articles and you’ll quickly see how passionate testers can be with their craft. Here’s a nice quote from Michael Bolton that pretty much sums it up:
“Testing is something that we do with the motivation of finding new information. Testing is a process of exploration, discovery, investigation, and learning. When we configure, operate, and observe a product with the intention of evaluating it, or with the intention of recognizing a problem that we hadn’t anticipated, we’re testing. We’re testing when we’re trying to find out about the extents and limitations of the product and its design, and when we’re largely driven by questions that haven’t been answered or even asked before.”
4. “I didn’t have time to read your bug report. Give me the 5-second version.”
Testers (the good ones, anyway) spent a great deal of time crafting their bug reports with precision, accuracy and steps to re-produce. When a developer (or other department) doesn’t care to understand the full severity of a bug, it not only wastes the tester’s time, but it can lead to huge problems down the road. The reasons for this should be rather obvious. Instead of the five second version, how about the five word version? Read the freaking bug report.
5. “You’re actually a very nice person. I don’t care what the developers say.”
I had to throw a little humor into the post 
. On a more serious note, the relationship between testers and developers is not always – how shall I say this – pleasant. As testing guru James Bach once wrote: “Anyone who creates a piece of work and submits it for judgment is going to feel judged. That’s not a pleasant feeling. And the problem is compounded by testers who glibly declare that this or that little nit or nat is a “defect,” as if anything they personally don’t like is a quality problem for everybody.” In other words, don’t stir the pot.
6. “Couldn’t a machine do this much easier?”
Depends on what they’re doing, but even if the answer to that question were “yes” who would manage the automation? Who would analyze the results? Who would choose the tool to use and decide where and when it’s going to be implemented? This doesn’t even touch on the need for manual testing. Machines can do a lot of things, but replacing testers is not – and never will be – one of them.
What other things should you never say to a tester? Let us know in the comment section.
In regards to point 2, it was Cem Kaner who said QA is quality assistance not quality assurance.
No1. is my favorite, usually I’m done within a second, and the obvious GUI Bugs are left, just to show that in many cases if Developer need a day to code, tester can do the job in 4hours or in 24 hours, depending on complexity.
What I hated to hear is “can we quickly run one more Regression test set” …
‘You have too much questions. Just go and test.’
Good one Veronika!
You know…all those projects came from overseas…ex: (TCG), can you forget about the severity and just leave it as FYI…
You forgot the old favourite, guaranteed to get the blood boiling:
“What do you mean it broke? It works on my machine!”
Quite true especially the points 1 & 2
Related to point 1, when you do “hurry up” (and sometimes you do get in situations where speed is key) you’ll likely miss something which, inevitably, will be found later and you’ll hear “why didn’t you find this!?”
Piers,
I’m so mad at myself for not thinking of that one. Good work!
In part 4 I ran into trouble reading this sentence
“The reasons for the should be rather obvious”.
I found a nit!
@Shey and Piers,
Outstanding points! In my 3 years of QA, I can’t tell you how many times I’ve heard this.
@Kevin
I never promised a bug-free post. Plus, I had to test this in a hurry
Trust me, it works.
Piers
I hear this all the time and sometimes make me feel a terrible teste
My favorite which I am hearing all the time is: “I tested it myself so, it should be fine.” The other one is “Testing is not a real job.”
“Hey, you’re the QA Engineering. It’s your job to make sure the software is high Quality.”
Good one ….
One thing I would say (as Michael Bolton would say).
A good software tester would Avoid using the qualifier “Never” as far as possible. We, testers are the folks that know things can be different. Never use “Never” (or Avoid using absolutes like Never, Always, Everything, nothing etc)
Shrini
Good one ! This website increases my motivation
Thanks guys !
“Where did this requirement come from?”
Never trust coders when they say “I am sure I fixed it!”
“The users would know better than to do that….”
Usually said when objecting to a negative test, and generally just before the test fails.
“You must have done something wrong”
Interesting and true. Could relate to all the points mentioned herein.
It works as designed!
Love your article.
Haven´t we all heard it before? And it actually helps to see others have to put up with the same crap.
After about 15 years in QA or test I can´t understand that there still is so little understanding for our profession.
Too funny! And what about:
“Oh, it’s COTS, so we won’t need to test it.”
All good, I always dreaded the one from the developers: “I also fixed a couple more things while I had the patient open”. I don’t like to hear that either.
We don’t care what testing thinks. The customer liked it during our demo.
For #1 I find it useful to ask experienced testers for the bottom up estimate it can help creating more realistic test schedule. For #2 – a clear definition of what completed testing task means is giving a tester idea of what’s the progress and eliminates a need for unreasonable promises
So true!
One more to add here is: “Normal users won’t execute current scenario”! This is related to my favorite negative cases I run as soon as I receive something new to test!
And yes – our profession is some type of mystery. Every product has its own answer for it!
Good point Shrini. That’s why I never use absolutes in any of my communications.
or “your test is invalid, it works in dev”
Another form of that Anita:
“Nobody would do that in the real world”
Loved the article…
Oh.. How can you test for this scenario, no user would ever do that
As Micheal Bolton would say, “This is a tale, of Captain Jack Sparrow….”
“It’s not a bug. It sure is a great idea though!” – get’s me upset, especially when you see the “great idea” used in the following cycle!
As a Technical Analyst, I am often asked to test things, despite the presence of a qualified QA department. Having come from a QA background, I am well aware of their capabilities. End users are often surprised when I explain how many tests can be run and how long it can take just to “check something out” for them. All these comments have the same thing in common – they fail to recognize the high standards our QA professionals bring to the table. Thanks folks for all you do!
Heard this one today
“there are no differences between the build you tested and the one we released”
What about a post on the things you should say to a tester.
After all testing is about quality and motivated testers will do a better job.
Regarding the detail, things often work differently in the real world. Such as not asking a tester to finish more quickly, it happens a lot. All though if you have good rapport with your peers often it happens in the reverse and they give you the time you need. This is also true when you provide test estimates, they accept what you say with less questions.
I love it when developers consdescend to me and pontificate about how the code is supposed to work. All they do, without realizing it, is reveal more bugs. As far as something to never say to a tester: never say that “No one is going to do that” because you think a “bug” is “unrealistic”. Yes, the end user just may “do that”. And worse.
Nice article Mike, thanks! I have a couple that I cringe at … even when I want to say them!
1) Why didn’t QA/YOU didn’t find that bug? (I like to rephrase this as “Why didn’t ‘WE’ find that bug?” Then, if I don’t know, I’ll say I’ll find out. If I know, I might share something like “we did report that but development rejected with -a user would never do that-it works on my machine-or-it’s not a bug- response!)
2) It functions as designed. (At that point I often want to file a bug against the design. Better option is to find a product owner, BA, product manager or user that can actually guide both testing and development to determine how it ‘should’ function.)
3) If you can’t reproduce it, don’t file it! (While I understand the challenges of finding and fixing problems without a reproducible scenario, it’s not impossible. Further, if it was a result of testing, it should probably be tracked somehow. My own personal experience with this was a intermittently appearing dialog that stated “Drink the Kool-Aid.” No joke. Because no one would take it seriously because it wasn’t consistently reproducible, we shipped it. Several HUGE companies ditched our software and didn’t renew their service contracts. Big revenue hit … bad day at the office!)
Happy Testing all!
My favorite question that I normally get from an irritated developer when I report a bug: “you are not supposed to go there or to do that, why did you go there?” My response is always, “because I can”.
My favourite one is
Developer :- “I am sure i had fixed it. let me check if I checked in the code”
or “I am sure i had fixed it. Build guys seems to have screwed up (cause i didnt check in the code)”
One that I come pretty close to while interacting with developers and designers is ” We have designed it this way and no one ever complained , so lets not go into whats wrong or right , lets just do our work” , to which my thoughts are , aint getting the product to work right my job , and is incorrect design or product behavior not an obvious deviation from the intended behavior.
I wish developers and designers were more open to accept QA’s recommendation on enhancements and improvements suggested for a product they work on.
I could add some flavor. Few things testers should never say:
- Something is not working, can you take a look?
- Yes, found a bug!
I, personally, become furious, listening for a variant of question3 – “What exactly you, testers, are doing? It is kind of clicking a various buttons, right?”.
Yeah, right! And programming is kind of typing on the keyboard.
Hi Matt, I’m compelled to point out that Felix the Sky Diver is Austrian, not Australian. Had he done the dive, his sponsor would have been Fosters not Red Bull, and he wouldn’t have saluted on exit, he’d've given us all the bird. Forgive me for being a pedant. But I want to believe you know what you’re doing and have your finger on the pulse of popular cultural event. Bob
My favourite is
“Don’t ask! You don’t need to know that!”
All of the above and more, this week’s favourite was asking if I could “gaurantee that the customer will not find any issues and that they will not have a reduced level of service”
This from a project manager, when reminded that the tester assigned to his project will be on holiday for a week after a release.
As a corollary to number 4, and one I heard just the other week:
“Oh yes, I knew that wasn’t finished, just raise a bug report for it!”
As if testers have nothing else to do than to raise defects for “TODO” items that a developer should fix before releasing to test.
Few more
“Hit F5″
“clear your cache”
“that is out of scope”
6. “Couldn’t a machine do this much easier?”
Machines can do a lot of things, but replacing testers is not – and never will be – one of them.
-> yup, totally agreed (y)
Re: “I didn’t have time to read your bug report. Give me the 5-second version.” – Testers need to be aware of the needs of people throughout the management chain. Too many testers are (top their credit) have a good understanding of the detail and can provide masses of words, screed dumps, logs etc. But they also need to be able to provide the top level “so what is the risk?” message and this is all too often missing.
In response to a statement like #1, I would suggest the following:
“to speed things up, the developer should just tell QA where the bugs are, and then that’s all that will need to be tested”
“That’s not a bug, it’s a ‘Feature’! “
– “Don’t worry about that.”
– “Oh yeah, I hadn’t actually deployed that yet.” (after you’ve retested and it’s still failing)
– “Was that a requirement?”
this has been awesome points. most of our testing team members never dared to say this. at least someone like you shared this. i think this should be forwarded more n more.
Similar to “Why didn’t you find it?” which is often said after the product goes to prod, and some user has reported it, is “Why are you reporting this now?”, but is not as bad, since it often means you found it before release date. However, at times, it used to make me feel sad, as it would probably delay the release. I finally told myself that, quality was enhanced by at least 1 bit.
Well, it’s good to see that we’re not alone, and others experienced the same at some point. And then what… we get up and keep pushing to test the best.
Anyone can test. As if there’s no special training or skills needed to properly test.
“That’s a training issue.”
mping and throwing things and knashing of teeth! I HATE it when a developer says that to me!
On a ligher note, my favorite description of what I do is “My full time job is to break stuff, and I happen to be very good at it!”
I hate a dev lead asking his team member to urgently look into a defect found by BA, when there are already a couple of high severity defects logged by the testing team.
Dear developers, you should be looking into the defects based on their severity, and not on the basis of who logged it! Pls grow up.
Mukesh, that’s a good one. It’s frustrating.
“How much time should I schedule to fix the bugs you find?”
My personal favourite is ‘Have you tested all the possible combinations of the scenario?’
Interesting thing in some places is “Developers also keep posting the bugs in the bug tracker saying that they found defects during unit testing and assigning those defects to the testers to test!”
Criticism is important for a good development and tester is a true critic of a code..
We are aiming for our build to be 99% bug free. But we are only able to give you 3 weeks to do regression testing( on a large application) after we finish fixing the bugs the test group has found in the previous 3 weeks (in UAT). And we hope nothing else is broke, so can you hurry the parallel testing so we can have a good production build?
In response to #1, have heard it many times. My response was “You can have it fast, or you can have it ‘right’ — but you can’t have both in the amount of time you’ve given for testing.”
“You must have done something wrong”
Shey said:
You forgot the old favourite, guaranteed to get the blood boiling:
“What do you mean it broke? It works on my machine!”
Might I recommend Client Copia. Think there is room for testing commiseration there as well
http://www.clientcopia.com
1. You are testing with invalid data.
2. It was working fine yesterday.
3. STR are NOT accurate to reproduce.
4. It cant be done. Because …
5. Tester, come to my machine for a while
6. Tester, verify on my machine.
7. Yes, we know this bug already
8. wait… wait… wait… report is fetching data.
9. It is cache issue, Hard Refresh
10. Uff… you are soo mean
Operator error.
The problem is between the chair and the keyboard.
“Why didn’t QA/YOU didn’t find that bug?” – that’s my favourite one, actually. Usually it’s leads to useless fingerpointing and all exscuses or answers (“Why did Dev create that bug, honey?” or “No time, too much to do”, “I wasn’t asked”) are pretty valid, we all know it.
However, a bit of self reflection won’t hurt, just in case. Sometimes the best qa guy misses things and can improve. We all should know it.
if you are lucky enough to work with developers with a sense of humor…’it is working as coded’ lol.
Three favorites…
1. “You weren’t supposed to test that.”
2. “I didn’t touch that part of the code.”
3. It can’t be wrong. It has been in production for 5 years.”
“Oh, this doesn’t need to be tested.”
My personal pet peeve is #4. It’s shocking how many times a Developer will say that he/she can’t recreate the defect or a BA will call looking for more information in a hurry because the defect needs triaging, and the answer is right there in the bug report. E.g. NOTE: The problem only occurs if x option is set to y. It took me 3 hours to figure that out and document it clearly for you. Please, please, please read. I can’t do my job without reading the supporting documentation. I’m pretty sure the other folk in the shop are supposed to be reading as part of their jobs as well. Sigh.
My favorite is, “I only made one little change, so it doesn’t need to be tested.”
How about…
…”Well no customer hast reported it, so we won’t change it until we hear if from the field.”
Just heard #4 the other day. So sad. In retrospect, I’ve learned to put the 5-second version at the top, then go into detail.
Actually all of these things can be said to QA and are said on a regular basis. Not only are they said…they are tolerated.
QA is undervalued, always has been and always will be. QA is at the end of the line. Development is valued and given as much time as they need. Then QA is asked to bring in the schedule. The cycle begins again. Then QA outsourced (see http://www.utest.com as one example) to 3rd world countries (where wives are trained in six weeks to pass an interview) and QA credibility is further diminished.
When I first started on utest as a quality assurance analyst, I submitted some ‘opportunities’ to the powers at utest. Guess what…..I received the same six responses. Shocking.
I’m amazed, I must say. Rarely do I encounter a blog that’s both
educative and interesting, and let me tell you, you’ve hit the nail on the head. The issue is an issue that not enough men and women are speaking intelligently about. Now i’m very happy I
found this in my search for something relating to this.
Hello would you mind letting me know which hosting company you’re using? I’ve loaded your
blog in 3 different internet browsers and I must say this blog loads a lot quicker then
most. Can you recommend a good internet hosting
provider at a honest price? Thanks a lot, I appreciate it!