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

2 Likes

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

This here is what i discovered:
Misconception: 100% of all bugs should be identified - and fixed
Counterargument: Test teams should focus on testing to meet the requirements of the product and should not be tested to make it 100% bug-free.

Misconception identified: testing can be fully automated.

Whilst there are advantages to automating some test, such as freeing up the time of testers and performing multiple repetitive tests which can reduce or eliminate mistakes. The issue that automation may struggle to get around is the amount of variables in a live environment that may not be automatable. Unforeseen obstacles or conditions for a self drive car to perform as intended will need some analysis and human input is one example.

I found 3 commons misconception:

               1-The software testing is always done at the end of the project.
               2-The Tester is not being in good consideration in the world of the development software.
               3-The Tester always delay the delivery of the project.

Counterargumentes:
1- .It is very important to start the testing process from the beginning so many problems could be
fixed
2-It is part of the team for the job of create a software, it´s not less or more than others.
3-The Tester may do the final testing in details at the end of the project before the delivery day.

1 Like

I tried not to write duplicates here so

Misconception:

  • Isn’t testing just clicking buttons?
  • Testers are the only one responsible for Quality
  • Testing costs a lot of money
  • Manual testing can be replaced with automated tests

Misconception: “Testers doubt everything and they are the ‘skeptics’ in the IT industry.”

Not having belief in a product would create doubt in the product and would be too negative to allow them to spend time and effort working on the system.
Testers need to believe in the product as they want to improve it and make it the best it can be.

Common misconception: Testers like finding bugs

Counterarguments:

  • Finding complicated and high risk bugs can be very satisfying but generally finding bugs is discouraging because you want the software to succeed and dealing with bugs slows things down.
  • While I do actually enjoy investigating and raising bugs it’s time consuming and the concern over that outweighs my satisfaction from carrying out the task.
  • If there are enough bugs in a piece of work it can prevent it from being released for an inordinate amount of time when you take into consideration release schedules, work load/priorities, devs working on it again, remembering what the software even does, remembering what the problems were, doing the retesting and then fitting it into a release schedule.