Last week, I had a question arrive from a reader of one of my books, Pragmatic Software Testing. The reader, Akhila, wrote:
Dear Rex,
I picked up your book with a hope to learn more about testing, as I’m new to testing. I’m through with a nice course in testing, but I’m yet to land a testing job. All said, I’m glad that your book is serving my appetite for learning more. I’m thoroughly enjoying reading your book. Little concern though is that, I’m still not finding prototype K.1, K.2 etc which you mention in the appendices. By the way, I’m going through the Indian edition of the book.
Hope to get a response.
Thank you for a wonderful bundle of knowledge.
Regards,
Akhila Hegde
Akhila, you are referring to the screen prototypes mentioned in the Omninet Marketing Requirements Document, but not provided in the requirements or anywhere else. This is actually a bug in the requirements, one that sharp-eyed readers (such as you) typically find when they do the review exercise in the book.
Like most of the other bugs in that document, this is not an unusual problem in requirements specifications. Referencing information that cannot be found, or, when found, turns out to be marked “to be determined” or just an empty template, is a problem that many testers (and others) encounter with technical documents of various kinds, requirements included.
In this case, if you don’t find the bug in a requirements review, you’ll certainly run into it when you go to create tests. This is one reason why early test design is so useful. The attempt to create tests often reveals problems in a requirements specification, sometimes even in specifications that were carefully reviewed.
Tags: pragmatic software testing
Rex Black is President of RBCS (
