Software Testing: A History

Software testing now enjoys a level of acceptance that was not always there. In the early days of software development, debugging was the primary form of software test. It was primarily performed by the programmer who wrote the code and the object was to get the application to working without crashing the system.

End users played a very small role in the acceptance of the applications during those days. It was up to the user to learn how to manipulate the program to achieve his/her expected results. If the program did not produce the desired outcomes, the user had to find ways to adjust data or entry techniques in order to reach the anticipated end goal.

A Brief History

When I joined DataPoint Corporation in 1974, I was hired directly into the Test Department. Our job was to design and produce test equipment and procedures to test production line printed circuit boards. The emphasis was on hardware testing. It was well understood that a board had to be properly populated and functioning correctly in order to perform its task successfully.

DataPoint was, as I like to believe, the creator of the first desk top, personal computer – the DataPoint 2200. The 2200 was an amazing machine for its time: completely self-contained, had a small desktop footprint and performed some very useful tasks with complete independence. It had its own operating system and all of the applications were developed in-house. The hardware was thoroughly tested, but the Test Department did not have a Software Test Division. All software testing was performed by the engineering department that was responsible for its development. When I left DataPoint in 1980, very little had changed in that regard. Software testing was still little more than an after-thought.

Progress Creates Problems

With the advent of the Graphical User Interface (the GUI) and user friendly software, the need for more comprehensive software testing became evident. User friendly put more responsibility on the developer’s shoulders to create programs that could be run out of the box. Unfortunately, developers do not think like end-users. Manufacturers found it necessary to hire teams of outside ìexpertsî to simulate the activity of the end-user. These ìexpertsî were expected to find any problems that the end-user might experience but do it before the product was released.

Beta testing became popular at about that time. Beta testing is the practice of allowing knowledgeable end-users access to the programs and exercising them in a manner consistent with the way an actual end-user would use the product in the field. The problem with beta testing, however, is that it begins at the end of the production cycle. If the beta testers found any significant defects, that meant the project had to be returned to development, determine the cause of the problem, fix it then return it to the beta testers. This cost the manufacturer time and money and could cause cost over-runs as well as shipment delays. Obviously, this was not the best approach to producing a profitable, revenue-generating product.

A Solution Waiting to be Discovered

Fortunately, smarter minds and common sense prevailed and a more thorough and deliberate software testing scheme was established. Today, the testing of a software product begins with the planning of the product. The software testing cycle co-exists with the production cycle. Specialized teams are established to work side-by-side with the developers and planners. Software Test Plans have become an integral part of the deliverable package to the customer. These plans cover the procedures that will be put into place while the product is under development and finalized before the product is delivered to the end user.

Future Exploration

Utilizing the resources of this forum, I would like to present to you the various stages, levels and processes that have become so important in the production life-cycle. I will talk about the various levels of testing: Unit, Integration, System, User Acceptance, Regression, et al. I will delve into white box and black box (and maybe even gray box) testing. I will discuss the newest member of the testing group: Performance Testing and its end-goals and misconceptions. And I will go into what many call ìnegative testing. This is the practice of trying to get the program to do something itís not supposed to do.

I hope to present these concepts and practices in an entertaining and enlightening manner that you will find difficult to put down. Along the way, I will expose some myths and reveal to you a very challenging and rewarding career field. Hope to see you next week and hear from you during the process.