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.

Essential Guide to Mobile App Testing

Comments

  1. says

    For a lot of people snoring may well not rank up there with a few oof the other ‘big’
    connection deal breakers, but iif you come about to becfome the snoree who lies awake evening immediately after night, listening to ear shattering noises
    and also you are unable to have a great night’s rest because of the
    snoring, you might disagree. And if your snoring companion refuses to know what a unfavorable effect his or her
    snoring is having on you and they refuse to
    accomplish anything about it, you would almost certainly commence contemplating some alternatives
    arrangements. This could incorporate separate sleeping arrangements, but again this may also
    negatively impacts the intimacy within a connection,
    or modifications towards the partnership itself.

  2. Dave@Avelo says

    Developer says “you’re always breaking my code” to which I always reply “The code was already broken when you passed it to me to test – I’m just identifying where it’s broken”

  3. Jon says

    How about, our testing environment and data set is not big enough to support that so we’ll just let out clients be the testers. What, What? Be quality advocates not assurance. JC

  4. says

    Wow! In the end I got a webpage from where I be capable of actually take helpful
    facts concerning my study and knowledge.

  5. says

    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!

  6. says

    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.

  7. says

    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.

  8. Steve says

    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.

  9. Sherry says

    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.

  10. K says

    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.”

  11. dawn h. says

    if you are lucky enough to work with developers with a sense of humor…’it is working as coded’ lol.

  12. jules b. says

    “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.

  13. says

    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 :P

  14. says

    Shey said:

    You forgot the old favourite, guaranteed to get the blood boiling:

    “What do you mean it broke? It works on my machine!”

  15. SB says

    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.”

  16. KN says

    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?

  17. SG says

    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!”

  18. Sam Oma says

    My personal favourite is ‘Have you tested all the possible combinations of the scenario?’

  19. Mukesh says

    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.

  20. pcam says

    “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!”

  21. Carlos says

    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.

  22. says

    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.

  23. Shauna Ayers says

    – “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?”

  24. Allen says

    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”

  25. Jeff Higgott says

    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.

  26. robpipita says

    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)

Trackbacks

Leave a Reply

Your email address will not be published. Required fields are marked *