Quality Engineering Core Principles

Based on our experience, we have established our principles – a set of delivery methodologies. Since it proves to be efficient, we hope you find it informative and helpful for delivering modern software with quality.

Why core principles?

These three principles express our perspectives on and preferred methods for achieving quality. Out of all competing philosophies, we believe that adhering to these principles helps us deliver higher quality software with more predictable results.

There are many widely differing perspectives on best-ensuring quality when developing modern software. Development organizations must choose from various approaches when deciding how to best structure teams, sequence tasks, and assign responsibilities to ensure software quality, ranging from dedicated test specialists to self-organizing agile pods without assigned roles, from tests-before-code to offshore automation-as-a-service. Many of these approaches are incompatible, and any organization must explicitly decide which one to use.

While our core values are encapsulated in the core principles, they are not prescriptive. The specific requirements of each project, technology stack, domain, and team necessitate customization to address the situation’s unique challenges appropriately. As a result, the core principles describe preferences while still allowing practitioners to implement processes and approaches as needed. Our principles are not commandments but rather guiding lights.

We defined these core principles to capture our point of view, but putting them into action requires teamwork. Because all aspects of software development impact quality, we cannot define or implement a quality strategy without the participation of all other roles — Software Engineers, Program Managers, DevOps Engineers, Business Analysts, and so on. A quality approach is a collaborative effort, not conceived and implemented solely by Quality Engineers. For each of these groups to effectively implement quality-assured practices, we must first agree on what quality means to us.

Whole Team Ownership

We believe in quality ownership by the entire team. Successful, high-quality software delivery necessitates the full participation of the whole group; the quality cannot be delegated to a single role or person. Every software team member must feel accountable for the deliverable’s quality, understand how they contribute to that quality, and actively and enthusiastically carry out those responsibilities.

Organizations that delegate or centralize quality responsibility to a “Quality Assurance” role and ask QA to guarantee or certify product code before release cripple their ability to deliver quality. At best, this delegation is a well-intended but misguided strategy to achieve some level of quality assurance. At worst, it is an intentional attempt by organization leadership to avoid accountability by using Quality Assurance as a scapegoat when problems arise. We do not believe that siloed quality ownership is ever a viable strategy in modern software development.

Empowering Teams

We believe in the role of a Quality Engineer, whose job it is to empower teams by focusing on quality. Quality Engineers are experts in test automation, quality assurance, agile processes, and continuous integration and delivery, among other things. This may appear to be a lot, and it is! Because everything can impact quality, a Quality Engineer must understand all aspects of software delivery and how they relate to quality. Quality Engineers champion, evangelize, influence, and advocate for quality, but they do not own it.

Quality Engineers are an essential component of any agile development team. They are not a separate team that sits outside or alongside the group; instead, they are integrated and collaborate as equals in the development effort. Investigate one of these development teams. Quality Engineers will build automation frameworks, collaborate with developers on story implementation, provide feedback on story ACs and testability, and talk with users to better understand use cases. The Quality Engineer has a difficult job requiring engineering knowledge, good communication skills, user empathy, and a “creatively destructive” mindset.

Quality techniques in modern software delivery eliminate quality responsibilities and expect developers to own code from concept to production. These tactics work for companies in specific circumstances, and we do not believe they are incorrect or misdirected. Finding developers who are also experts in Quality Engineering, on the other hand, is difficult. Allowing team members to specialize in Quality Engineering naturally results in more powerful, successful teams. Some techniques delegate quality to outside teams or organizations. We are categorically opposed to all variants of these techniques. A dedicated Quality Engineer that works as an integrated part of every development team produces the greatest results in our modern, agile software development technique.

Value of Proximity

We believe that closeness between development and testing operations is advantageous. Success in software development necessitates efficient collaboration among all team members; nonetheless, we emphasize the importance of proximity between development and testing activities because many planned delivery techniques split development and testing. This isolation impairs a team’s capacity to generate high-quality results.

Proximity does not necessarily imply physical proximity; it simply means that development and testing activities are carried out simultaneously (virtually) by members of the same, small team who collaborate in real-time with no barriers (process, technological, or otherwise) impeding their interaction. It means that Developers and Quality Engineers are co-creators of a deliverable rather than components of an assembly line. It means that quality is integrated into software as it is created, rather than verified later, before a release or at the end of a sprint. Quality activities are both a component of and inextricably linked to development.

What does this look like in practice? It seems like Quality Engineers are participating in code reviews and merge requests. It seems like Developers are writing tests as part of story development, often alongside or in collaboration with a Quality Engineer. It looks like Quality Engineers are reviewing architecture plans for testability and talking through edge cases and possible adverse impacts with Developers and Product Owners during user story refinement. These activities mix quality into development, bringing dev and test activities into proximity.

Any method that diminishes the proximity of development and testing operations reduces their efficiency and effectiveness and negatively influences a team’s ability to produce quality. We are always critiquing our current procedures and looking for ways to improve them so that development and testing are as close as possible.

Conclusion

These basic concepts outline our approach to achieving quality in software development. The concepts have shown to be effective for us and our development process, which has been derived and refined over years of software delivery with hundreds of clients. None of them are original ideas; they are all taken from or influenced by companies or individuals who have expressed their views on quality. 

They are not flawless, exhaustive, or final but rather serve as beginning points for lengthier, more in-depth discussions about the complicated task of assuring quality in modern software delivery. We aim to achieve them in every delivery endeavor, but our understanding is constantly expanding, and our industry is continually changing. What works today may not work tomorrow, but preparing for the next challenge is half the pleasure.