What would you add to this list of 10 misconceptions about testing and quality?

🙋 Questions
, , , ,
1

We asked the community on Twitter and LinkedIn the following question.

What misconceptions are junior testers taught early on around testing and quality?

Here are ten that stood out (in no particular order):

  1. The testing “column” is the sole responsibility of the testers
  2. That they are supposed to find all of the bugs in a product/application/software/system within the time frame allocated to testing.
  3. That their job is to assure quality
  4. That BDD is automation testing
  5. That testing is about two things. Breaking the system and stopping releases going into production. Both happen and can be part of a role but these are not concrete foundations for our craft.
  6. That QA are quality gate keepers
  7. Confusing testing with just checking a few things
  8. That testing is about breaking stuff
  9. That it is easy-peasy
  10. That every bug/issue that you bring up will be taken seriously.

(Source: Twitter, LinkedIn)

How about you? What are your thoughts on this list? What could you add? What are the most common you’ve personally experienced in your career?

And what might we do and continue to do with our craft to alleviate such misconceptions?

4 Likes
2
  • That the machine executing the automation is doing the whole testing / doing testing at all.
  • That you need a test column at all
4 Likes
3

That’s a great list. Some of these don’t seem to let up. When I first started engaging with the wider test community I saw many of these misconceptions already being tackled and yet I still encounter them all the time.

For example, in 2010 I collected some articles and forum posts against the notion of QA as gatekeeper from Mark Berryman, Robert Tehve, Fiona Charles, and Zeger van Hese. In 2023 I can join a random development team and be pretty confident they’re still using QA as gatekeepers. I suppose there weren’t enough of us to spread the word and be persuasive and demonstrate how it can work in practice.

Sometimes I wonder if “what might we do and continue to do with our craft to alleviate such misconceptions” is to create communities around quality & testing that are not aimed at test professionals, but primarily at developers, engineering managers, agile coaches, and so on, with quality coaches injected into the forums and other platforms just as they could be in teams.

As to what I could add to the list, the worst (but mercifully brief) misconception I experienced from my early days as a tester was being made to believe that it’s my job to create test plans and test cases.

1 Like
4

One topics that come up from time to time for me is that testers feel that it is their responsibility to try to push developers and product owners to fix bugs.

What I tell them is that it is their job to ensure that stakeholders have all the information they need to make informed decisions - if they decide to fix or not fix a bug is a business decision, and not something a tester should feel is on their shoulders.

You can definitely be a “quality advocate” - but this is not directly tied to the tester role necessarily. Anyone in the team could take that responsibility. And if you do take that responsibility, make sure it is aligned with the rest of the team and stakeholders, so that you are not on a one-person-unsanctioned-crusade.

2 Likes