Friday, July 14, 2006

3-in-1: Spec, Test script, and User Manual

3-in-1: Spec, Test script, and User Manual

I know there is the other side of the same coin: you may say that the “test” in “TDD” is not just “testing” per se; or, the user perspective in the spec is not just “user manual writing” per se -- they are deeper, etc.

However, before we get deeper into it; let’s test the water, and try the “shallow” things first and see how powerful it can already be.

---- “Test script” introduces a very good thing: it forces us to use consistent data in a scope that as large as possible. Fit makes it more explicit (see my previous posts; vikas has some good posting; however, even you do not use Fit per se, you should use the concept of it: use “real” data (OK, as realistic as possible), in tabular format.

---- “User Manual” introduces another very good thing: it presents the UI, and describes things according to the typical usage flow, of the result of button-clicking. All other things (for example, typing, tab ordering etc.) are organized into those UI and button-clicking descriptions.

You may say, we are a big company, and we are doing large projects, and we have different official formats for those different documents. Good. Re-format the same document according to their official formats. You can ask some lucky volunteers to do that, or even better, create a program to do the conversion.

You may say, our QA department and Users department own those documents, so, it is not up to us … OK, in that case, it is simply a gift to them that IT has done most of the work already – they are going to love it.


Blogger survic said...

There is indeed a (potential) problem here. On the one hand, in the button-clicking descriptions, there is strong tendency to put sqls and algorithm pseudo code there, instead of just tabular testing data. On the other hand, for testing scripts and user manuals, it seems that those sqls and pseudo code are inappropriate.

I say, let’s do both: both tabular testing data, and the sqls and pseudo code. If necessary, ask some lucky volunteers, or, if you are lucky to have a technical writer, to re-write sqls and pseudo code into “structured English”, or, simply delete all the paragraphs. I do feel that last option is a bad one though. Believe it or not, in a lot of cases, testers and users need to understand the sqls and algorithms.

7/14/2006 02:26:00 PM  

Post a Comment

Subscribe to Post Comments [Atom]

<< Home