Validator Demo Script
April 5, 2000
This is a brief description of how I have done Validator demos in the recent past. I’m not attempting to create a fancy graphics demo script in this document, but a brief narrative of how I have demoed Validator.
The first principle of a Validator demo is that the demo itself does not end with a “bang.” That is, there is not a fancy graphic conclusion to the demo itself. The final screen of an ordinary Validator demo is a text screen with test cases. It is possible to do a fancier demo with a GUI test execution tool such as Validator, but most AEs do not have these back end tools on their machines, with current licenses, etc.
So I do Validator demos beginning with a chalk talk. This lets me set expectations and make very sure that they know what they’re seeing at the end and why it is impressive. The chalk talk will take at least half the demo time, probably more.
In the chalk talk, I’m careful to start with questions. What is the nature of their testing problem? Are they GUI oriented? What language are they using? This question phase is essential so that I can tailor the presentation. I’ll usually make whiteboard notes based on their input.
Then I’ll begin a drawing, left to right, starting with requirements, going to Use Case diagrams and down to sequence diagrams. At some point I’ll draw a repository symbol and mention how our architecture works and how these diagrams relate to each other and the repository. I’ll mention ACD here too when discussing the repository. Finally, I describe how we are conformant to the IEEE documentation specs. (This means that Validator users can state that they are using “Engineering best practice” as embodied in our IEEE output documents – IEEE 830, IEEE 831.)
The next part of the chalk talk diagram is discussion of their test harness. Depending on what they told me about their testing situation, I may draw some test harness and may describe how they can generate portions of the test harness automatically. (In C++ for example, there is a test harness generator tool called Cantata++ http://www.iplbath.com/p13.htm
The demo then consists of going through sufficient Validator screens to show the principles we have discussed. I spend some time with the T Table and how it describes data. This includes data types such as “Abnormal range.” I’ll show them our SRS document and some of the summary T documents too.
I typically conclude with our Word document showing all the test cases we generated. When I bring it up on the projector screen I have it at 10% scale! What this does is shows that it is one good sized report and they can see it “in the large.” Then, of course, I go into some detail on the reference case and a few of the cases farther down.
When the demo concludes, I’m concerned with leaving on a high note. So what I’ll do is double check that they comprehend what they’ve seen and how it maps to their process. If we win agreement on that we have had a good demo!
Mark Bell
Sr. StP Applications Engineer