Topic: The Drawbacks of This Testing Approach

Message

   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.

Edited by Anita_buie - 03May2007 at 3:41am

Author	Message
Anita_buie Newbie Joined: 03May2007 Online Status: Offline Posts: 1	Topic: The Drawbacks of This Testing Approach 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. Edited by Anita_buie - 03May2007 at 3:41am Post Resume: Click here to Upload your Resume & Apply for Jobs

	IP Logged


One Stop Testing Forum : Software Testing @ OneStopTesting : Test Plans @ OneStopTesting