Systems & Software Talk 

This is a simple manual data-driven test procedure. For you geeky-techie IT history buffs: Data-driven techniques were used long before the advent of tools geared toward test automation. Things to note:

1. [ ] is used to enclose variable data or test cases.
2. ( ) is used to enclose another operation, in this case a call to another test procedure.
3. As an example, this assumes that a real-world procedure document would contain that information necessary to assure the tester is equipped with the correct version of procedure, application-under-test, and other information critical to test preparation and execution.
4. For example purposes embedded calls to suggest other tests are included. Let us look at the Call (GUI_Standards) step. This suggests addional steps bundled separately where one might expect validation of button color, size, position, font, font color, default tab stop and focus, tab order, and hot key indicators, etc.
5. You would need to add your own Expected Result column - OR - indicate that the role_buttons are also the Expected Results. The Expected Result column was intentionally omitted to allow a proper fit of the example on this page.
6. As with all procedures, this should not be executed while under the influence of alcohol or other mind-altering substances.

BIG HUGE GINORMOUS NOTE!

This was cast in MS-Word as it was intended as an example only. One could easily put this into an MS-Excel file with the input data in a column separate from the actual steps. What does this do for you? It sets you up for usage by an automated test tool. If you take it that far, then you would of course add columns as necessary to fit within your automation strategy and framework. Also, if you are thinking about ways to implement and/or improve upon this whilst you are in the jaws of an alligator or you are making a dead-stick landing in your Cessna 172; then you might just be a real tester.