Software Testing Lecture Series
To Automate or Not to Automate
All the specifications, design rules, programming and gui standards available will not guarantee that at the end of the development life-cycle a quality product has been delivered into the hands of its intended users.
The quality of the delivered product will depend a great deal on the synergy of the entire development team – including the Business Analysts and the SMEs (subject matter expert users) who together documented user requirements, the Systems Architect who researched and documented systems requirements, the Developers who translated the requirements into code, the designers of the user interfaces, the testers who uncovered defects, and finally the QA analysts who bear the responsibility of auditing the work of the other team members to verify that the appropriate procedures have been correctly implemented. If the entire team is thus committed to producing the best product possible, then a successful conclusion to the development life-cycle is 85% assured!What?! Not 100% assured?!? As the old adage goes: "There are only two certainties in life: death and taxes." Why is it not possible to guarantee that a product release is "100% free of defects"? Because it is impossible to test every valid input or possible program paths! It's just as impossible to test every invalid input. It's also not possible to even imagine, let alone test!, every user's idiosyncratic ways of using the application. Therefore, defects will be missed in the 'signed-off' product release—always.
Defects which will, slowly but surely, be detected by the end-users. That is why there are so many 'new and improved' products on the market today. When Microsoft released Word 2.0, it was enthusiastically accepted by the buying public. However, it didn't take the public long to figure out that sometimes, if you hit the 'enter' key twice in a row then the 'backspace' key, all the text on the monitor 'page' would suddenly disappear, and you'd be looking at a blank screen! That was a very irritating defect, to say the least. Still, if the product had been 'perfect', we wouldn't have Word 2000 today, itself full of defects just waiting for unwary users to discover. The bottom line: there is no perfection under the sun (except, of course, for Aunty).| Bugrade (BUg upGRADE): A software upgrade that fixes bugs more than it adds functionality. Although new features are touted, the upgrade is purchased to eliminate headaches in the prior version. The above definition is from the"Computer Desktop Encyclopedia" published by The Computer Language Company Inc.. From their site, you can download a 'demo' of this electronic encyclopedia. Aunty uses her 'bought and paid for' copy many times every day. It's worth the 35 bucks. |
Because of the inability to test every possible scenario and also because many tests such as load or performance tests cannot be done manually with any degree of accuracy, nowadays many Quality Assurance teams are combining manual testing with automated testing. Automated tests can be created by the QA team members who have a programming background. They can take the form of shellscripts for UNIX environments, batch tests for DOS environments and sometimes modules created in Perl, VB, C or C++, etc.. However, today there are also many automated test tools commercially available. Used properly, these test tools can save time – eventually – by automating repetitive test processes, and helping to improve the overall quality of the testing process.
Unfortunately, these tools are often touted, by their P.R. and Sales staff, as 'wonder tools' which can provide immediate, cost-effective, time-saving relief for the testing staff and for the process of testing itself. This is decidely not true! Each of these tools has its own learning curve and its own 'bugs'. Also, not every testing tool will work in every environment either.<< Previous | Glossary >> Return to:
Copyright © 1998 – 2000 Violet Weed, Inc. – Microsoft / Novell / Oracle / Sun Certified