TechLadder Corporation
Menu
Facebook-f Twitter Linkedin-in Youtube Instagram
Challenges of Quality engineering 1 scaled

Fundamentals of Quality Engineering

In this article, the Slalom Build Quality Engineering team will discuss our Quality Engineering Fundamental Concepts. We use these principles to illustrate and discuss how we believe software development should be conducted to ensure quality. Now that we’ve established them as an essential component of our delivery strategy, we’d like to disseminate them extensively. We hope that you find them instructive and that they stimulate discussion on the topic of producing high-quality, contemporary software.

Why are Fundamental Principles So Crucial?

The Quality Engineering Core Principles of Slalom Build, at their most fundamental, delineate and explain how we think about quality. These four principles articulate our perspectives on quality and our preferred methods for achieving it. We believe that adhering to these principles enables us to develop superior software with more predictable outcomes compared to all alternative approaches. 

There are numerous, widely divergent viewpoints on how to ensure the high quality of modern software. From dedicated teams of test specialists to self-organizing agile modules with no defined responsibilities, from tests-before-code to offshore automation-as-a-service, development firms must choose from a variety of software quality assurance strategies. Several of these methods are incompatible, so each organization must choose which one to employ expressly.

Although the fundamental principles represent our core values, they are not enforceable. Each project, technological framework, domain, and team’s inherent problems must be modified. Consequently, the main principles define preferences while allowing practitioners the flexibility to implement procedures and techniques as necessary. Our ideals are not mandates, but rather beacons.

These essential concepts were developed to express our perspective, but putting them into practice requires collaboration. We cannot establish or implement a quality plan without the participation of all other roles, including software engineers, program managers, DevOps engineers, business analysts, and so on. A quality approach is not something that is designed and implemented solely by Quality Engineers. Before each of these organizations can employ quality-assured procedures, we must concur on what quality means to us individually.

Collective Team Ownership

We believe in collective ownership of quality. Effective, high-quality software delivery requires teamwork; the quality cannot be designated to a single position or individual. Every member of a software team must feel accountable for the quality of the deliverable, comprehend how they contribute to that quality, and carry out their responsibilities with vigor and enthusiasm. 

Companies that outsource or concentrate quality responsibilities on a “Quality Assurance” position and require QA to guarantee or certify product codes prior to release limit their ability to produce quality goods. This delegation is, at best, a sincere but misguided effort to ensure quality. At worst, it is an attempt by organizational leadership to avoid responsibility by shifting blame to Quality Assurance when problems arise. In contemporary software development, we do not believe that individual quality ownership is ever a viable strategy.

Teams that exemplify the concept of full team ownership conduct differently, and it is extremely impactful to observe these teams in action. There is no “it’s not my job,” no flinging code over the wall, no sub-optimization of “my” unique duty, and no “why didn’t QA notice this???”; rather, there is profound and ongoing cooperation amongst all team members in pursuit of a common goal. Teams that behave in this manner generate a force for excellence that is significantly more powerful and pervasive than any single position or individual. In all of our development initiatives, we strive for this type of team-ownership culture.

Enabling Teams

We believe in the Quality Engineer’s responsibility to empower teams by concentrating on quality. Quality Engineers provide expertise in areas such as test automation, quality assurance, agile procedures, and CI/CD. If this seems excessive, it is! Since everything has the potential to affect quality, a Quality Engineer must be well-versed in all software delivery domains and their relationship to quality. Quality Engineers advocate, evangelize, influence, and promote quality, but they do not own it (core principle number one!). 

Every agile development team requires engineers of high caliber. They are not a separate team that seats separately or with the other members of the group. They are incorporated into the team and collaborate on the development project as equals. When examining one of these development teams, you will find Quality Engineers constructing automation frameworks, collaborating with developers on story implementation, providing feedback on story acceptance criteria (ACs) and testability, and conversing with users to better comprehend use cases. The Quality Engineer has a challenging job that requires technical knowledge, excellent communication skills, user empathy, and a “creatively destructive” mindset.

