If computing began in the 1950’s, when did software testing begin? In the every early days, testing and most everything else was left up to the development community. With the low level languages such as Assembler, it took a very specialized skill set to write programs. There was an unfounded belief and trust that the programmer understood what was needed and what was in the best interest of the company. Testing, therefore, was the responsibility of the person who wrote the program.

In the 1950’s the general belief was that testing was something that the programmers did to find “bugs”. Nowadays, the terminology is often to find “testing defects”. However, during the 1970’s, most people viewed testing as the way to execute a program to find errors and break it.

In the 1980’s, with the introduction of personal computers, developers began to push the responsibility for testing out to the end user. If the code didn’t work, it was the end user’s fault.

We now know that poorly defined requirements are often the root cause of systems that don’t work well nor satisfy the customer. I recently attended a seminar on software testing techniques. Details were provided about many references books and standards. Interestingly, Glenford J. Myers’ book titled, The Art of Software Testing, has tools, techniques and ideas that are as relevant in today’s web based testing world, as they were when he wrote the book in 1979! Imagine, software-testing techniques were described so long ago and aren’t used consistently yet!
Some of Glenford Myer’s key testing principles includes:

• Testing is an extremely creative and intellectually challenging task-therefore, the testing process should begin at the beginning of the project and not be an “add on” at the end. The probability of the existence of more defects in a program is proportional to the number of defects already found. Therefore, track your defects back to the business functions that are being tested and monitor where the large numbers of defects occur. Target this area of the application under test for many tests to find more defects and increase the quality of that function.
• Avoid throwaway test cases unless the function under test is to be single use too. Therefore, you need to plan out your test cases and scripts carefully so that you can reuse as many as possible in subsequent projects. This technique is old, yet its application is not well used.
• Certainly consider using an automated test tool for as many multi-use test cases as possible. This will reduce the test execution time and allow knowledgeable functional test resources to focus on developing special test cases for other aspects of the application.

In summary, software testing is a process that requires dedicated and specially trained professionals.