Automate your Verification |
 |
 |
 |
| Written by Graham Stoney | |
|
Successful software products have multiple releases, because customers always want new features. Even poor bug-ridden products require multiple releases, because customers want bug fixes. The only products which have a single release are complete failures. Unless you're planning for complete failure, you should automate your verification because you will be doing it numerous times. Automated verification will be a whole lot easier to implement if you design your software for testability in the first place. Generally speaking, well structured software will be easier to build an automated test harness around, because hopefully you've got well-designed interfaces to attach to. But a little foresight can go a long way. Some techniques like polling and asychronous user interfaces can cause test automation to fail if events arrive too quickly; in a well-designed system, events get queued and handled so that they don't get lost. The classic example in GUI land is an automated test program attempting to click on a dialogue box which hasn't been presented yet. If the application has been well-designed, it will wait until the dialogue box has been shown before looking at the next event from the user so the test program doesn't have to throttle the events it generates or insert arbitrary pauses in the test execution cycle. Following my advice on regression testing will go a long way towards automating your verification because your regression test suite will build up to a complete automated system software verification suite. Documenting the verification results then becomes relatively easy: just capture the results of the regression test run, and explain why any tests that fail aren't critical to this software release and mention them in your release notes. Social Bookmark this page:         
|