I understand "devops" to be the application of the development processes (issue tracking, version control, release management...) to operations tasks (deployment, migration...).

Is there an equivalent term for the application of development processes to QA tasks (testing that only a human can perform, rather than automated testing or continuous integration)?

  • 5
    Based on the question in the body, it seems like you're under the impression that DevOps is "the application of development processes to operations tasks". Where did you get this idea? – Thomas Owens Jun 4 '18 at 13:36

Terms like DevOps are subject to the whims of enthusiastic marketing and consultancy folk and all too quickly become "must have" buzz words. But underlying it is a simple concept: infrequent, "big bang" integration, testing and development are expensive, time-consuming processes that generate antagonism between teams. Further, unless developers are responsible for fixing their own bugs, a culture of "works on my machine" must be tackled all the time.

So don't do it that way. Instead, automate highly repetitive tasks and perform them frequently, giving us continuous integration and deployment, unit and other automated tests. And make dev teams responsible for maintenance. These approaches are efficient, inexpensive and reduce animosity between teams.

What DevOps is not is the "application of the development processes ... to operations tasks". This is a highly simplistic, developer-orientated view of things. Many of the techniques that DevOps supplies to an organisation is in fixing problems with the development process.

But to your question:

Is there an equivalent term for the application of development processes to QA tasks (testing that only a human can perform, rather than automated testing or continuous integration)?

DevOps practices encourage early, frequent, integration and testing. That is achieved via automated testing. When developers and testers collaborate, that automated testing can cover most of what traditionally was seen as "QA's job", ie working through test scripts, manually repeating the same tests over and over. Instead, testers are left free to perform exploratory testing, ie following their instincts in finding less obvious bugs, rather than sticking to a script.

There is no "DevTest" as it's not needed. That's already covered by DevOps.

| improve this answer | |
  • 2
    "DevOps is not the application of the development processes ... to operations tasks" - In fact I would go so far as to claim the inverse, Having worked in old fashioned manufacturing operations, DevOps is the application of standard operations techniques to the Development Process . The goal is to integrate software development as a component of the supply chain – crasic Jun 4 '18 at 18:04

DevOps is not the "application of the development processes to operations tasks". There are a few different takes on what DevOps is, but I describe it as a mindset or culture where the deployment, operations, and maintenance of a system is considered throughout the SDLC.

The idea of "DevTest" or "DevQA" already exist. It's called Agile, as defined by the Manifesto for Agile Software Development and the Twelve Principles Behind the Agile Manifesto. Although the Agile Manifesto isn't the only way to break down silos in an organization, it is probably one of the most common.

To understand this, you'd have to step back in time. In the days when plan-driven models were seen as the way to build software, you would have silos. Depending on the organizations, the silos would be different, but would often be based on the phases of the SDLC - you'd have a requirements team that turned stakeholder needs into a specification, an architecture and design team that turned the requirements into a design specification, a coding team that would take the design specification and turn it into code, a test team that would take the built product and test it, and then a release or operations team that would take the system and deploy it and run it.

But this wasn't efficient. The idea of "throwing work over the wall" to the next team just led to communication delays, rework, and other waste and slowness in the development cycle. The various Agile methods realized this and sought to tear down the walls of product development and called for cross-functional teams - nearly all of the agile processes (XP, Scrum, Disciplined Agile Delivery and so on) call for a cross-functional team that contains all of the knowledge and experience needed to deliver working software on a regular basis.

However, in the early days of what would become the Agile methods (the late 1980s and 1990s), operations was different than it is today. Advances in virtualization, containerization, infrastructure as code (and the ability to more readily manage the configuration of infrastructure), and cloud computing changed how operations tasks could be done. These advances and changes led to the ability to tear down the silos between the product development organization (business and product, development, test, quality assurance) and the operations team.

Going back to the Agile Manifesto and the principles behind it, a few of the principles would be a little different in a DevOps culture:

Business people, developers, and operations staff must work together daily throughout the project.

Working software and the infrastructure it runs on is the primary measure of progress.

The best architectures, requirements, and designs, and infrastructures emerge from self-organizing teams.

The way that this manifests would depend on the development organization. It may be a continued operations team that is involved with ongoing development as a form of a specialist role. It could mean that operations experts are put on each team to support the team's activities. It could also mean that one or more members of the development teams have some level of cross-training in operations work. Or it could be a combination of these.

| improve this answer | |

Yes, I have seen the term 'Developer in Test' and similar. It means employing developers to test stuff.

This boils down to writing automated tests, normally UI or 'functional' tests that run on the actual finished product rather than integration or unit tests.

If the term hasn't gained as much popularity as devops its probably because it has become so ubiquitous.

To be a 'Tester' these days means writing automated tests, which means you are just as much a programmer as the developers.

| improve this answer | |

I have never heard of a "DevTest" or "DevQA". I am not sure what that would look like.

In DevOps, you should be leveraging the concept of Continuous Delivery. As such, your testing and QA process is built in. Ideally, you will be able to build, test, deploy your apps in a fast and automated manner.

Regarding your human versus automated testing question. When you have human testing in the delivery pipeline, I do not see why the process would change. You simply work that manual testing into your pipeline.

Two books on DevOps that I personally have found helpful:

  • The Phoenix Project, A Novel About IT, DevOps, and Helping Your Business Win by Kevin Behr, George Spafford & Gene Kim

  • The DevOps Handbook: How to Create World-Class Agility, Reliability, and Security in Technology Organizations by Gene Kim, Patrick Debois, John Willis, Jez Humble & John Allspaw

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.