There are modern software delivery techniques that eradicate quality responsibilities entirely and require developers to own code from concept to production. We do not believe that these strategies are erroneous or misguided, as they are effective for some businesses in certain situations. On the other hand, it might be challenging to locate developers who are also Quality Engineering specialists. Enabling team members to specialize in Quality Engineering results in teams that are inherently more potent and successful. Additionally, quality may be outsourced to other groups or organizations. We categorically oppose any variants of these tactics (see third fundamental principle). In our modern, agile software development methodology, the best results are achieved by a Quality Engineer who is a dedicated member of each development team.

The Worth of Proximity

We believe that proximity between the development and testing departments is advantageous. Since the majority of delivery models separate development and testing, we emphasize the need for direct contact between development and testing operations. This division hinders an organization’s ability to produce high-quality results. 

Proximity does not necessarily imply physical proximity; it simply means that development and testing activities are performed simultaneously (virtually) by members of the same, small team who collaborate in real time with no process, technological, or other barriers impeding their interaction. This implies that Developers and Quality Engineers are not merely components in a machine, but rather co-creators of deliverance. It implies that quality is integrated into the program from the beginning, as opposed to being tested subsequently, prior to a release, or at the end of a sprint. Quality activities are a crucial element of development.

In what manner does this manifest itself? It appears that Quality Engineers are participating in code evaluations and merge requests. Developers appear to be creating tests (of all types!) as part of the story-creation procedure, typically in tandem with a Quality Engineer. Quality Engineers appear to be assessing architectural blueprints for testability and discussing extreme situations and any negative repercussions with Developers and Product Owners during user story refinement. All of these measures contribute to the incorporation of quality into development by bringing together the development and testing processes.

We believe that the precise duties and responsibilities of team members, as well as their day-to-day conduct, should be left to the team’s discretion, despite our preference for intimacy. There are numerous ways to achieve close proximity. Is TDD required? Should story combinations be encouraged or mandated? When and who composes which types of examinations? Each team is tasked with answering these questions and developing a solution that works for them.

Any strategy that isolates development and testing reduces the efficiency and effectiveness of both, as well as a team’s capacity to produce quality work. We are always searching for ways to improve our current processes so that development and testing can occur simultaneously.

Importance of Automation

Automation is required for rapid, high-quality delivery. The exponential rise in software complexity, coupled with the transition to iterative and incremental deployment methods, makes manual testing impractical for maintaining velocity. Automation is required for validation to keep pace with development. Failure to invest in test automation throughout iterative delivery will result in a Regression Death Spiral. 

Despite the fact that some businesses promote test automation, many fail to recognize the benefits of increased productivity. Simply automating testing with code does not guarantee any benefits. In the absence of adequate planning and consideration, requiring a team to automate X number or Y percent of all tests results in unwieldy, lethargic automation suites that are frequently ignored and rarely generate value.

Test automation must be regarded as a type of software engineering and subjected to the same rigorous processes (design reviews, code reviews, linting, etc.) as product development. Quality Engineers collaborate with the team to design and refine an automation strategy suited to the software architecture and technology infrastructure. Quality Engineers contribute essential skills to development teams by recognizing this challenge and promoting automation solutions that increase velocity.

Conclusion

These four guiding principles define our strategy for attaining software development quality. This is not the only method to consider quality; many successful software companies consider it differently, which is acceptable. Our development process has been established and enhanced over the course of many years of delivering software to hundreds of customers. All of them derive from or are influenced by corporations or individuals who have expressed their own views on quality. They are not perfect, exhaustive, or conclusive; rather, they serve as jumping-off points for more in-depth discussions about the difficult task of ensuring quality in modern software delivery. We strive to attain them with every delivery, but our knowledge and business are constantly expanding. What is effective today may not be effective tomorrow, but adapting to the next challenge is half the fun. 

Each essential idea necessitates considerably more consideration than can be provided here. However, we trust that the preceding introduction has provided you with a sense of who we are, what we stand for, and how we approach the challenging problem of developing high-quality modern software. Eventually, we hope to provide a more comprehensive and in-depth discussion of each fundamental concept. For more information, please visit our website or contact our specialists directly.

Contact Us