Striking The Balance: Is DevOps Going To Kill QA? (Part 5)

Where are the main hold-ups in the software production process?

According to a research among 250 IT professionals regarding the main hold–ups in the software production process, the result is as follows:

Despite that, the answer to the question is DevOps going to kill QA is NO as there is no way that the companies will ever be able to find the “full – stack” dreamed developers.
There is a common misunderstanding though, that bringing the ideas, practices, and methods of the DevOps in the organization means that the QAs will need to find a new job.

Maybe DevOps doesn’t mandate or require independent test teams to be present in the organization, but that definitely does not mean that there will be no need of testing.
In a perfect DevOps world, everyone is responsible for QA, but not everyone has the tools, knowledge, and expertise to do QA right.

In most organizations that are transitioning to DevOps, what we see is that only half of the processes are being aligned with what is supposed to be DevOps. Along with that, many critics of the DevOps state and not without reason, that the DevOps culture is good and fit for the startups, but usually turns out to be a bottleneck for corporations.

What does DevOps stand for?

Once you have a smooth process for agile development and continuous integration (how many have these two running smoothly?), automating the deployment process makes total sense because it is fulfilling the objectives that the business craves:

1. Faster time to market;
2. Higher quality;
3. Increased organizational effectiveness;

So, we should pay attention to the following – the notion of “QUALITY” is built into the fabric of the DevOps idea. If you cannot reliably release high – quality software, then the DevOps is bound to fail.
It is clear that when the companies are adopting this model – merging the Development and the Operational Teams, they are striving to facilitate a practice of automated software development.
DevOps usually provides the structure that enables teams to push software out as a service on a weekly, or daily, or even hourly basis.

Some even say this is the next step to agile methodologies. Because DevOps is Agile taken through its logical evolution: removing all the obstacles to getting high – quality software in the hands of the customer.

As Carl Schmidt, CTO of Unbounce said:

“I’m of the mindset that any change at all (software or systems configuration) can flow through one unified pipeline that ends with QA verification. In a more traditional organization, QA is often seen as being gatekeepers between environments. However, in a DevOps – infused culture, QA can now verify the environments themselves, because now the infrastructure is code.” And “It’s QA’s responsibility to actually push new code out to production, so the DevOps team has been providing them with tools that make blue-green deployments push-button easy. Our QA team can then initiate deploys, verify that the intended change functions as expected, cut cover to the newly deployed code, and also roll back if there is any reported issue.”

Despite what is thought, QA has a critical role in the DevOps organizational structure.

That is due to the fact that if applied properly, the DevOps suggests that the QAs have the visibility and the directive to push the code out when it is working, and roll it back when it is not.

Yes, that is truly a very different mindset than QA organizations had 10 years ago, where the primary goal was finding bugs. In DevOps it is all about preventing bugs, not finding them.

So, in DevOps, the QA groups are charged with preventing the defects from reaching out to the public.

The shifted role of QAs in DevOps

The shifted role of the QAs in the DevOps organizational structure has several implications:

• QA owes continuous improvement and quality tracking across the entire development cycle. The QA is the one primarily responsible for finding problems, but not only in the product, also in the process. They are also to recommend changes and improvement whenever they can.
• Tests are code that is a necessity. If you are to release every day or week, there will be no time for manual testing – you must develop automation systems, through code, that can ensure quality standards are maintained.
• Automation rules. Anything that can be automated, should be automated.
• Testers become the quality advocates and thus influencing both development and operational processes, they don’t just find bugs. They look for any opportunity to improve repeatability and predictability.

In no way will DevOps kill QA, but it will definitely transform it. And some of the new roles are:

QAs will still champion quality as many DevOps organizations have adopted a test-driven approach and continuous testing. And, instead of running the tests and handling the hands-on work, QA pros will transition into a more consultative and distributed role to help developers learn how to write better tests and improve their approach to screening quality. Because, at the end of the day, the developers are still developers and QAs are still QAs.

The QA role will move to mentoring as well – as supposed, in the DevOps organizational structure, the Developers will write the test cases, and to avoid the half-baked tests, it is really important that the QAs give guidance and advice on how to write them and review them after that.

The QA role will also shift to a more decision making one – there will probably be a change in the organizational chart and the QA pros will definitely affect more the development process of a product.
In summary, if we decide to believe that everything will shift to DevOps (we don’t), we can imagine the future this way:

• There is definitely an opportunity to embed QA expertise directly within product teams to directly support them.
• There is also the option to divert the QAs into tooling groups, responsible for writing the test harness, or providing tooling across the organization.
• And, there is the possibility to create a center of excellence or a consulting group meant to advise specific workgroups on strategic issues of quality.
• If the trend of automation and DevOps continue, the QAs should start thinking about how to help elevate a test approach rather than executing it.

What is the future?

Some see the DevOps practices as good only for startups, but not all companies are startups where, for example, the developer should also be a database analyst, a QA, and an operations analyst.
There is no such person who can take all these roles equally and has all the knowledge to not make mistakes.

It is clear, should the DevOps trend continue, there will definitely be a shift in roles, but neither the QA, nor the Developer role will go extinct.

And in the end? What is behind the wrong perception of most companies for the DevOps idea?

• DevOps doesn’t make specialists obsolete…
• Developers can learn about systems and operations, but nothing beats experience…
• Operations people can learn development too, but again, nothing beats experience…
• Operations and development have historically been separated for a reason – there are compromises you must make if you integrate the two…
• Tools and automation are not enough…QAs are also needed…

Of course, this is our take at the issue, but we’d like to raise a debate on the topic and help people involved in the field think more critically about the need for good testing in a software project.