What’s a testing belief you once held but have now let go?

The software testing world has undoubtedly changed in the past 5, 10 and 20 years.

For those that have been around long enough, what’s a testing belief you once held but have now let go of?

Response so from a Tweet I put out:

  • That everything has to be planned and nailed down up front (Dan Billing)
  • That you had to be ISEB certified before you could be a good tester - (LarryG)
  • That testing is about finding bugs (Hylke De Jong)
  • That I can find all the bugs. (Dana Bentley)
  • That testers and developers don’t work together (Iain Bright)
  • That 100% bug free is the goal. (Jenna Charlton)
  • Always aiming for the best :slight_smile: (Helena Barmer)
  • Automation coverage 100% :slight_smile: (Anand Ganesh Sivaraj)
  • That you had to automate EVERYTHING (Kaveeta Bhatia)
  • That assigned acceptants take acceptance testing seriously. (Herman Nijland)
  • That we needed a perfect understanding of how the system was supposed to work before we could do any useful testing. (To be honest that illusion didn’t survive contact with reality for very long.) (James Christie)

That every bug I found had to be logged, you know, to show that I found it, just incase…!

And that it was up to me to determine what bugs were fixed!


That “Closed - Waived” was a personal slight on me as a professional tester, and not just a business/time/budget call.


I’ve let go of an early belief that you had to answer the question, ‘does it work’ with a binary answer


I tweeted to say;

“Quality is only the testings responsibility.” Nope.

I’m very glad we have moved away form the culture that if anything isn’t a high quality is is the testers fault. Instead we ensure the entire team, developer, tester, product owner ensure the ‘quality is built in’. It’s always a work in progress but it has to be a team activity. From the conception of the idea, to the deployment, everyone is responsible.


Every possible permutation needs to be tested. A more experienced tester explained the principals of risk based testing and the impossibility of exhaustive ( in both number of tests and physical exertion) testing. Made me chill out.

Also my biggest fear was if something went live and a bug was found I would be blamed and sacked.


Previous belief: Testers* can assure that something is good.

Current belief: The users are the only ones that can say** something is good.

* Nor any single individual, as a matter of fact.
** So we need testing in production

1 Like

“Well, it depends…” :joy:


In the beginning, I thought I could test everything.

Then I started looking at user flow diagrams, multiplying out all of the possibilities and I realised…yeah good luck with that thought!


That I HAVE TO find all the bugs


That automation would take my job.

Now I know automation has only made my job more interesting!


I believe my role is to find bugs. No one wants to hear my thoughts on stuff that isn’t related to a bug. You know, such things like feature and product ideas, concerns, compliments, the quality of my testing and how we might make it easier for all of us to test.

There are quite a few from me. Here goes…

  • All known defects in the software have to be fixed prior to “signing off” for release
  • Every single test script must be passing in order for a release to happen
  • Anyone can be good at testing
  • A test script must be written so that your grandmother could run it
  • The only way to test is by writing a script and running it

There were a few points spoken about in last night’s Belfast Software Testing Clinic that I think go well with this topic:

Last night’s session was on Exploratory Testing (ET). Folks were asking when should we do ET and what should we do next. That prompted me to remember a belief that I let go of: in testing there are absolute right answers. Sometimes ET may be one step in the bigger process, sometimes it alone may be sufficient testing … it’s all about making the assessment based on the situation.

There is no correlation between the volume of testing artifacts produced during ET, or any other testing, and the value of the testing, the example spoken about last night, and I used to think this way when working for a large corporation, was that artifacts are important as they prove we have performed testing.

Further to the above point, it was suggested that there could arguably be inverse correlation between the creation of voluminous quantities of test artifacts and the value of the testing. This could come about as the time spent generating artifacts has reduced the time available to perform actual testing.

Based on the above I recalled another belief that I have let go of: production of test cases == testing. As was mentioned last night and the above point, inverse correlation can apply to this. The example given was that a test manager may prefer to assess the value of testing by looking at, e.g. mind maps that were produced during brainstorming/ET rather than wading through low level test cases.

A few of my own as well:

  • Testing is a fixed skillset, i.e. once you have tools in your tester toolbox, you’re done. I’ve come to appreciate that a continuous learning ethic applies to testing perhaps as much as it does to software development
  • Automation is the holy grail. I’ve come to appreciate that it definitely adds a lot of value, but it doesn’t do this automagically when we just approach it at an operational level, i.e. good strategy and tactics really help
  • There is not a lot of difference between a good and a great tester
  • By doing ‘x’ you’re doing agile. I now think agile is much more something you judge based on how you feel
  • Testing is easy

I must be the one to test everything.

That one has been so damaging to me, and my life as a tester has been so much better now that I’ve let it go. There’s a team of other people, developers, QA members, PMs - they all do some amount of testing, and I need to focus on the areas of highest / critical risk, because testing everything is impossible.

Tl;Dr - Trust your coworkers, and recognize that you cannot test it all.


@alex Being the only tester in the company cured me of that one.


That testability is only a characteristic of the SUT.


What I believed - that I need to learn automation to be a ‘proper’ tester.

What I now believe - automation of any kind is just a tool in the testers kit. I’ve met far more talented testers than me that barely know anything about automation.


I was made to write these permutations by my lead after I joined a new company with about 6 years of testing experience . I tried to explain him how unuseful and expensive that would be. Maybe I couldn’t explain well, he handed over the ISTQB book to me to refer. :roll_eyes:

Hope more testers get over this belief!

1 Like