If you work in software quality assurance (QA), it’s time to find a new job.
The overall software development process has always consisted of the following core activities:
- Creating a requirements analysis;
- Producing a specification of the software artifact;
- Constructing the software;
- Investigating the quality of the product or service;
- Finding and fixing defects; then
- Deploying to production.
In most organizations, this process generally has occurred within one or more methodologies such as waterfall or agile. In waterfall, the testing process occurs relatively late. The software is produced, bugs are found by the QA team and then the software is fixed. These last two practices repeat in a cycle until management is comfortable that it can be released to the public.
In agile, individuals and teams—including QA—work closely together to release and then update software on an ongoing basis rather than deploy an entire platform all together and all at once. DevOps, as we have written in our “What is DevOps?” guide, is the next generation of agile development. Agile is a way of thinking in software development; DevOps goes one step further and is a concrete cultural change that implements the philosophy within an organization.
And that implementation eliminates the need for QA as a separate entity in the organization and disperses the responsibility for quality across different teams, even though many have argued that the discipline is still needed in one form or another.
Past Interpretations of QA in DevOps
One common argument is that DevOps sits at the center of a Venn diagram of dev, ops, and QA:
On one side, QA works together with development in trying to push more of their tests into the continuous integration system. Tests must have zero human intervention and generate their own test data.
On the other side, QA works with operations to collaborate on monitoring tools; perhaps to continuously run smoke tests in production. Chances are that operations is developing scripts for backup and restore of production systems, rollback of deploy, or scripts for disaster recovery.
Tim Hinds at NeoTYS looks at the issue differently and says that “DevOps QA” is meant to prevent defects rather than find them:
QA takes a critical role in this organizational structure because they have the visibility and the directive to push code out when it is working, and roll it back when it is not. This is a very different mindset from QA organizations of 10 years ago, whose primary responsibilities involved finding bugs. Today QA groups are charged with preventing defects from reaching the public site.
With all due respect, both are wrong.
Why DevOps Does Not Need QA
DevOps often uses continuous integration (CI) and continuous delivery (CD). In CI, developers use various continuous integration tools to integrate code into a shared repository multiple times each day, and DevOps relies on automation to determine the quality of the version. You cannot have any human interaction if you want to run CD, which ensures that any version of a batch of code in the repository can be released at any given time.
Essentially, the traditional QA cannot work in a full CI/CD environment. In older structures, the responsibility for software quality was in the hands of QA. Today, it’s part of the DevOps culture and methodology—the developers now own the responsibility rather than a separate entity within the organization.
Specifically, DevOps entails the use of vendors and tools such as BUGtrack, JIRA and GitHub to aggregate and report software bugs and defects. Test automation tools including Selenium, Cucumber, JUnit, TestNG and JMeter manage, execute and measure functional tests and cycles.
In the end, if there is a layer of people in the middle between development and operations, then you cannot perform CI and CD seamlessly and, therefore, cannot do DevOps. To run a proper DevOps operation, you cannot have QA at all.
The Future of QA
So, what will happen to all of the people who work in QA? One of the happiest jobs in the United States might not be happy for long as more and more organizations move to DevOps and they become more and more redundant.
According to the U.S. Bureau of Labor Statistics (BLS), software quality engineering is one of the high-tech professions whose growth rate is projected to be slower than average:
However, the BLS numbers are likely too generous because the bureau does not yet recognize “DevOps” as a separate profession at all:
As evidence, just look at how the relative number of Google searches in Google Trends for “sqa jobs” is slowly declining while the number for “devops jobs” is rapidly increasing:
For QA, the trend definitely does not look good.
I could go ahead and argue in details with this article. But just so it happens I wrote a blog post yesterday on what QA-related areas might be important for DevOps: http://oso.com.pl/?p=498&lang=en
Does your vision of DevOps answer the questions that keep me awake at night?
I read your blog and certainly you raised some good points.
I do see the value in having everyone own the quality of the product and not just a certain group or individual and IMO DevOps is mostly about accountability which is being supported by process and automation and not the other way around.
— Asaf.
The QA function isn’t going to disappear, no matter whether you try to combine the function into the development organization (ala Software Development Engineer in Test, for example), or you try to merge it into DevOps, which makes even less sense to me.
There is a need to have an independent separate functional verification of whatever is being developed. Changing the software engineering methodology or release model doesn’t remove this requirement. This is true whether or not we’re talking about Test Driven Development, waterfall, agile, release management, continuous integration, etc.
You need this separate set of technical eyes that functions as a protector of both User and Business goals. Because they are human, Developers never provide a solution that works 100% of the time — the code never works exactly as they thought it would, and never meets all of the original goals, at least initially. Virtually all code fails the initial V&V test. There are ALWAYS bugs. Note this is whether or not Development’s unit tests pass — or pair programming is used, or if the peer code reviews pass. There are no perfect development strategies.
“Today, it’s part of the DevOps culture and methodology—the developers now own the responsibility rather than a separate entity within the organization.”
Developers cannot own the QA function. Besides the obvious conflict of interest items, if development’s understanding of initial requirements is wrong, their validation of them will be wrong too. The user will simply not be protected — no chance for a “hey, wait a minute” or “No, you understood that wrong….”
Regarding the use automation and tools for testing purposes, with all due respect, I think you’re misguided in how these things actually work.
Someone has to construct a manual test plan made up of test cases first. Again, the methodology really doesn’t matter. If requirements don’t come from a requirements document, then they come from interviews with the business user or product marketing team. Or they come from user stories and acceptance criteria formed during Sprint Planning Sessions. Or from exploratory testing of beta versions, or GUI mockups.
Long story short — that WAY before you start writing/recording your Selenium tests or using your testing frameworks like JUnit, you’ve got to decide what needs tested, and how you’re going to do that. And only then do you start looking at automating SOME of those. There are plenty of bugs found during exploratory testing even if you have a full suite of automated regression tests in place.
No matter what other “improvements” you want to make to the process or where you want to distribute the test engineers, the QA function is here to stay because it’s a required piece of the software development paradigm. This is as true today as it was 50+ years ago.
Here’s my response. I ran out of space i the comment box…. http://blog.gerrardconsulting.com/?q=node/666
well put, mate.
Strong reply
Thank you for putting together such a well crafted response to this article. A lot of uninformed individuals seems to have this perception that QA has no future in software development.
In my current organization, QA introduced the concept of CI and DevOps. Once a DevOps team was quickly established, the team worked closely together with Dev/QA to put out the best quality product to the public. We recognize that working together allowed us to become more effective at collaborating and becoming more proactive than reactive when it comes to enviromental changes and releases. Our efficiency increased and each specialized team focused on what they do best. We believe in the power of team collaboration!
QA is generally under-appreciated, the QA team usually get the blame for issues but rarely the glory for successes, and QA’s stress level is usually very high. I know that my team works very long hours, we are the first ones in the office and typically the last ones out of the office or end up working late nights at home/weekends to support a release. In the end we do what we do because we feel rewarded when we find bugs, have successful build releases with little to no bugs, and get some sort of recognition for our hard work.
I don’t believe that QA is going anywhere anytime soon and I am glad there advocates out there that are willing to step up and defend the QA practice from misinformed individuals.
Another one of these. Let’s not pull the fire alarm unless there is a fire.
Hi Asaf, Thank you for the post. Your perspective on DevOps diminishing the need of QA is quite interesting. Though I feel DevOps is an approach to be explored further.
You might like to check out this post on How DevOps Principles & Practices Improve Software Quality & Efficiency. Here’s the link – http://www.gallop.net/blog/devops-principles-practices-improve-software-quality/.
Do let me know your views as well.
Thank you Asaf,
Cheers,
Michael
Unlikely, the repsonsibility of qa is explanied as “… perhaps to continuously run smoke tests in production”. This is the last thing that you can do as a qa. Never perform tests on live. On the other hand, automated tests makes it eligible to automate everything so in the core of CI/CD, there is test automation. If you are releasing some unexpected features by CD with help of devOps, shut-down that process and return back to primitive software development process.
I’m a senior DevOps manager and have been for over a decade (it wasn’t called DevOps back then). Before that, I was a software engineer, programming since 1992 professionally and since 1978 as a kid. I have to say that I think the delivery of this article is absolutely terrible. It makes enemies and gets people to be defensive and territorial through threats about people’s livelihood. That goes completely against the main DevOps goal of system-wide thinking. You can’t optimize the efficiency of a system by creating silos caused by defensiveness and threats.
Not only is the delivery of the content terrible, I think the content and ideas contained within it are wrong as well. QA is not going to disappear – it’s becoming more automated. So instead of manually testing software, QA will be more focused on creating scripts to run the tests. They still have to come up with the test suites and test cases that validate the original requirements. So in my view, that’s an improvement for QA. I’d much rather spend time creating automated tests than running them manually – of course, I’m a developer at heart. You can call the whole pipeline DevOps, but QA is in there every step of the way and QA people are creating and plugging tests in all the time to increase quality as far left in the pipeline as possible. If anything, QA is more involved and engaged throughout all phases of the pipeline than ever before.
I’m disappointed that this article came up in my google search and that it exists on a site called staging-devopsy.kinsta.cloud. I hope the article isn’t just click-bait or trolling. What a bad name this article gives to DevOps as a movement. It’s anti-DevOps to create enemies between groups within a system.
I believe this is one of the most important information for me.
And i am satisfied reading your article. However
wanna statement on some general things, The site taste is perfect, the articles is in point of
fact nice : D. Good job, cheers
Fantasy Festival Videos
fantasy Festival Images
I loved the way you have mentioned and explained everything.
And yes the agile environment is killing the role of QA managers as there is scrum master, but I think going with agile is good in order to keep up the pace with other competitors .
You can also prefer to read this blog: http://www.sooperarticles.com/technology-articles/software-articles/role-qa-manager-agile-project-1609992.html
I think that 90% of the disagreement to the article would be eliminated if the author said that QA testing as a separate human role was going away instead of saying QA is going away. Of course quality is key in DevOps, but since the dev team is also the testing team (ideally the actual test routines are fully automated, and run from the start) as well as the operations team, the ownership of quality and hence successful Operations is on the developer.
Hello, I am new to this group. I want to know if the devops concept can be useful during defect fix is getting deployed in the test environment. Can this made as automated validation? its not a agile world for me but fixes are getting deployed everyday. The defect is fixed in the application but it breaks somewhere. Any idea for this is much appreciated.