Why “Test Obsession” Is the Disruptive Culture of the Future
A look at why testing so easily disrupts the software development lifecycle, and how testing can keep up with a fast-paced world.
Join the DZone community and get the full member experience.Join For Free
After learning that Alaska Airlines has won the “Highest in Customer Satisfaction Among Traditional Carriers” award for eight years running, and the “Number 1 on-time major North American Carrier” award for the last five, I would assume that their dedication to incredible software quality is just as worthy of public heralding.
Parasoft, one of our outstanding TapIn Partners, recently sponsored a webinar where they were joined by Forrester Vice President & Principal Analyst Diego Lo Giudice, and Alaska Airlines Automated Test Engineer Ryan Papineau. Titled, “Why Testers Can’t Test”, and now available to watch on-demand, Diego, Ryan, and Parasoft make a terrific case for the technologies available to development and test teams who are looking to improve the quality of their software—and not at the cost of speed.
In the webinar, Diego talks about testing being, “one of the most disruptive stages of the SDLC”, and he describes many organizations as being at a crossroads of sorts when it comes to trying to keep up with today’s pace of software development while not letting software quality go to the dogs. His suggestion when faced with those crossroads is to become “test obsessed” and dramatically increase the amount of testing you’re doing—as early and often in the SDLC as possible.
This understandably presents quite a challenge for many enterprises, especially those who have long viewed testing as an impediment to delivery speed and innovation. I assume that those organizations are often guilty of viewing IT in the same light.
But to be fair, for those who have long kept testing as a time-boxed event held only at the late stages of the SDLC, it’s probably difficult to view testing as anything but a speed trap or even a money pit.
Diego later points out that in some cases, as much as 40% of a test manager’s budget becomes ensnarled in delays and costs related to inconsistent, incomplete, slowly-provisioned environments. Deadlines approach or even pass with not enough testing being done, bugs show up in production and the cycle repeats itself with each new release.
This is a real problem for many organizations today, as evidenced by the number of headline grabbing defects, bugs, security flaws, and software crashes in every industry imaginable. I’ve covered this space before, and so has Parasoft’s Wayne Ariola. Wayne presented his session, “What do software defects really cost?” at the 2015 STAREAST conference, and I marveled at how stunned a room of testers were at the true damage that production-stage defects can have on global enterprises.
Unfortunately, the solution to this ongoing “failure to focus on software quality”, as Ariola puts it, is not easily reached and it definitely won’t be the result of simply purchasing more hardware or even cloud infrastructure. After pointing out the amazing things that Alaska Airlines has been able to accomplish with continuous testing and service virtualization, Ryan Papineau was asked what one of the biggest challenges was when he and others began to transform the way the airline looked at software testing. He answered, “Building trust.”
That trust can be incredibly hard to come by, especially when first moving to DevOps, cloud-based dev/test environments, or any other truly disruptive cultural shift that changes the way things have seemingly always been done.
Many of us are hesitant to, or skeptical of change, especially change that may take away existing responsibilities, assign us new tasks we’re unfamiliar with, or require our collaboration with departments that have lacked our trust. But my hopes are that with more success stories like Alaska Airlines, organizations will soon see that the positive cultural impact from embracing disruptive technologies like those listed above will long outlive the fears and doubt.
Published at DZone with permission of Noel Wurst, DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.