Par Julie Papineau: Experte en génie logiciel et formatrice chez Zentelia
30 août 2024
Des acronymes en TI, il y en a pour les fins et les fous. Démystifions ensemble certains acronymes entourant la qualité logicielle.
Ayant eu le privilège de travailler avec de nombreuses équipes dans différentes entreprises, je suis régulièrement témoin de la confusion qui peut naître des perceptions divergentes d’un même terme. Les expériences vécues par chaque employé viennent teinter notre compréhension des termes. Il est donc vraiment important de se doter d’une base terminologique commune.
Commençons par un acronyme tout simple… QA (AQ), signifiant assurance qualité. Ce terme est utilisé tant pour désigner un rôle spécifique au sein de l’équipe (comme le QA de l’équipe) que pour faire référence à la discipline générale de l’assurance qualité. Lorsque les équipes parlent de QA, c’est malheureusement souvent associé au membre de l’équipe qui exécute les tests. L’ISTQB (International Software Testing Qualification Board) décrit l’assurance qualité (QA/AQ) comme étant des « activités visant à donner confiance dans le fait que les exigences de qualité seront satisfaites ». Lorsque nous parlons d’assurance qualité, nous faisons référence à un ensemble de pratiques, de méthodologies et de processus mis en place pour garantir que le produit répond aux exigences implicites et énoncées ainsi qu’aux normes de qualité. QA est l’approche préventive axée sur les processus. Pensez ici à tout ce que vous pouvez mettre en place pour prévenir la découverte de défauts plus tard dans votre cycle de livraison (par exemple, lors des tests). Politique qualité, stratégie, planification, monitoring et contrôle, y compris les métriques et tableaux de bord, révision de documentation en amont… Toutes des activités pouvant être prises en considération afin de prévenir l’introduction de défauts dans le code.
Afin de faciliter la suite de votre lecture, je vais plutôt utiliser le terme « analyste qualité » lorsque je fais référence au membre de l’équipe, afin d’éviter toute confusion avec l’acronyme QA. L’analyste qualité participe, entre autres, à l’exécution des tests. Cette activité fait partie du QC, contrôle de la qualité. Défini par l’ISTQB comme étant des « activités destinées à évaluer la qualité d’un composant ou d’un système », le QC est une approche de détection et de correction orientée vers le produit. Les tests, dans toutes leurs déclinaisons, sont certainement un élément central, tout comme le prototypage et la simulation. Faire du QC, c’est donc faire du QA. Certes! Toutefois, les activités qui ne font que « trouver » des défauts feront ralentir votre cycle de livraison et seront perçues comme un goulot d’étranglement. C’est pour cette raison que la QA et les activités citées plus tôt ont une grande importance.
Et vous? Où vous situez-vous entre la QA et le QC dans vos projets? Plusieurs équipes font appel à leur analyste qualité afin d’exécuter les tests une fois que quelque chose est prêt (QC). Certaines autres vont impliquer leur analyste qualité pour réviser les critères d’acceptation (QA).
Aujourd’hui, la société en général est plus exigeante et moins patiente. Tout va plus vite et au travail, tout doit être livré rapidement également. En TI, l’agilité a instauré le principe de fournir de la valeur rapidement aux clients. Ceci nous permet de nous réajuster si le tout ne répond pas bien aux attentes. Le DevOps a ensuite émergé, afin de répondre à certains défis entre développement et opérations. Le souhait de plusieurs entreprises est d’offrir aux utilisateurs les nouveautés en temps réel. Bien que la pression pour accélérer les délais de livraison ait augmenté, les activités entourant la qualité du produit n’ont pas toujours évolué en conséquence. Il est encore commun de se préoccuper de la qualité à la fin d’une étape ou du projet.
Revenons à l’acronyme QA. Cette fois, je vous propose assistance qualité comme définition, au lieu d’assurance qualité. Une subtilité, me direz-vous. Tout à fait! Mais une subtilité qui démontre clairement le changement de garde que doivent prendre les analystes qualité et toute l’équipe de livraison. Je dois la découverte du terme assistance qualité à Atlassian, il y a déjà 9 ans, dans cette vidéo.
Dans un cycle de livraison à haute vitesse, les analystes qualité et testeurs doivent absolument évaluer les répercussions de leurs activités sur le temps de livraison. Ils ne peuvent plus se donner des semaines et des mois pour veiller à ce qu’aucun souci ne gêne les utilisateurs.
« La qualité est la responsabilité de tous. » C’est un mantra que vous avez certainement déjà entendu et il est peut-être même utilisé dans votre équipe. Les dernières décennies ont cependant montré que seuls les analystes qualité sont qualifiés pour s’assurer que le produit est prêt à être utilisé, contrairement aux développeurs et autres professionnels du secteur. C’était vrai il y a 20 ans lorsque les projets étaient gérés en mode cascade qu’on livrait deux fois par année. Que le testeur soit le seul à confirmer est malheureusement une fausse croyance qui perdure, et ce, à tous les niveaux de gestion. Le plus gros défi des analystes qualité sera de briser cette croyance.
La meilleure position à adopter par les analystes qualité est de se concentrer à offrir de l’aide et du soutien à l’équipe qui assure la qualité. Il est important d’assister plutôt que d’assurer, car ce dernier terme évoque davantage un rôle de contrôleur ou de policier. Les analystes qualité devraient agir et être perçus comme un responsable de produit (PO), le produit étant la qualité. Ils doivent s’assurer que les critères d’acceptation, de vérification et de validation du produit sont également inclus dans les récits. Pensez non seulement à l’aspect fonctionnel, mais aussi aux critères de performance, de sécurité et d’utilisabilité. L’objectif principal est de tout mettre en place AVANT le début du développement et de s’assurer que chacun partage une vision alignée du travail à réaliser. L’analyste vient donc assister son équipe en préparant le tout. L’équipe de développement a donc tout en main pour livrer ce qui est entendu… y compris les tests. Ici aussi, les analystes qualité peuvent assister leur équipe en définissant la stratégie de test, les attentes concernant l’automatisation des tests, les jeux de données, et autres éléments à fournir avec le code. L’analyste qualité doit régulièrement interroger son équipe pour identifier leurs préoccupations concernant leur rôle dans la vérification et la validation. Il doit ainsi agir en tant que coach, formant les membres de l’équipe pour renforcer leurs compétences en matière de qualité, afin qu’ils puissent assumer ces responsabilités eux-mêmes plutôt que de les déléguer.
J’entends déjà certains membres de l’équipe se demander quel sera le rôle de l’analyste qualité s’il ne réalise plus tous les tests. En réalité, entre autres responsabilités, l’analyste continuera de les soutenir en assurant la qualité des récits et de la documentation, en rédigeant des cas de test pour renforcer la confiance de l’équipe, en préparant des jeux de données, en explorant pour réduire les risques, en trouvant les requis implicites qui ne fonctionnent pas correctement, en participant à la gestion des incidents, et en contribuant à l’amélioration continue grâce à des métriques… Et j’en passe!
Il est temps de passer de l’idée que "le QA doit tester" à celle où "le QA aide l’équipe à avoir confiance en leurs tests". Si vous utilisez ou entendez encore cette expression, je vous encourage à revoir votre lexique d’équipe et à évoluer d’une approche d’assurance qualité vers une approche d’assistance qualité.
Faites appel à notre expertise pour découvrir comment vous pouvez, vous aussi, adopter une approche renforcée de vos pratiques d'assurance qualité. Écrivez-nous!
Comments