The Drawbacks of This Testing Approach
Printed From: One Stop Testing
Category: Software Testing @ OneStopTesting
Forum Name: Test Plans @ OneStopTesting
Forum Discription: Discuss, Learn and Prepare better and better Test Plans for yourself.
URL: http://forum.onestoptesting.com/forum_posts.asp?TID=1214
Printed Date: 05Dec2024 at 10:17am
Topic: The Drawbacks of This Testing Approach
Posted By: Anita_buie
Subject: The Drawbacks of This Testing Approach
Date Posted: 03May2007 at 3:40am
The Drawbacks of This Testing Approach
Many projects are not mature and are not rational (at least from the
point-of-view of the quality assurance team), and so the test team must
scramble to test as effectively as possibly within a very short time
frame. I've spelled out how to test quickly without a structured test
plan, and this method is much better than chaos and somewhat better
than letting the developers tell you what and how to test.
This approach has definite quality implications:
* Incomplete functional coverage -- this is no way
to exercise all of the software's functions comprehensively.
* No risk management -- this is no way to measure
overall risk issues regarding code coverage and quality metrics.
Effective quality assurance measures quality over time and starting
from a known base of evaluation.
* Too little emphasis on user tasks -- because
testers will focus on ideal paths instead of real paths. With no time
to prepare, ideal paths are defined according to best guesses or
developer feedback rather than by careful consideration of how users
will understand the system or how users understand real-world analogues
to the application tasks. With no time to prepare, testers will be
using a very restricted set input data, rather than using real data
(from user activity logs, from logical scenarios, from careful
consideration of the concept domain).
* Difficulty reproducing -- because testers are
making up the tests as they go along, reproducing the specific errors
found can be difficult, but also reproducing the tests performed will
be tough. This will cause problems when trying to measure quality over
successive code cycles.
* Project management may believe that this approach
to testing is good enough -- because you can do some good testing by
following this process, management may assume that full and structured
testing, along with careful test preparation and test results analysis,
isn't necessary. That misapprehension is a very bad sign for the
continued quality of any product or web site.
* Inefficient over the long term -- quality
assurance involves a range of tasks and foci. Effective quality
assurance programs expand their base of documentation on the product
and on the testing process over time, increasing the coverage and
granularity of tests over time. Great testing requires good test setup
and preparation, but success with the kind testplan-less approach
described in this essay may reinforce bad project and test
methodologies. A continued pattern of quick-and-dirty testing like this
is a sign that the product or application is unsustainable in the long
run.
|
|