Continuous value delivery requires more than clean code.
Architecture enables to structure the various technological elements to meet today’s goals while keeping flexibility for the ones for tomorrow. It is a requirement to survive in a context where continuous adaptation is the norm.
Quality Engineering is the paradigm constraining the software value-chain to continuous value delivery acting on the 5 pillars of its framework, MAMOS: Methods, Architecture, Management, Organization, Skills.
We cover in a previous article the Methods referential, combining change management and quality practices. In this article, we focus on the Architecture of Quality Engineering, that includes the technology elements.
Follow the QE Unit to access the 60 practices of Quality Engineering & more.
This guide is a work-in-progress to be adapted based on the feedback and likely to evolve within the Quality Engineering Framework, MAMOS: Methods, Architecture, Management, Organization, Skills.
Each practice has been ranked among Quality, Speed and Complexity by maximum score representing the implementation priority. This article is only an excerpt, you can access full prioritization of these practices available here.
The Architecture of a Quality Engineering Transition
While a Quality Engineering organization focuses on less technical aspects, fundamental architecture elements are commonly found at the most valuable tech companies achieving a high level of quality. But to reach their level, you have to start somewhere.
The listed practices focus on supporting the first transitions to Quality Engineering with an emerging maturity of architecture. The practices are therefore aiming at setting the necessary foundations at that stage and for future development for any technological ecosystem.
The most valuable Architecture elements are divided along the software delivery lifecycle. It starts with coding practices that foster a built-in quality structure. Going along the chain, concrete technological elements of testing and deployment are core building blocks.
The organization of the code is essential before any coding takes place. Trying to build a house on inexistent or badly designed foundations will lead to costly rework and in worst cases, a disaster. Effectively choosing, designing, and setting a repository architecture is a must-have to drive a sustainable Quality Engineering organization.
There are essentially two choices between monorepo and multipo where possible variations exist. If you are starting from scratch, seriously consider a monorepo with a modular architecture. Over-time, you can evolve depending on your context like Google or Airbnb.
You can read the following articles to deep dive in this theme:
- The Epic Story of Mono vs. Multi-Repo is Not New
- The Hands-on Mainstream Repo Models You Need To Know
- The 6 Popular Old Myths about Mono and Multirepo Explained
- Mono or Multirepo: It’s All About Quality Engineering
- The 7 Fundamentals Tooling to Empower Your Repository
Software engineers have to develop as fast as possible the business features to iterate on the value proposition. At the same time, the quality engineers have to support the team with environments, automation, and other components.
Defining a standard reusable bootstrap of code in the different engineering contexts unlock economies of speed and scale to the Quality Engineering organization. You can implement them by project templates and technologies embedding good practices of versioning and release.
A common trait of high-performing Quality Engineering organizations is to create services with speed and reliability. The use of APIs in the different software artifacts of the cross-functional and engineering teams accelerates the composition and reuse of services in the organization with reduced effort and synchronization.
This architectural principle enables the organization to scale faster and provide more easily automation and self-service. This capability of API within the organization should be applied for both internal and external services to keep a fast pace of innovation overall. You can get inspired from the Amazon API mantra set by Jeff Bezos.
Designing an effective testing system is essential for minimalist, on-demand, and modular testing practices in Quality Engineering. Architecturing for testing is essential to meet the forgotten or bypassed testability requirements such as data availability, test techniques support.
A testing architecture consists of organizing the test repository associated with the requirements referential, defining the adherences between code and test artifacts, and identifying how to integrate the different test automation solutions. From there, Quality Engineers can work on effectively building these solutions.
To understand the like with your code repo, you can also read this article You Can Overcome The Test Repo Dilemma. Now.
Similarly to the coding bootstraps, Quality Engineering organizations will benefit from providing reusable test components by typology to the team. They will enable the cross-functional teams to quickly implement the minimal test while simplifying the work of support and maintenance of quality engineers.
We have all encountered projects with commented unit tests. The value of reliable testing bootstraps is to avoid this situation by providing built-in unit testing capabilities as well as automated tests within CI/CD pipelines. This setup effort that is hard for software engineers is therefore removed during the business iterations, making a difference for Quality at Speed.
The best way to ensure tests are run is to make them an integral part of the software delivery process. Quality Gates are a systematic way of triggering tests and stopping the deployment based on specific criteria in a deployment pipeline. They can be active from the development environment up to the production ones with gradual deployments we will see thereafter.
Quality Gates can start only with unit test gates, to then add security, code quality, and test automation gates in every environment up to production. This practice is very effective with coding bootstrap including the gates by default, testing bootstrap with native testing integrations within the CI/CD foundations.
The team needs automation of the build, deployment, and release pipeline. The product, team, and technology can change but providing templates CI/CD are must-have foundations for the teams. They can focus on building the product with quality while quality engineers can improve them in parallel afterward.
This pipeline can ensure the number of environments used by application, the testing performed through Quality Gates, and support progressive deployment. Additionally, this standardization helps you gain measurement for more advanced practices like value stream. You need to secure these foundations for all or at least the main projects used.
The best way to validate an hypothesis is by testing it. Product teams will therefore push a lot for features experimentation to test ideas. But doing that on the full scope of users while the product is not yet at a good level of quality is dangerous for the company.
Progressive deployments are the way to decouple the deployment and release of the application with various modes like Dogfooding, canary release, A/B testing. Progressive deployment is best deployed with CI/CD foundations and automated Quality Gates.
The team requires observability to support measurement, problem-solving and the continuous improvement of the product. Creating an observability pipeline from the start ensures that this requirement will not be missed. Over-time, the team will improve the observability coverage and capabilities depending on their needs and retrospectives.
These practices will set you up for a journey in transforming to a Quality Engineering organization. The practices will support you in maintaining continuous improvement and adaptation with capabilities, systematic processes and organizational learning.
This content focuses on the domain of Architecture, letting the practices of Methods, Management, Organization & Skills in a separate area. The objective is to enrich it within the community and improve its content.
You can access the full Quality Engineering Framework containing the rank of the practices across Quality, Speed and Effort. It also contains an option to customize the priority of certain practices and already leave you with an action plan.
Follow the QE Unit for more Quality Engineering.
The Quality Engineering Definition, Manifesto and Framework are available through a Creative Common Attribution-NonCommercial-ShareAlike 4.0 International (CC BY-NC-SA 4.0).