DevOps Model: The Role of Quality Assurance Redefined
Quality assuarance professionals, take notice. Everything is about to change.
Join the DZone community and get the full member experience.Join For Free
you might have come across devops so often that it may seem to penetrate each and every organization slightly related to it. but the reality is different, as always. the point is that this model is far more complicated to apply compared to agile and other popular forms of sdlc because the role of each department undergoes significant changes.
what is devops?
although many definitions are available, we think of devops as the space for keeping the software deployable regardless of the new features implemented. most importantly, devops means that everyone — from jr. analyst to developer, qa engineer, project manager, and owner — takes equal responsibility and makes a contribution to product success.
the fundamental benefit of the model is a clear segmentation of roles that follows the principles of continuous integration and delivery (ci/cd).*
*off-top for those unaware: ci/cd is a concept that enables effective merge of newly developed features into the main codebase. it fulfills the integration aspect by running different tests at each sprint stage and provides delivery aspect by deploying the committed code into the software available for the end-user.
back to the roles. although separated, devops is a strategy that embeds each just in time and keeps their activity during the whole product growth.
- developers and designers (devs) build the software logic following user stories, create features that work and prove that via unit tests.
- quality engineers (qes) help maintain software quality, review the features, write acceptance/end-to-end tests, and approve the software correspondence to the requirements.
- product owners (pos) and business analysts (bas) cover the aspect of business value for the end-user, coming up with the user stories. often, they have to coordinate and analyze the acceptance test results to check their relevance and implement changes in user story when necessary.
- operations (ops) takes care of the software released. they make sure it is available for the users. thus, they work on the code logistics design to move developers' code to a production environment where people access the website/app.
devops and qa
in a pure devops world, qa is an enabler, not a gatekeeper. the model is all about blurring the boundaries between the roles of qa and development in project delivery. meaning the part of software quality assurance goes in line with development and operations, creating a backup line for correct product functioning.
these are the areas to work on when implementing qa into a devops environment:
- merging the teams. one of the critical aspects to consider is integrating the team of quality assurance with other technical specialists involved in the project. in such a way, qa becomes a strong enabler for ensuring product quality during the whole development lifecycle. besides, such team structure allows detecting tangible aspects of the quality required from the final product.
- metrics. clear quality metrics are of absolute importance in devops. the core idea is to find the defects at the earliest stages and prevent serious hurdles on the way. at the same time, this helps to make the team focused on the requirements, stay tuned to any changes within. besides, qa engineers keep an eye on important details which could have been missed due to miscommunication. the task of qa engineers here is to actively implement the requirements into the process and guide the dev team in the right direction.
- qa + dev. this is all about communicating the goals of each team. the ever-debated topic of getting qa and developers cooperate acquires more significance in devops culture. project managers know how complicated it might be to make qa specialists and programmers think in line. yet devops requires constant quality maintenance, which is, checking the software for potential errors. this is the place where continuous integration and continuous testing evolve.
- qa + ops. since operations make the product available for the end-user, their cooperation with qa is also of prior importance. the user-oriented approach of qa engineers implies the software flow desirable and comfortable for people, justifying the construction efforts of the whole team.
- parallel tests. when working under devops, companies ensure the qa team runs the tests continuously. however, there is a need to explore the ways qa pros perform the tests without extending the software delivery time. the it-experts and authors at dzone claim the qa engineers have to fully standardize the testing environment, automate the process of test implementation. what's more, the effective parallel testing strategy requires enough resources, and this is also a point for the management board to think over before the process starts. parallel check-ups of the software help qa engineers run test cases under different conditions and deliver more reliable results.
why continuous testing matters
continuous testing (ct) and continuous delivery are the other two milestones of the devops culture. test early and test often — that's how the key principle of continuous testing sounds. it implies the use of agile-related methods to build a qa strategy. although devops highly encourages automating the whole testing process, qa engineers still play an important role in providing testing solutions into the development. when effectively implemented, ct helps to detect risks, address them, and enhance product quality. that's a relatively new concept in the area of tech, yet qa engineers achieve ct process via automated test cases and support each development stage with instant feedback.
notably, devops is an environment of highly coordinated cross-team functioning in the development chain. in a perfect scenario, with continuous testing and delivery, a developer configures deployments, and while a qa engineer configures automated test cases, developers add them to the qa repository. as such, the team takes collective responsibility for the software quality, together adheres to the deadlines.
the roles acquired
with the devops emphasis-on-automation approach, many think that traditional software quality assurance might be called into question. the transformed relations of development and operation stuff could be one of the reasons for that. there is also an opinion that independent software testing service providers with the qa engineers performing their prior function are slowly becoming outdated.
sounds scary. what if we say qa engineers still have plenty of work to do in devops environment? the truth is that the reinvented role of operations (ops) in the product development has a powerful impact on the role qa engineer must be ready to acquire.
software qa as a consultant
seems like qa experts won't be working the same role anymore. for devops, a qa engineer would have to change their mindset and start helping businesses to grow instead of providing traditional testing services. luckily, our experience shows most software testers can make this shift. qa consulting is one of the most effective shifts we've taken recently. just because a structured audit provides an unbiased review of the software, and reveals potential changes, suggested ways to improve the project.
so instead of running tests and crafting the documentation, qa pros will have to transition to software quality expert consulting and help developers learn how to make their approach more quality-oriented.
software qa as a strategist
there always been an opportunity to embed qa expertise directly to development via scrum. when the qa part is involved from the very beginning of each sprint, product growth takes a totally different path. to account for a crucial role of testing expertise and responsibility in the devops model, qa engineers should look for the new ways to add value in the software lifecycle. this means making high-level strategic decisions related to testing and software quality assurance. the point is that a qa engineer thinks about what end-users are doing and how they interact with the software. this is what a qa strategy often lacks. qa engineers might consult the team on how to mimic user-experience to determine what is required to meet users' needs. no more “passed/failed.”
final: any challenges?
one of the major hurdles devops model implies is the process itself. a lot of tech specialists used to their responsibilities will have to redefine their roles. moreover, to combine several teams takes effort and requires high-standard management and resources. that's why there are still companies resistant to devops culture.
it is a relatively young method, though. if you approach it with open mind and implement it step-by-step, you'll manage to bring the best parts together into a greater whole.
Opinions expressed by DZone contributors are their own.