Common Myths in Testing
Testing is an essential step in the software development lifecycle. However, it often comes under the scanner for its benefit and use. Here are some of the common myths of testing and the reality around them.
- Myth: Anyone can test
Reality: It’s not the first time you’ve seen this. If anyone could test and no training / skill was required, companies would be hiring anyone for their testing needs. However, the reality is very different. Testing requires technical skills, understanding of the business, and a creative mind to think about all the alternative scenarios to test the software. Testers need to have logic and programming skills in order to understand how to break the system. It also requires attention to detail and analytical skills so that you can analyze the results and get to the root cause of the issue.
- Myth: Testing can be 100% automated
Reality: Test Automation is good and often times a great lever to achieve efficiency in your testing capability. When you automate test scenarios, you automate the repeatable steps. There isn’t a randomness involved in it. All the basic checks and the lower level correctness checks can be and should be automated to the maximum level possible. This also eliminates the need to manually validate things that can be verified automatically. The randomness (or exploratory testing as we call it) cannot be replaced by test automation. Humans excel at judgement. No amount of automation can fully replace the need of having human intervention in testing.
- Myth: Production issues are caused since testers missed them
Reality: When a defect is missed most often the testing team is held responsible for missing it. While I admit testers make mistakes and test strategies can be flawed, there are other factors affecting it as well. A QA team’s job is to test the functionality of the system. What if the requirements are inaccurate or ambiguous? Some other factors that determine the quality of testing are – time, resources, available infrastructure, test data availability, test data completeness and support from other teams.
- Myth: Testers must test after the development is complete
Reality: While this misconception is going away very quickly in firms that have moved to agile development and have adopted shift-left methodology, it’s still an issue with the traditional / waterfall approach. Testing is not a separate end of development process event. The benefits of engaging testing team early in the life cycle are clear – continuity in requirements, quality checks along the way, reduced testing phases (since things get planned in parallel), early detection of defects and improved overall product quality.
- Myth: Testers are responsible for the quality of the product
Reality: Testing is a measure of quality. It’s a tollgate before you go live and your customers see the product. While it’s your final line of defense, it is by no means your only mechanism to ensure a quality product. You cannot stand at the weighing scale and attempt to lose weight. The training must be done along with proper nutrition to see results. Similarly, proper processes must be followed right after the idea originates and requirements are written. The entire team from business, developers, project managers and qa members are responsible for ensuring quality in the product.
- Myth: Testing is very time consuming
Reality: There is a difference between efficient and inefficient testing. Efficient testing includes planning with the available resources for the best possible outcome. You may want to change the world but the reality is that you are limited by the resources at your disposal. If you plan and execute well the testing time must be known in advance and inefficiencies must be eliminated. It’s the number of iterations that it takes to get the defects fixed which make the testing process seem extended. Teams have to realize, it’s just not the single iteration of test execution which takes long, it’s what follows that consumes time.
- Myth: Testing costs a lot of money and there is little ROI
Reality: Has anyone ever complained of having a “goalie” on a soccer team? He does his best but it is no guarantee no goals will be scored against you. Testing is similar. It’s necessary. You cannot eliminate it. While testing alone does not guarantee a quality product, it certainly aims to prevent releasing utterly defective products.