60 pratiques de Quality Engineering : Architecture (Part 2)

La livraison de valeur continue nécessite plus que du clean code.

L’architecture permet de structurer la technologie pour répondre aux objectifs d’aujourd’hui tout en gardant la flexibilité pour ceux de demain. C’est une exigence pour survivre dans un contexte où l’adaptation continue est la norme.

Le Quality Engineering est le paradigme contraignant la chaîne de valeur logicielle à une livraison de valeur continue agissant sur les 5 piliers de son cadre, MAMOS : Methods, Architecture, Management, Organization, Skills.

Nous avons abordé dans un précédent article le référentiel des Methods, alliant conduite du changement et pratiques qualité. Dans cet article, nous nous concentrons sur l’architecture du Quality Engineering, qui comprend la technologie.

Suivez la QE Unit pour accéder aux 60 pratiques de Quality Engineering.

Méthodologie

Ce guide est en cours de construction et sera adapté en fonction des retours d’expérience au sein du framework de Quality Engineering, MAMOS : Methods, Architecture, Management, Organization, Skills.

Chaque pratique a été classée parmi la qualité, la rapidité et la complexité par un score maximum représentant la priorité de mise en œuvre. Cet article n’est qu’un extrait, vous pouvez accéder à la hiérarchisation complète de ces pratiques ici.

L’architecture d’une transition vers le Quality Engineering

Une organisation de Quality Engineering a besoin des éléments fondamentaux d’architecture. Ils se retrouvent généralement dans les entreprises technologiques à plus forte valeur ajoutée délivrant au high standard. Mais pour atteindre leur niveau, il faut bien commencer.

Les pratiques répertoriées se concentrent sur l’accompagnement des premières transitions vers le Quality Engineering avec une maturité émergente de l’architecture. Les pratiques visent donc à poser les bases nécessaires et à soutenir le développement futur.

Les éléments d’architecture sont répartis tout au long du cycle de vie de livraison logiciel. Cela commence par des pratiques de code qui favorisent une qualité intégrée. Tout au long de la chaîne, les éléments de test et de déploiement viennent complémenter ces fondations.

Pratiques d’architecture

Content

Coding

Code repository

L’organisation du code est essentielle avant toute production de code. Essayer de construire une maison sur des fondations inexistantes ou mal conçues conduira à des réparations coûteuses et, dans le pire des cas, à un désastre. Choisir, concevoir et définir efficacement une architecture de référentiel est un pré-requis pour conduire une organisation de Quality Engineering durable.

Il existe essentiellement deux choix entre monorepo et multipo avec des variations possibles. Si vous partez de zéro, envisagez sérieusement un monorepo avec une architecture modulaire. Au fil du temps, vous pouvez évoluer en fonction de votre contexte comme Google.

Vous pouvez lire les articles suivants pour approfondir ce thème :

Bootstrap de code

Les ingénieurs logiciels doivent développer aussi rapidement que possible les fonctionnalités métier pour itérer sur la proposition de valeur. Dans le même temps, les ingénieurs qualité doivent soutenir l’équipe avec les environnements, l’automatisation et d’autres composants.

La définition de bootstraps de code réutilisable et standard dans les différents contextes d’ingénierie permet de débloquer des economies of speed & scale pour l’organisation. Vous pouvez les implémenter sur chacun des modèles de projet et des technologies intégrant les bonnes pratiques de versioning et de release.

API-driven

Un trait commun des organisations de Quality Engineering de haut niveau est de créer des services rapides et fiables. L’utilisation d’API dans les différents artefacts logiciels des équipes interfonctionnelles et d’ingénierie accélère la composition et la réutilisation des services dans l’organisation avec un effort et une synchronisation réduits.

Ce principe architectural permet à l’organisation d’évoluer plus rapidement et de fournir plus facilement l’automatisation et le libre-service. Cette capacité d’API au sein de l’organisation doit être appliquée aux services internes et externes afin de maintenir un rythme rapide d’innovation dans l’ensemble. Vous pouvez vous inspirer du mantra de l’API Amazon défini par Jeff Bezos.

Tests

Architecture de test

La conception d’un système de test efficace est essentielle pour des pratiques de test minimalistes, à la demande et modulaires en Quality Engineering. L’architecture des tests est essentielle pour répondre aux exigences de testabilité oubliées ou contournées telles que la disponibilité des données ou la prise en charge des techniques de test.

