DevOps Enabled By Testers
“Testers must become engineers” say the IT leaders that have gone through their DevOps transformation journey. While that is a goal that has proven to generate higher quality software and much better software development throughput in highly mature software engineering organizations (e.g. the unicorns), in the traditional enterprise, that goal can’t be achieved overnight.
A few weeks ago I was talking to an IT executive at a company trying to wrap her head around the role of Testing as a practice in a world of Agile and DevOps. Her organization has been going through an Agile transformation for the past 3 years, but they haven’t seen any significant improvement in the business outcomes IT generates. It has been a costly transformation.
In their view, they’ve established Agile only took the company as far as developing code faster, but there is still a bottleneck to take that code to the hands of their end users. Now they’re starting their DevOps journey to remove that bottleneck and accelerate the release of that code as well as implement an appropriate feedback loop between users and the business. That company believes that the business agility that Agile promised can only be achieved by combining Agile and DevOps.
Agile + DevOps
By merging their Agile and DevOps transformation initiatives, another question came up. What about the Testing Center of Excellence (TCoE)? For the Agile transformation, that TCoE simply embedded their testers into the scrum teams and reused the same testing practices they were already equipped with from the waterfall days. To modernize testing processes, skills and tooling to better serve the Agile transformation was deemed too costly by the company, so they did what they could.
With DevOps, that same approach won’t work. If testing is not performed at the pace of development, the desired speed to release software to users won’t be achieved. That means testing, once again, will be seen as the bottleneck. Among many challenges, the TCoE is responsible for centralizing testing across all lines of businesses and also for the 4 major enterprise releases that happen every year.
In doing their own research, the company found out a lot of information on how testing should transform to support DevOps adoption. Upskilling testers so they acquire similar skills to developers is certainly one of the most talked about initiatives. So that IT executive said that about 5 months ago they took that to the letter. They asked their IT partner, a large System Integrator (SI), to train their TCoE staff in how to create JUnit code so testers could understand, and maybe even help, developers to adopt Test-Driven Development practices.
It was a 5-day training. In person. Classroom style. Mandatory. Fifty people in each class. The training program was planned to last 3 months to train around 600 testers in the TCoE. She said “by the end of lunch time in the first day of the first class, half the testers never came back. By the end of the day, only 3 people remained”. Obviously, I asked her why. She smiled and said “the 3 people were test automation engineers. The others were all manual testers. And that was the lesson I learned in the hardest way possible”.
This IT executive said she had fought hard to secure the budget for the training, positioning it to her leadership as crucial for the future of DevOps success. What she never considered was the background of the manual testers and their desire to learn something as technical as the JUnit framework. She took it personally, given it was such a bold and smart move on her part. So she thought.
When talking to some of those manual testers to try to understand why they left, she realized most of them had no technical background whatsoever. Many of them had been recruited from the company’s call centers, stores and branches due to their subject matter expertise on the business as well as their unique customer-focused perspective. Most had no college degree and the ones that did have, were usually not a technical one.
Needless to say, she cancelled the training mid-week to reassess her next move. And she lost a lot of political capital in the organization.
People first. Always
As we were having that conversation, the IT executive was asking how to properly map out her organization, including her Testing CoE. She wanted to define a better way to position testing as the enabler to the DevOps transformation the IT organization requires.
There is no cookie-cutter approach to DevOps transformation. Especially when it comes to testing teams and how they should adapt themselves in this new world. So we should learn as much as we can from leaders that have gone through that Agile + DevOps transformation and, after many scars, have made it to the other side. They’ve impacted business outcomes by positioning testing as the enabler to Agile + DevOps adoption at scale.
Learn, then take the lessons that are applicable to your own organization and apply them gradually. Radical changes in the enterprise environment rarely generate positive results. Take baby steps and measure results. Pivot as needed. Learn from it. Celebrate success. Advertise success across the organization. Take the next step. Soon more teams will take interest and the transformation will be natural and organic. The goal is to have the top-down transformation mandate meet the bottom-up organic transformation enthusiasm.
Data Specialist at Turing.com
3 年Alex, thanks for sharing!
Associate Solutions Consultant at Adobe || PGDM - IMI, New Delhi
3 年Alex, thanks for sharing!
Senior Scrum Master | Agile Project Manager
6 年Thank you for sharing. There is no recipe for an evolution from traditional testing to Agile Testing. Yet, everyone expects that by throwing traditional testers and testing methods into an Agile Team, that all will be well. It's great that senior people actually share experiences like these
Director of Quality Assurance at Redpoint Global
6 年Great post Alex - so what advice/recommendations/lessons learned do you have for the QA shops that have tons of SME knowledge on how the business and applications should function - but not the technical knowledge of a developer for junit, etc? It's a bit of a conundrum for the industry - how to make the transformation and not lose the business knowledge....
Agile Coach, Testing Specialist (Retired)
6 年Great post , strong message, Alex. Thanks for sharing. Along with the mindset and background of testers I've also found that including Product Owners and other stakeholders in some gaming and other learnings in order for folks to at minimum appreciate XP practices and need. This can possibly lead to some BDD but definitely assists with collaborative ATDD beginnings which manual testers can use as springboard.