Quality Engineer in DevOps

Nowadays, for most people, “Quality Engineers” refers to people who perform manual testing – clicking around the user interface of the system, trying to find all kind of bugs in different places. For others, “Quality Engineers” refer to people who are highly skilled in a specialized tool to test applications. Both definitions are not entirely wrong, as software quality is constantly evolving but they are missing a huge part of the puzzle. That is why we are writing this blog post to shed some light on the evolved role of a Quality Engineer and how to work with Devs in a DevOps Environment to build high-quality apps much faster.

Quality Engineering Evolution

Software Quality is an essential part of software development, with a long-standing relationship. Back in the days, there was this wall where developers build, and quality engineers manually check-in a waterfall manner. The testing activity back then was long, tedious and a huge bottleneck in the delivery pipeline. Time goes by and the software industry matures into a more agile manner. Small iterations of developing features were introduced, closing the gap between different roles in the team. Unfortunately, this was not enough as at the end of the day the testing activities were still at the end of each iteration. And then a whole new concept called “Shift Left Testing” came up.

Shift Left Testing is the idea of moving software testing activities to the beginning of the software development cycle by shifting it left instead of occurring at the end as it used to be. This approach is faster and more cost-effective as it avoids issues raised at later stages in the software development cycle. Issues raised by the customers on production could result in business losses, not to mention the extra cost, time, and effort to develop a fix and deliver it to the customer. While, issues raised at the earlier stage of the development cycle, can be fixed immediately with minimal cost and effort.

Shift left is the current trend of the industry demanding Quality Engineers to evolve into Software Development Engineer in Test (SDET) to be able to perform all different types of automation tests in the testing pyramid. Whereat the lowest level of the pyramid are unit tests whether Backend or UI, followed by integration tests, then end to end tests, and finally manual exploratory tests at the top level.

Quality Principles

There are many diverse approaches and views on how to best ensure high-quality software development. From dedicated teams of software quality engineers to cross-functional agile squads without specific assigned roles, from writing tests before code to offshore automation as a service. Organizations must choose from a range of approaches when deciding how to best structure teams and assign responsibilities to ensure software quality.

While the following principles encapsulate how we think about Quality, they are not prescriptive. Each project has its own requirements, technology stack, business domain, etc. and the team must accommodate the project set up to address the unique challenges facing them. Thus, the Quality Principles describe preferences but gives flexibility for the team themselves to implement the processes and approaches as they see fit. These principles are guiding stars, not commandments.

These principles represent our point of view in approaching quality but realizing them requires collaboration from the whole team. Quality is impacted by every aspect and role in the software development, so we cannot execute a quality approach without involving all the other roles in the process, from the Project Managers, Business Analysts, Software Engineers, etc. A quality approach is a team approach, not something solely conceived and executed by Quality Engineers. Each one has a role to play in implementing practices that ensures quality, we need a shared understanding of our quality approach and what it means to us as a team.

Quality Ownership

We believe that quality is the responsibility of the whole team. High-quality software delivery requires all team members to participate in ensuring the quality, responsibility for quality cannot solely fall on a single role or team member. Every member of the delivery team should know how to contribute to the product’s quality and actively execute these responsibilities. The team must feel accountable for the quality of the end product.

Organizations that delegate the quality responsibility to a “Quality Engineer” role and ask them to ensure that the end-product is production-ready before releasing to the customer cripple their ability to deliver fast, high-quality products. At best, this is their innocent, misguided way of ensuring the quality of their deliverables. At worst, it is an intentional attempt to dodge the accountability of having low-quality products by using Quality Engineer as a scapegoat when things go south, and issues are raised.

Teams that embody this principle behave differently from others, there is no “Why didn’t the QE find this issue?” or “I won’t test my code, the QE will check it for me” or “This is not my job”, etc. There is only continuous collaboration between all team members, driving them towards one goal which is delivering fast, high-quality products to the customer. It is our belief that teams that behave that way achieve more successful results and create a healthy environment for people to enjoy working together. By following this principle, the team will create a far stronger force towards quality than having a single role ever could. That said, the responsibility of the QE here is to help the team realize this principle.

Quality Engineering as a Specialty

The role of a Quality Engineer, in our opinion, is to empower teams by focusing on quality. Quality Engineers bring expertise in software testing, test automation, agile processes, CI/CD, and DevOps, among other things. Everything has an impact on software quality, and that’s why QE must have great knowledge of all aspects of software development from software design, architecture, technology stack, delivery process, etc. Quality Engineers use this expertise to derive the team towards achieving high-quality products, but they do not own it.

Quality Engineers are an integral part of the agile development team. They do not sit outside waiting for the rest of the team to release a new build to be tested. They are fully embedded into the team and work together on the product development as equals. Quality Engineers participate in all kinds of activities like building test automation frameworks, creating automated tests, pairing with developers in user stories implementation, asking customers for feedback on stories, collaborating with the business analysis team in setting the acceptance criteria for stories, and talking with business users to better understand their use cases, etc. Quality engineering is a very demanding role that requires great communication skills, great expertise, and a creative destructive mindset.

Nowadays, some organizations remove the quality roles entirely from their teams and expect developers to test their own code, basically own their code from design to production. We believe this approach works for certain organizations in specific circumstances, and we are not here to judge their approach. However, finding software engineers who also have expertise in software quality is very challenging and at the end of the day you did not remove the quality practice, you just mixed it. Allowing team members to specialize in Software Quality, in our opinion, leads to better, more productive teams.

Test Automation

Test Automation is a must if you want to achieve high quality and fast product delivery. The complexity of the software and the shift towards incremental and iterative development approaches make it practically impossible to keep pace with sluggish manual testing. To ensure that testing activities keep pace with development, test automation is a must. Lack of investment in test automation in iterative delivery will lead to a huge hindrance in product delivery.

While most organizations give priority to test automation, many of them still fail to reap the benefits of faster delivery. They start writing automated tests heads-on without thinking about the Test Pyramid (Check our Blog Post about ‘Finding the Right Balance between End to End and Unit Tests‘). Without a suitable testing strategy, requiring a team to automate X percentage or Y number of all tests can result in bloated, slow automation suites that are frequently ignored and rarely deliver value.

Test automation should be treated like any other software development project, with the same rigorous architecture reviews, code reviews, and other processes as production code. Quality Engineers work with the team to create, improve, and adjust their automation strategy according to the specifics of the technology stack and software architecture. Leading these automation approaches and defining their testing strategy is a key area of expertise that the Quality Engineers bring to the agile development teams that make a huge impact on the team’s delivery velocity.

Shift Left Testing

It is our belief that continuous collaboration between different team members is the core of successful delivery teams. ‘Shift Left Testing’ as a concept supports this belief and specifically calls out the need for development and testing activities to be inseparable. Team members collaborate in real-time without any barriers inhibiting their interaction. It means that both quality engineers and developers are collaborators rather than cogs in a production line. It means that quality is built in the product as software is developed and not something to be ensured later, at the end of a sprint or before a production release.

While we support this practice, we believe that the particular roles and responsibilities and day-to-day activities should be left to the team to have an internal agreement on what works for them. What works for a team does not necessarily have to work with other teams. In which phase should we pair as a team in the user story? Should we work using a TDD approach? Who exactly is going to write which types of tests across the testing pyramid, and when? The team should be empowered to answer all these questions and come up with an approach that best suits their needs.

Conclusion

Time is, after all, money. Remember that getting the software to market faster gives you a competitive advantage. And following the Quality Principles outlined above will ensure that you beat your competition in the market with higher-quality applications.