Fallacy: Humans have five senses – sight, hearing, smell, taste, and touch.
Truth: Humans have close to 20 senses including balance, pain, movement, hunger, thirst, etc.
Fallacy: Sugar makes people hyperactive.
Truth: Studies reveal that even with sugar-free diets, ADHD and poor behaviors are found.
Fallacy: Shaving thickens hair.
Truth: Regrown hair isn’t thicker. It just isn’t tapered.
We list these fallacies to understand how pervasive misinformation is, be it any field of knowledge.
When it comes to software testing, the situation is no different. Myths and fallacies dominate the testing environment, affecting many processes and general public knowledge.
We list 6 common fallacies concerning defect management to remove myths and create positive education on the topic:
Fallacy: The software must be defect-free.
Truth: No software will be bug-free. While testers try to find and fix as many bugs as possible as per project requirements, they do not seek to identify 100% of bugs, as that is an impossible target. This is not to say that testers only fix a handful of bugs. Most IT projects have testers identifying and fixing hundreds and thousands of bugs. Testers should focus on Requirements Traceability Matrix to harness their testing skills to the right target.
Fallacy: Defects have to be fixed immediately.
Truth: While a tester aims to fix a defect as soon as possible, it is not always the case. Defects are marked with priority according to the level of severity. Testers fix the most critical bugs first. There can be conflicts between team members about which defects require immediate attention. For example, product owners will wish to have product features correctly developed, and other software problems will not have much relevance to them. Defect fixing is shaped by these decisions.
Fallacy: Defects are not good.
Truth: Finding defects helps to fix them and create a high-quality product. Finding defects should not be taken negatively. It is not reflective of poor development skills, but a natural consequence of coding practices. Teams should view defect management as a source of learning and growth, instead of a project burden.
Fallacy: Automated testing finds all defects.
Truth: Manual testing is subject to human errors. Automated testing is not. With automated testing, both speed and quality of testing improve, while saving the time of testers. However, this does not mean that automated testing using defect management software will find all the defects of the software. Test automation machines are best for batch testing and regression testing, conducting testing they have been programmed to do. Manual testing remains useful especially in user interface testing where assessments on visual appearance have to be made. Artificial Intelligence (AI) can detect new issues given their capacity to be smart, but current automation practices are not entirely driven by AI.
Fallacy: Only testers find defects.
Truth: Another common fallacy is that only testers find defects. While it is true that defect management is primarily dealt with by testers, everyone in the team can test – developer, product owner, business analyst or end-user. Developers usually perform testing after writing each piece of code. In agile processes, developers and testers work together.
Fallacy: Higher defect numbers mean the software is of good quality.
Truth: If the defect numbers are high, it means more time will be spent on fixing them. While it is valuable to detect a large number of defects as they will be fixed, and the final product delivered will be improved, simply having a large count of defects isn’t a measure for high quality. Sometimes, the number of defects may be high, and in spite of fixing them, the final product’s quality may still be poor. A large number of defects can simply occur because a project is a large scale one.
Read Dive is a leading technology blog focusing on different domains like Blockchain, AI, Chatbot, Fintech, Health Tech, Software Development and Testing. For guest blogging, please feel free to contact at firstname.lastname@example.org.