What's the worst testing advice you've ever heard?

Lets put it out there…bad testing advice, I see it everywhere on the ‘internet’. Lets create a collection here.


LinkedIn and Twitter versions for fun too!

1 Like

Not quite advice but I was once told off for talking to a developer (I was asking questions to clarify something) as I was ‘wasting their valuable time!’

I was also told once that I should make my bug reports ‘bulletproof’ so the ‘blame’ couldn’t come back to me.

Suffice to say I totally ignored both of these and continue having conversations to this day for both :slight_smile:


“You’re only here to test things that are written in-house.”

So red faces all round when third-party apps fell over and said Thud after deployment, or when stuff other people who weren’t devs worked on had embarrassing errors facing the public.

1 Like

I was told by a former manager that we can’t see the unit test results from our developers, as it could influence what tests I might do :roll_eyes:


“Don’t put technical information in your bug reports”

Technical information like how to reproduce the problem because it was a rather technical issue (as well as a big security hole). Or that the issue presented a lot like a different issue. :roll_eyes:


“I like your idea, but NO we don’t want introducing theses changes because everyone is so busy already…”

then, I talked about changes with others to have some opinions from others :sweat_smile:

I’ve been naughty to not take that advice. On the other hand, I cannot stop thinking about it will improve the work we are doing. So I encouraged myself to speard the idea and let people who do the work decide if it is possible to incorporate those changes.

1 Like

“Feature worked in previous build, no need to test it again.”


I will generalize as there’s not a single worst advice.
My problem is with the generally huge amount bad and extremely bad advice you get from forums, slacks, googling testing, blogs, training, linkedin and other sites that offer ‘guidance’, conferences, etc.
This wore me down with time and constantly slowed my progress, the progress of testing as a profession, the progress of smart testing. It has decreased the view/status we have as testers, while promoting a large amount of crappy managers to give even more crappier advice on testing.

A suggestion to people working in testing is to start thinking critically about what you say. And be critical with what you read or hear.

“You shouldn’t be concerned with the technical aspects of the system, maybe just focus on the UI and ensure that the UAT is successful”

This was prompted after I requested technical documentation on a specific component that had been changed and the Product Manager suggested the test approach. Luckily I ignored this advice!

1 Like

With urgent fixes getting told:

  • “It’s a really small change, tested locally, shouldn’t need to go through QA, can’t really break anything…”

Go with it and bypass QA, automation and visual regression checks
–> Breaks production.

Worst part is that automation and visual regression checks would have easily uncovered the issues.

Never again!


“I wouldn’t worry about doing that - if no-one has asked for it - means they are not missing it or don’t care…”…regarding strategy documents & risks list for major new feature - Senior/Lead QA last year…


“Don’t test it! Nobody will do it on real life!”


Insecure test manager made me test the system after additional software had been installed (which was ok of course) and then let me test the system before installation. That was the system that got tested daily.

This can’t be tested

Dev: “I think it’s an issue with the testing environment. It should be fine. Let’s test in production instead”
Me: Naïvely goes along with this
Production: Takes down website

Not doing that again!

1 Like

Dev to QA: Don’t worry, I have tested it, will take responsibility, making it live.


2 months later, a bug gets opened by a customer.

Manager: How can you miss it?

QA: :astonished:


I suspect we’ve all experienced these:
“It’s fine - it won’t need testing” (how many seconds until I found a bug!)
“You’re not a dev, the technical side is none of your business and it’s fine” (dev’d for more years than the person objecting to my technical advice before moving to test - yes, it failed when released)
“It’s your data, it will be fine for customers, we’re not fixing it” (oh no it wasn’t)
“They’re a reputable company, their QA will be better than ours” when questioning whether we needed to acceptance test software from a partner company that we were re-selling (bug challenge between me and a colleague - gave pages of bug reports in under an hour despite us never having got our hands on the product before)


“Test everything. We want 100% coverage.”

  1. So much awful ambiguity.

  2. No understanding at all of rational risk/value tradeoffs.

It gave me the opportunity for some conversation around trying to understand what the most important thing the business was actually concerned about.


“No-one will ever do that”

Invariably followed by a customer doing ‘that’, sometimes within minutes of receiving the new code.


“We’ll test it in production and rollback if necessary.”