La QA vient supporter l’équipe tech pour assurer que les évolutions en cours de développement et récemment déployés ne viennent pas perturber l’application. Découvrez comment les méthodes Shift-Left et Shift-Right viennent se complémenter pour assurer un bon niveau de qualité.
Dans l’ingénierie logicielle, le niveau de qualité d’un produit est rarement le fruit d’une parfaite exécution des développements. Peu importe le niveau d’expertise des développeurs et leurs bonnes pratiques, le développement logiciel vient avec son lot de bugs et de comportements inattendus.
La Quality Assurance (QA) est une bonne pratique dans la production d’un logiciel qui consiste à venir s’assurer que le produit répond bien aux attentes du Product Owner.
Avec l’adoption croissante de l’agilité au sein des équipes de développement, le processus de QA se retrouve, dans la plupart des entreprises, intégré à la feature team à travers des ressources, des pratiques et des outils permettant de contrôler les risques inhérents au développement et son intégration au sein d’écosystèmes complexes.
Là où l’équipe de développement porte la responsabilité d’écrire et de maintenir des tests unitaires, les tests fonctionnels, les tests d’intégrations et les tests end-to-end relèvent du domaine des QA analysts. S’appuyant sur les spécifications fournies par le Product Owner, les QA vont concevoir des scénarios de tests qui pourront être exécutés manuellement ou, dans un second temps, automatisés.
Chez Shippeo ces scénarios de tests sont écrits en suivant la syntaxe Gherkin et sont dans la mesure du possible fournis aux développeurs avant qu’ils ne démarrent le développement de la fonctionnalité. Qu’il s’agisse de tests fonctionnels, de tests d’intégration ou de tests end-to-end, les mêmes scénarios Gherkins seront utilisés. Certains tests peuvent être automatisés, d’autres ne seront exécutés que dans le cadre de campagnes de tests manuelles. L’automatisation fait l’objet d’une stratégie à part entière.
Dans une organisation qui comprend plusieurs équipes de développement, il est fréquent d’avoir des interdépendances entre les différents services.
Les équipes sont, le plus souvent, organisées de telle sorte à ce qu’elles puissent avancer indépendamment les unes des autres bien que les problèmes de dépendance existent toujours. Les tests fonctionnels au sein de la CI vont devoir faire abstraction du reste du monde par exemple en mockant les autres services. En effet, avant l’étape d’intégration un test en échec doit être révélateur d’un problème situé au niveau de l’équipe concernée.
En revanche, les tests d’intégrations vont chercher à tester plusieurs services et s’assurer de leur bon fonctionnement une fois qu’ils travaillent de concert. Ils feront l’objet d’une campagne propre qui couvrira à la fois les nouvelles features et une partie de la non-régression impactée par les nouveaux développements. C’est une étape qui demande une excellente connaissance fonctionnelle et de l’environnement pour être efficace et pertinente.
Comme son nom l’indique, les tests end-to-end ont pour but de tester le bon fonctionnement complet d’une feature, sur l’ensemble des briques qui la composent. Ces tests sont exécutés manuellement ou automatiquement et vont demander effort certain de préparation. Les nouvelles fonctionnalités développées peuvent rendre une partie de la campagne de non-régression obsolète ce qui nécessite une nouvelle étude de celle-ci.
Ces tests d’intégrations et end-to-end sont coûteux en termes de temps et de ressources humaines.
L’approche Shift-Left invite à faire collaborer le PO et le QA au maximum avant de passer la main aux développeurs. Les analystes QA vont proposer au Product Owner une série de tests d’acceptation pour valider une User Story afin de s’assurer de la bonne compréhension de la fonctionnalité, et si nécessaire, retravailler celle-ci soit au niveau des tests soit au niveau de la spécification avant qu’elle puisse avancer dans le backlog. Ces tests d’acceptation seront communiqués aux développeurs afin qu’ils puissent faire leur travail en s’assurant de prendre en compte ces différents critères.
Grâce au Shift-Left, l’équipe peut arriver à un développement agile du produit, une réduction des coûts de maintenance et du nombre d’heures passées à prendre en considération des cas à la marge qui n’auraient pas été bien préparés lors de la conception de l’User Story. L’objectif étant d’avoir à ouvrir le moins possible de bug au moment de la phase de la validation.
Bien qu’il soit fréquent de voir les équipes QA être évalués sur le nombre de tickets ouverts, l’objectif du Shift-left vient apporte une touche de prévention, au lieu d’être simplement un organe d’alerte et de répression. Mettre en place une approche Shift-Left peut donc nécessiter une réévaluation des KPIs affectés à l’équipe QA
L’approche Shift-Right se concentre sur l’après mise en production dans l’optique d’être proactif dans la recherche de problèmes sur l’environnement de production.
Parmi les pratiques Shift Right, ou peut imaginer mettre en place des sondes pour veiller à ce qu’une pile de messages Kafka soit toujours entre un niveau plancher et un niveau plafond permet à l’équipe de s’assurer d’être alertée si jamais il y avait un comportement anormal dans l’activité de production. On peut aussi penser à surveiller la bonne réponse de différentes API structurantes ou encore surveiller le temps de chargement de certaines pages.
Un autre exemple peut être la mise en place d’un Job qui va faire des requêtes en bases de données pour vérifier que tous les utilisateurs créés ces dernières 24 heures ont bien tous les champs requis et même donner un niveau d’information sur les champs non renseignés. Savoir par exemple que la propriété “Langue” n’est renseignée que dans 30% des cas va permettre aux QA et au Product Owner d’avoir un point de vigilance si jamais lors d’un développement, ce champ devenait essentiel au bon fonctionnement d’une feature.
Dans la plupart des cas, les tests Shift Right vont mettre en évidence des dysfonctionnements du côté de la donnée ou de l’infrastructure. Les systèmes d’alerting inciteront les QA à analyser l’origine du problème et à solliciter le bon interlocuteur en vue de sa résolution.
Chez Shippeo nous avons la conviction que la mission d’un QA est avant tout d’avoir une expertise fonctionnelle afin de challenger les fonctionnalités et d’utiliser cette philosophie Shift Left et Shift Right pour resserrer l’étau autour du produit pour renforcer sa qualité.
Nous avons fait le choix d’externaliser pour le moment l’automatisation des tests afin de donner l’opportunité aux nouveaux arrivant de monter en compétences fonctionnelles, comprendre leur environnement, et donner à la conception des tests toute la place qu’elle mérite pour être pertinente et efficace.
En complément de la conception des tests, nos analystes QA sont également responsables de proposer des moyens de surveillance de ce qu’il se passe en production et d’être un interlocuteur privilégié en cas de détection de problème que ce soit de façon proactive ou suite à la remontée de la part d’un client via l’équipe support.
Shippeo recrute à de nombreux postes, dont celui de QA. Si vous avez une appétence pour le fonctionnel tout en ayant une fibre technique, n’hésitez pas à me contacter sur LinkedIn ou à jeter un coup d’œil sur la page Shippeo.
Elles sont passées où les femmes dans la tech ? Entre le manque de représentation…
Dans cette vidéo, on interview Nicolas Grekas, contributeur clé de Symfony, pour discuter de sa…
Comment trouver son job dans la tech ? Marie a la réponse ! Grâce à…
Adobe, l'empire créatif, et pas des moindres ! Belle ascension de la part de ces…
Est-ce plus simple de créer des morceaux avec les outils de Musique Assistée par Ordinateur…