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:
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.
Identify and develop counterarguments to the misconception so that you can debunk it when you need to.
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)
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.
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.
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.
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.
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.
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.
I found an article on dzone.com relating to misconceptions about testers.
One misconception which I found interesting is that testing is simply documenting information about a product.
The counter argument here is that documentation should be involved in every software role, however testers in particular take rigorous and well defined steps when testing to ensure nothing is missed that could affect the delivery of the product.
Testing in and of itself is a tech skill. Being able to read code, debug it, test it, and then create a test report from those activities all relate to tech-intensive knowledge. In fact most of the time what is being tested is software, i.e. technology. Being able to understand and manipulate technology is essential if youāre going to report under which circumstances it breaks.
Software testing slows us down.
It may slow the release of the product/ software or even cause more work. But this is a benefit because the longer it is worked on and corrected as many bugs as possible will save time, money and effort when it is released.
Testers break software - However testers didnāt write the code so they didnāt break it, software can only be broken by those who created it, while testers only tell the information on what needs to be fixed to the developers.
Testing is writing cases and then performing them - Test cases are much less important to testing than creativity, communication, and curiosity.
It Doesnāt work in production so testers failed - However nothing can be tested completely.
A misconception in software testing is that testers donāt have technical skills. Whereas, a counterargument of this misconception is that testers and developers have complementary skill sets with some overlap.
A misconception I myself had not long ago is that testing is done at the end once the product is finished, and while that does still happen here and there today it is not as commonplace. You can test anything, you can start testing before a line of code has even been written and you donāt stop testing once the product has been put live already.