Lesson 5 - Activity 3 - Do you know about any misconceptions about testing

Time: 30 minutes to research and share

Introduction:
Within the software development industry, there are some who misunderstand what software testing is and its role in software development. As a tester, you may have to provide clarity and debunk those misconceptions to help teams get better value from testing.

We debunked some of the more common misconceptions in our lesson and we would like you to find other misconceptions of testing and think about ways you would counterargue them.

Purpose:
Learning about common misconceptions gives you a better appreciation of what testing is and isn’t. This knowledge will help you recognise when others hold these misconceptions and allow you to debunk them to potentially help improve testing practises and the value testing can provide.

Activity:

  1. Find a software testing misconception. You could try:
  • Searching the Ministry of Testing site (we have some articles and videos that explore misconceptions of testing).
  • Searching The Club for old forum posts on the subject
  • Searching the web for blogs, articles and videos
  • Connecting with testers via The Club or Slack to ask them what misconceptions they have come across.
  1. Identify and develop counterarguments to the misconception so that you can debunk it when you need to.

  2. Add this information to your portfolio notes and share them on this thread to compare with others.

(If you can’t find any new misconceptions, feel free to pick one of the misconceptions we covered in the lesson and develop your own counterarguments)

Here is what I found:

Misconception: Everything has to be automated.

Counterarguments:
• Not everything is worth automating because not everything carries the same risk and cost.
• Automating does not necessarily mean adding value to the testing of a product.
• Large automation sets are very difficult to maintain.
• Deep analysis should be done to classify what needs to be automated and what not.

1 Like

Misconception:
Testers are breaking the product

Counterargument
“I didn’t break the software. It was already broken when I got it.” – Michael Bolton

1 Like

I found similar misconceptions to those previously shared in the training, and also posted above. The one that was the most interesting was “Testing exists to find all the bugs” or “It Doesn’t Work In Production So Testers Failed”. These are both misconceptions as it is impossible to test everything. The potential input combinations and scenarios are too complex.

1 Like

Quality assurance is not as being a developer, career-wise.

Among the development community and within my own social circles, there is a line of thinking that the career path of a developer is, in most or in all ways, better than the career of a tester (mostly, the debate is around which career path is better paid, which career is more secure, which one provides better learning opportunities etc.)
While each career naturally has its own pros and cons, this is not exactly a true statement.

In Agile, both developers are testers play a cruical role. Developers are the foundation, yes, but at a certain point they will require testers in order for their product to keep up with the standards.
As far as salaries go, depending on the knowledge and capabilities of either the developer or the tester, their salary tends to be within the same range.
As far as job security goes, job market is volatile anywhere, but testing departments, once introduced to a company, tend to stay necessary. The weakest link will always be removed, so if an employee does not perform, they will have to leave the organization, no matter whether they are a developer or whether they are a tester.
Learning opportunities is the part where it gets interesting. The developers do have knowledge that can be carried over more easily to a new job, but testers are becoming more and more tech savvy as automation becomes a trend. Further than that, while developers have to focus only on the feature given to them, testers tend to have a broader view of the whole production process and better know-how of every aspect of it.

At the end of the day, developers eventually need to learn how to test, and testers eventually need to learn how to code. Both disciplines are wide enough now that there is a lot to learn in order to keep up with the current technologies.

Testers Don’t Have Tech Skills
I found that from the common misconceptions here in the ministry of testing. As far as I read here and from the exercise, we had before to search for a software development job listing. I think that people don’t understand that the job of the tester is different than a developer and has a different mindset. The job of the tester in my understanding is to test the overall software and actions of it and communicate it to the rest of the software development team where the developer role is to create the code for the software.
So the tech skills are needed to both but in a completely different way and lots of times different skillset the one to the other as they solve different problems.

Misconception: Testing is here to find all the bugs

Counter-arguments: It would take forever to test everything, therefore you cannot find all the bugs.
There is a nice quote in the article: “Program testing can be used to show the presence of bugs, but never to show their absence” – Edsger Dijkstra