There are several advantages for QA engineers who work in a DevOps practice

Testing is not conducted in a DevOps organization the same way as it is in the traditional waterfall software development lifecycle (SDLC). In the old model, developers would create a lot of code and then hand off a build to QA right before release. QA engineers would test for a period of time, usually under pressure to meet a ship date, and then either sign off or send it back to development.

In the DevOps world, the testing role has become more integrated with development at every step. QA engineers work side-by-side with developers and operations, resulting in fewer production bugs and overall improved product quality. Releases are bite-sized, allowing for quicker and more thorough testing of new or changed code.

Development, build, test, release processes are evaluated as part of the value stream to ensure they're efficient and necessary. Tasks and processes that happen repeatedly are considered for automation.

Shared Responsibility

In DevOps, all team members share responsibility for improving the security, compliance, and quality of software. This shared responsibility reduces friction between Test and Development and helps everyone work quickly to find better ways of completing tasks, avoid bugs, and work together. Under DevOps, new test cases could be added to the QA plan by test engineers, developers, or deployment engineers.

Upstream Automation

Developers, designers, build engineers, and others are all knowledgeable and talented people, but sometimes errors still happen because of PEBKAC ("problem exists between keyboard and chair"). DevOps' focus on automating approvals, code commits, and builds means fewer opportunities for user error to occur — even on a step that QA isn't actively testing.

The combination of cross-functional teams and upstream automation equates to a reduced Mean Time to Detection (MTTD). Errors and possible bugs are caught earlier in the development process before they become problems for end users.

Test Automation

Not all tests should be automated. It would likely take similar efforts to design and automate a test that you only plan to execute once as it would to manually run the test, so that would not be a candidate. Focus your test automation efforts on tests that are run repeatedly against every build, that are data-intensive, or that take hours to run.

Human QA engineers are better able to conduct user experience and release readiness tests. Automating the repetitive, tedious testing for machine-generated errors frees up QA engineers' time and intellectual acuity to focus on the more exciting and complex testing problems.

Test Coverage

As software integrations and architectures become more complex, the role of QA is incredibly critical. Ensure your test quality is high and that you're testing the application code, features, or requirements sufficiently by measuring overall test coverage and automated test coverage.

Automated test coverage is calculated by dividing automated coverage by total test coverage. Avoid adding additional tests to "game" the metric because that can delay builds and increase developer and tester efforts if and when those unnecessary tests return errors.

Testing Tools for DevOps

Get help automating tests and visibility into your test coverage with tools like SmartBear, Perforce Helix Test Case Management
, and Atlassian Crucible Peer Code Review.