Une architecture de test consiste à organiser le référentiel de test associé au référentiel d’exigences, à définir les adhérences entre code et artefacts de test, et à identifier comment intégrer les différentes solutions d’automatisation de test. À partir de là, les ingénieurs qualité peuvent travailler à la création efficace de ces solutions.

Pour comprendre la même chose avec votre dépôt de code, vous pouvez également lire cet article Vous pouvez surmonter le dilemme du repo de tests.

Bootstrap de test

De la même manière que les bootstraps de code, une organisation de Quality Engineering bénéficiera à l’équipe en fournissant des composants de test réutilisables par typologie. Ils permettront aux équipes transverses de mettre en œuvre rapidement le test minimal tout en simplifiant le travail de support et de maintenance des ingénieurs qualité.

Nous avons tous rencontré des projets avec des tests unitaires commentés. La valeur des bootstraps de test fiables est d’éviter cette situation en fournissant des capacités de test unitaire intégrées ainsi que des tests automatisés dans les pipelines CI/CD. Cet effort de configuration difficile pour les ingénieurs logiciels est donc supprimé lors des itérations métier, ce qui fait une différence pour le Quality at Speed.

Quality Gates

La meilleure façon de s’assurer que les tests sont exécutés est d’en faire une partie intégrante du processus de livraison du logiciel. Les Quality Gates sont un moyen systématique de déclencher des tests et d’arrêter le déploiement en fonction de critères spécifiques dans un pipeline de déploiement. Ils peuvent être actifs depuis l’environnement de développement jusqu’à celui de production avec des déploiements progressifs que nous verrons par la suite.

Les Quality Gates ne peuvent démarrer qu’avec des tests unitaires, puis ajouter des gates d’automatisation de sécurité, de qualité du code et de test dans chaque environnement jusqu’à la production. Cette pratique est très efficace avec les code bootstraps et bootstraps de test en utilisant des intégrations de test natives dans les fondations CI/CD.

Déploiement

Fondations de CI/CD

L’équipe a besoin d’automatiser le pipeline de build, de déploiement et de publication. Le produit, l’équipe et la technologie peuvent changer, mais fournir des modèles CI/CD sont des fondations indispensables pour les équipes. Ils peuvent se concentrer sur la construction du produit avec qualité tandis que les ingénieurs qualité peuvent les améliorer en parallèle par la suite.

Ce pipeline peut garantir le nombre d’environnements utilisés par l’application, les tests effectués via Quality Gates et prendre en charge le déploiement progressif. De plus, cette normalisation vous aide à mesurer les pratiques plus avancées telles que le value stream. Vous devez sécuriser ces fondations pour tous ou au moins les principaux projets utilisés.

Déploiement progressif

La meilleure façon de valider une hypothèse est de la tester. Les équipes produits vont donc beaucoup pousser à l’expérimentation de fonctionnalités pour tester des idées. Mais faire cela sur l’ensemble des utilisateurs alors que le produit n’est pas encore à un bon niveau de qualité est dangereux pour l’entreprise.

Les déploiements progressifs sont le moyen de découpler le déploiement et la publication de l’application avec divers modes tels que Dogfooding, Canary Release, A/B testing. Le déploiement progressif est mieux déployé avec les fondations CI/CD et des Quality Gates.

Pipeline d’observabilité

L’équipe a besoin d’observabilité pour prendre en charge la mesure, la résolution de problèmes et l’amélioration continue du produit. La création d’un pipeline d’observabilité dès le départ garantit que cette exigence ne sera pas manquée. Au fil du temps, l’équipe améliorera la couverture et les capacités d’observabilité en fonction de leurs besoins et de leurs rétrospectives.

Framework

Ces pratiques vous prépareront à un parcours de transformation vers une organisation de Quality Engineering. Les pratiques vous aideront à maintenir une amélioration et une adaptation continues avec des capacités, des processus systématiques et un apprentissage organisationnel.

Ce contenu se concentre sur le domaine de l’architecture, laissant les pratiques des méthodes, de la gestion, de l’organisation et des compétences dans un domaine séparé. L’objectif est de l’enrichir au sein de la communauté et d’améliorer son contenu.

Vous pouvez accéder au framework complet de Quality Engineering contenant le classement des pratiques en termes de qualité, de vitesse et d’effort. Il contient une option pour personnaliser la priorité de certaines pratiques et vous laisse déjà avec un plan d’action.

Suivez la QE Unit pour plus de Quality Engineering.

La définition, le manifeste et le framework de Quality Engineering sont disponibles sous le Creative Common Attribution-NonCommercial-ShareAlike 4.0 International (CC BY-NC-SA 4.0).