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
regressing 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.
|