There is this long-standing joke about Bill Gates’ supposed comments about GM and the rest of the auto industry, and the stinging riposte from GM (http://www.snopes.com/humor/jokes/autos.asp). As an aside, GM’s subsequent troubles with their ignition switch may have made some parts of the joke too real for comfort to GM insiders. However GM’s then apocryphal response to Gates, “Yes, but would you want your car to crash twice a day?” brought software bugs front and center into the discussion.
Although the joke dates back to the late 90s, bugs are certainly as troublesome today if not more. Considering the rapid expansion in the extent of software automation since then, the cost of software bugs has probably gone up several fold. Clearly it is impossible to find truly bug free software with the exception of perhaps specialized areas like the military, space exploration, or aviation. Certainly in the enterprise world eliminating bugs remains a utopian dream.
Given the realities of project deadlines and budget limitations (schedule, budget, or quality, pick two), bugs will likely continue to make it through into production. So far, holding them at bay has largely been the effort of QA teams through rigorous software testing. Manual testing continues to be a reliable workhorse. But what is increasingly catching the attention of management is automated testing. It is said that automated testing is no silver bullet; but it sure comes close to being one.
Developing scripts once and executing them repeatedly – hundreds and thousands of times – definitely has huge significance from a productivity standpoint. Keeping on testing is the idea: during development, at the time of integration, before deployment. In test driven development, tests are created even before a single line of code is written. With agile scrum, you have QA and development working hand in hand with considerably more communication and collaboration between the two groups.
Software is being pushed out at a faster and faster rate. Continuous integration of code by developer teams into shared repositories, continuous delivery of code to UAT or staging, and continuous deployment of code to production are here to stay. This has become the new normal especially for SaaS providers and mobile app developers, both of which markets should continue to grow at a rapid pace, consider Salesforce for example.
Driven by the impetus toward agile and more automation, perhaps we might start to see testing as an independent activity gradually begin to scale down. Instead we will likely have Dev and Test teams coalesce into each other.
Enter DevTest (possibly as an extension of DevOps) teams with members competent in both development and testing, most if not all of the testing being automated. Much of the testing is beginning to be done by developers writing and executing automated test scripts. (An apparent corollary: testers who don’t understand code could be at a career disadvantage. It should be easier for developers to acquire proficiency in automated testing than the other way around).
Going forward, software will be in a state of perpetual motion with builds flowing smoothly into production. Keeping pace with user needs in an always-on world will call for round the clock deployment. Continuous testing has become the new imperative, too critical to be solely left to QA teams. The 24-hour cycle is here for keeps and once again the pendulum is swinging toward developers.