Quality Matters: The DevOps Tipping Point

Software development is at an interesting point in its history. We stand at a time in which the very first pioneers of our industry are still active, but are slowly stepping aside as the industry they created goes through another transformation.  Over the last 40+ years, the software development has gone through several transformations or shifts, to borrow the concept used today.  The current shift in the software development process is by far the most dramatic I have witnessed in the last 15 years.  As it was recently described it to me, automation has been done in many other industries but not software.  This shift is software development's turn at automation.

The shift to automate software development is referred to as DevOps, it is the merger of infrastructure and software development into one seamless process.  I have heard it referred as bringing the agile process to infrastructure; however, I see it as a combination of both agile and the automation of the development process.  Don't confuse test automation with DevOps automation, they are not the same thing. Test automation is one piece of the process and is a critical piece as well.  A topic for another article.

Your competition is eating your lunch, dinner and dessert before you finish your breakfast.

 In the past several months, I have read countless articles and blog posts regarding the role of the quality analyst, quality tester, automation engineer in the DevOps. Additionally, I have spoken to several companies both large and small in the Atlanta market, and there is a very clear direction, that DevOps shift is underway.  To steal the point of Malcolm Gladwell’s famous book, Tipping Point, DevOps is at the tipping point.  For those on the West Coast, where DevOps originated, it is likely you have already experienced this shift but those of us on the East Coast, we are beginning the transformation.  Undoing this shift is going to be difficult and very costly in the event the ROI proves to be incorrect.  For example, one Fortune 30 company has eliminated the quality roles and moved to a developer centric model with a Quality Center of Excellence (QCE).  Another Fortune 150 company is implementing a QCE but is maintaining quality roles as Software Engineers in Test (SETs).  A growing start-up does not have quality analysts, instead their development team handles the testing and they hire quality testers to perform Usability Testing and Ad-Hoc user testing.

I can share a growing list of examples of how companies are embrace DevOps.  If you are in a quality role, from tester to analyst to manager to automation engineer, it’s time to embrace the change and learn new skills.  There are plenty of traditional QA roles, but the shift to SET or SDET (Software Development Engineer in Test) is well underway.  Job postings for these types of roles than traditional roles are plentiful, and because job postings generally only account for 15% of all job searches, the numbers of SET and SDET roles are likely much higher.

 With the shift to DevOps and the role of QA changing, quality is shifting.  It may surprise you however, the main driver behind the shift to DevOps is quality.  One of its tenets is to automate manual steps which are costly, timely and prone to human error.  Imagine a developer or SET submitting a pull request which begins a series of events that provides feedback in minutes or hours whether the submitted change is ready for deployment to a Production environment. Imagine the same scenario in which the feedback indicates that the change is not ready.  How much time and money is being saved by this timely feedback?

 DevOps attempts to solve the issues with the Project Management Triangle, software can be cheap, fast and good: pick two.  Quality is highly desired, in fact in all my conversations, quality is the primary concern.  The leaders I spoke with were confident their teams could deliver software quickly, while reducing costs, but traditional quality methodologies are too slow and test automation isn’t living up to the hype of increased speed, broader coverage and lower costs.  Quality is stuck in the Middle Ages; it requires months of time to properly prepare and analyze the software to test it with a high degree of confidence.  In today’s environment, months are too long.  Your competition is eating your lunch, dinner and dessert before you finish your breakfast.