QA InfoTech | Your Software Testing Partner
Home Home Blog Blog Sitemap Sitemap Contact Us Contact Us
 
Home » Knowledge Center » Testing Myths & Facts
Software Testing Myths & Facts
"Myths arise from a lack of direct experience. In the absence of information, we form beliefs based on what we think we know, often with a skeptical feeling towards what we don't know. In the realm of software development, myths can make it difficult to approach real-world problems objectively, thus putting budgets and schedules at increased risk"

Laura Rose
, Quality Engineering Manager, IBM
Testing Myths & Facts
Myth: Initiating testing activities earlier in the development cycle increases delivery time while reducing the number of features in the product.
Reality: Testing is not the time-consuming activity in a development lifecycle. Diagnosing and fixing defects are the time-consuming, bottleneck activities.

Myth: You can't test if you don't have a product to test.
Reality: Iterative testing isn't limited to testing code.

Myth: Continually regression-testing everything every time we change code is tedious and time consuming…but, in an ideal world, it should be done.
Reality: Regression testing doesn't mean "testing everything, every time."
Iterative regression testing means testing what makes sense in each phase and iteration. It also means modifying our coverage based on the impact of the change, the history of the product, and the previous test results.

Myth: It's not a bug -- the feature is working as designed.
Reality:The over-explanation of why the product is doing what it's doing is a common trap. Sometimes we just know too much. When defects are triaged and reviewed, we often explain away the reasons for the defect. Sometimes we tag defects as "works as designed" or "no plans to fix" because the application is actually working as it was designed, and it would be too costly or risky to make the design change. Similarly, we explain many usability concerns as "it's an external component" or "it's a bell and whistle." Our widgets or UI controls may have known limitations. Or we may even tell ourselves that "once the user learns to do it this way, they'll be fine."

Myth: A tester's only task is to find bugs.
Reality: This view of the tester's role is very limited and adds no value for the customer. Testers are experts with the system, application, or product under test. Unlike the developers, who are responsible for a specific function or component, the tester understands how the system works as a whole to accomplish customer goals. Testers understand the value added by the product, the impact of the environment on the product's efficiency, and the best ways to get the most out of the product.

Myth: We don't have enough resources or time to fully test the product.
Reality: You don't need to fully test the product -- you need to test the product sufficiently to reduce the risk that a customer will be negatively affected.

Myth: Testing should take place in a controlled environment.
Reality: The more the test environment resembles the final production environment, the more reliable the testing. If the customer's environment is very controlled, then you can do all your testing in a controlled environment. But if the final production environment is not controlled, then conducting 100 percent of your testing in a controlled environment will cause you to miss some important test cases.

 
 
Case Studies
White Papers
Webinars
Tools Expertise
Testing Myths & Facts
 
 
 
 
 
Request Form
 
Your Full Name*
Your E-mail ID*
Your Telephone
Message
 
 
 
 
© 2003-2008 QA InfoTech
  Privacy Policy :: Disclaimer