The Evolution of Software Testing
By: Akshata Naikar
Tags: Test Automation, Software Testing Trends, Software Testing

Software Testing Life Cycle

The summer of 2004, I graduated with a bachelor’s degree, majoring in the coveted “Computer Science and Engineering” field. I was hired by a multi-national company on campus, and started my software career soon after. My first role was that of a Software Integration and Test Engineer which I immensely enjoyed, before being bit by the programming bug. I attribute my good coding skills to my brief experience as a QA engineer, since consciously I started thinking from the perspective of a tester and wrote different test cases to break the code I have built. Software testing, which is an integral part of software development process, has evolved over the decades.

Software testing is the process of running a program with the intention of finding errors — Glenford J. Myers.

In 1957, Charles L. Baker distinguished program testing from debugging in his review of the book Digital Computer Programming by Dan McCracken. The review is published in the journal Mathematical Tables and Other Aids to Computation. In 1979, Glenford J. Myers introduced the separation of debugging from testing. Although his attention was on breakage testing, it illustrated the desire of the software engineering community to separate fundamental development activities, such as debugging, from that of verification.

In this article, I have presented the various best practices we’ve adopted and upcoming trends in software testing.

Waterfall Model

In most of the teams I’ve worked with, software development and testing were treated as mutually independent activities. For the most part, we adopted the traditional waterfall model for development and testing activities. Testing activities begun only after the software was fully developed and all the features were implemented. QA engineers were not very actively involved during the requirement analysis phase and had very limited interactions with business stakeholders and product management team. They were heavily dependent on the design documents and information gathered from developers who wrote the code. The lack of insight into the requirements and customer expectations led to limited testing strategies and the testing plan was not comprehensive. Often times, issues were raised by support during the UAT phase since the team wasn’t aware of customer specific use case scenarios. Also, most of the testing activities were manual and simulation tools were used only for performance and stress testing phases. This resulted in a long QA testing cycle for any major release/project. Furthermore, we ended up having additional release cycles, just to incorporate customer’s feedback on the software we had built.

Agile Model

The need of the hour was to move towards agile principles in order to support adaptive planning, evolutionary development, early delivery, continual improvement and flexible responses to change. By adopting agile culture, we were able to create self-organizing and cross-functional teams, and product owners became an integral part of our scrum team. With this agile approach, QA engineers were more involved during the requirements validation phase and when developers were coding, QA were writing the test cases. We were able to implement and test the new features in a continuous and iterative approach.