From: Don Mills (donm@softed.com)
Date: Fri Apr 11 2003 - 12:27:48 EST
At 10:16 31/03/03 +0100, Ian Alexander wrote:
-----<snip>-----
>However there is also a different place for simple narrative
>stories, not atomised or structured in any way beyond the
>essential logic of the tale. Stories raise issues, identify
>weaknesses and exceptions, give hints for test cases, and
>many other engineering purposes. However I certainly agree
>with you that simple stories are not in themselves good
>places to hold formal requirements directly
-----<snip to end>-----
Good, Ian, I think we're in essential agreement with one another -- although, methodologically (because I'm a tester and not an RE) our approaches differ. I work from "formal" (huh!) Requirements Specifications to create test cases that are "stories" illustrating the use of the requirements in context with one another. I then work through these scenarios with the customer, identifying what's right and what's wrong. The results get fed back to the Requirements Author for correcting the Specification, and also feed back (via the corrected Specification) into the test cases.
Having (re-)invented this technique myself (about 12 years ago), I used to call it "Advanced Test Planning" ("Advanced" meaning "early in the life cycle, before product design"). I now know I should have called it "eXreme QA".
At all events, the result is that product design begins with (a) a set of formal requirements, and (b) a set of illustrative scenarios that has already verified the requirements and will later verify (or is it validate ...) the product.
Now, the next thing I'd like to try is Beizer's "Threat of Testing" technique: early release of the tests "threatens" the developers to the extent that they put in fewer bugs, and work harder at finding the ones they do put in. Then, come test execution time, you run "1 in 50" (Beizer), or "1 in 30" (a statistician I consulted!) of the test cases, selected partially by priority and partially at random. If the results are excellent, you don't test any further. If the results are mediocre, you whack it with the full test suite (or give up?). Between those two points, you analyse and decide what to do.
I've engaged in two (now) projects where the results of the "eXtreme Testing" approach amply demonstrated its effectiveness in both speeding development and (almost) eliminating bugs, and have read of several others (all at the Egreetings.com site, in Cantor and Derr's article previously cited). But though both "my" projects would have saved time and money by using Beizer's "threat" technique (analogous to sampling in mass manufacture), the project that has the courage to try it eludes me so far.
Regards,
No content checking was done on this email
This archive was generated by hypermail 2.1.6 : Mon Apr 14 2003 - 09:00:09 EST