From: Don Mills (DonM@softed.com)
Date: Thu Apr 17 2003 - 18:16:10 EST
At 16:17 10/04/03 -0500, Brian Marrick wrote (in an email that got lost in
my in-tray):
-----<big snip>-----
>(I think of requirements documents as commentaries on the tests,
>explaining what might otherwise be puzzling.)
-----<end>-----
Funnily enough, as a tester also, I see it the other way round -- because (as I have previously documented on this list) I have experienced highly successful projects, and know of others, in which test cases were developed as commentaries on the requirements, which might otherwise be puzzling to the non-technical person. By the latter, I mean the software designers and programmers who are ignorant of the technicalities of the problem domain and of the nuances not necessarily expressed in even a good requirements specification. (I learnt that lesson years ago, when I prepared a pair of testing course, one for the "technical staff" who developed software, and one for the non-technical staff who ran the business. "All our staff are technical staff," I was told in very certain terms, "but the software staff don't understand half the technicalities of our business.")
This was Beizer's "threat of testing" principle put into practise: a prior awareness of what was to be tested, and how, sharpened up the developers' perceptions no end -- but only after the test cases "illustrating" the specifications had first demonstrated how poor the specs really were. But you've heard that story from me before, so I'll leave it at that.
Best wishes to all (and nice to know you're aboard, Brian),
Regards,
No content checking was done on this email
This archive was generated by hypermail 2.1.6 : Mon Apr 21 2003 - 09:00:10 EST