QA

L'assurance qualité regroupe les pratiques visant à garantir qu'un produit réponde à ses exigences et fonctionne correctement. Elle englobe les processus, les normes et les activités qui produisent la qualité, et non seulement celles qui vérifient son absence. La distinction avec le contrôle qualité, qui consiste à inspecter le produit fini, est plus qu'une simple question de terminologie : l'assurance qualité vise à prévenir les défauts, tandis que le contrôle qualité vise à les détecter.

L'organisation traditionnelle, où une équipe distincte teste le travail finalisé lors d'une phase séparée avant sa mise en production, présente des faiblesses bien documentées. Les défauts sont découverts longtemps après leur introduction, lorsque le contexte est oublié et que le coût de correction est maximal. Le délai entre la programmation et les tests signifie que les développeurs ne reçoivent aucun retour d'information rapide sur leurs propres erreurs. Enfin, la responsabilité de la qualité est transférée à un groupe qui n'a aucun contrôle sur le processus de production.

Les pratiques modernes répartissent les responsabilités au lieu de les concentrer. Les développeurs intègrent des tests automatisés au processus de compilation, les revues de code permettent de détecter les problèmes avant leur déploiement en environnement de production, l'intégration continue effectue une vérification à chaque modification et les spécialistes qualité se concentrent sur la stratégie de test, les tests exploratoires et les domaines non automatisables. Le rôle du spécialiste consiste désormais à faciliter et à concevoir la vérification plutôt qu'à l'exécuter intégralement.

La pyramide de tests décrit une distribution judicieuse de la vérification automatisée. Une large base de tests unitaires s'exécute rapidement et identifie précisément les défaillances. Une couche plus restreinte de tests d'intégration vérifie la compatibilité des composants. Une couche supérieure, plus étroite, de tests de bout en bout, simule des parcours complets à travers le système réel. Inverser cette approche, en s'appuyant fortement sur des tests de bout en bout lents et fragiles, produit des suites de tests qui prennent des heures à s'exécuter, échouent de manière imprévisible et finissent par être ignorées.

Les tests exploratoires demeurent essentiels et sont souvent sous-estimés dans les organisations axées sur l'automatisation. Les tests automatisés vérifient que le comportement spécifié fonctionne toujours ; ils ne peuvent pas détecter qu'un flux est confus, qu'un message d'erreur est inutile, qu'une combinaison non envisagée produit un résultat absurde, ou qu'une modification a aggravé la situation d'une manière non couverte par les assertions. Une investigation manuelle approfondie permet de déceler des catégories de problèmes qu'aucune suite de tests ne détectera.

Les obligations de qualité vont bien au-delà du simple bon fonctionnement. L'accessibilité, les performances en conditions réelles, la sécurité, le comportement sur les appareils et connexions réellement utilisés par le public cible, ainsi que la correction du traitement des données sont autant d'attributs de qualité. Les organisations qui ne vérifient que le fonctionnement proposent des produits qui marchent correctement, mais qui ne répondent pas aux besoins d'une part importante de leur public.

La gestion des données de test est une contrainte peu attrayante qui détermine la faisabilité pratique de ces objectifs. Des données réalistes sont nécessaires pour identifier des défauts réels, tandis que les données de production sont souvent inutilisables directement en raison des obligations de confidentialité. De plus, des données synthétiques trop propres masquent précisément les problèmes qu'il convient de détecter. Constituer un stock de données de test représentatives et conformes est généralement une condition préalable à une vérification pertinente, et non un simple détail.

L'argument économique en faveur de la prévention est bien établi. Le coût de correction d'un défaut augmente fortement avec le temps nécessaire à sa découverte : il est négligeable lorsqu'il est détecté en phase de développement et devient substantiel lorsqu'il est découvert en production, où il engendre également des coûts opérationnels et des atteintes à la réputation. Investir dans la détection précoce se justifie donc par le seul critère du coût, indépendamment de l'impact sur l'expérience client.

La qualité étant déterminée par la manière dont le travail est produit plutôt que par le résultat final, les bonnes pratiques doivent être mises en œuvre dès la phase de production et non après. En pratique, cela se traduit au sein même de l'entreprise. le développement de produits dans le cadre de la définition de « terminé », les critères d'accessibilité et d'expérience étant tirés de Audit UX les normes et les seuils de performance de performances web budgets, afin que ce qui est vérifié corresponde à ce que le produit doit réellement fournir.