Créer une stratégie de qualité
Republié avec la permission de l'excellent blog de Kristin, thinkingtester.
Dans mon dernier article, j'ai présenté le concept du modèle de maturité qualité : une série de comportements liés à des attributs de la qualité qui aident les équipes à atteindre divers aspects de la qualité dans leur logiciel.
Il est important de noter que l'adoption d'un modèle de maturité qualité exige que toute l'équipe contribue à la qualité.
La qualité n'est pas quelque chose à "jeter par-dessus le mur" aux testeurs ; c'est plutôt un objectif que partagent aussi bien les développeurs que les testeurs.
Mais comment faire en sorte que toute l’équipe s’approprie la qualité ?
Une façon d’y parvenir est de créer une stratégie qualité. Il s'agit d'un document sur lequel toute l’équipe s’accorde ensemble. Considérez-le comme un contrat qui décrit comment le logiciel de qualité sera développé, testé et livré par l'équipe.
Ici, je vais aborder quelques questions auxquelles vous voudrez peut-être répondre dans la stratégie qualité de votre équipe.
Création et affinement des user stories
Question : Comment l’équipe décide-t-elle des user stories à traiter ?
Cela peut être une décision prise par l’ensemble de l’équipe ou uniquement par le product owner. Ou bien la priorisation peut être faite par une personne extérieure à l'équipe.
Question : Qui affine les user stories pour les préparer au développement ?
Cela peut être toute l'équipe ou un sous-ensemble de l'équipe. Idéalement, vous voudriez que le product owner, un développeur et un testeur participent au processus.
Processus de développement
Question : Comment l’équipe décide-t-elle qui travaille sur quelle user story ?
Il est possible que les développeurs puissent choisir n'importe quelle story sur le tableau, ou bien que chaque développeur ait des stories dans des domaines fonctionnels spécifiques parmi lesquelles il peut choisir.
Dans certaines équipes, les testeurs logiciels travaillent également sur des stories de développement simples, comme changer des mots ou des couleurs sur une page web ou ajouter des identifiants pour faciliter l’automatisation.
Question : À quoi ressemble la définition de “Terminé” pour une story ? Est-ce mesuré par le respect de tous les critères d’acceptation de la story ? Le développeur doit-il ajouter des tests unitaires avant que la story puisse être considérée comme terminée ? Comment savoir si une fonctionnalité est prête à être testée ?
Dans de nombreuses équipes, il est attendu que le développeur effectue un premier test pour vérifier que ce qu'il a codé est prêt pour des tests complémentaires.
Transmission de la fonctionnalité
Question : Comment une story sera-t-elle transmise pour les tests ?
Dans certaines équipes, cela se fait simplement en déplaçant la story dans la colonne “Tests” du storyboard. Dans d'autres équipes, une cérémonie de transmission plus formelle est requise, durant laquelle le développeur fait une démonstration de la story et fournit des suggestions pour les tests à effectuer.
Question : Qui déploie le code dans l'environnement de test ?
Cela peut sembler anodin, mais cela peut en réalité causer de nombreux malentendus et beaucoup de perte de temps. Si le développeur pense que c'est au testeur de déployer le code dans l’environnement de test et que le testeur suppose que le développeur l’a déjà fait, le testeur peut commencer à tester sans se rendre compte que le nouveau code manque, jusqu’à ce qu'il ait investi beaucoup de temps sur l’application.
Question : Qui effectuera les tests ?
Dans certaines équipes, les développeurs peuvent prendre en charge des stories de tests simples pour améliorer la vélocité du produit, tandis que les stories plus complexes sont confiées aux experts du test.
Création du plan de tests
Question : Qui va créer les plans de test ? Comment seront-ils élaborés ? Où seront stockés les plans de test ?
Certaines équipes préféreront réaliser des tests exploratoires ad hoc avec une documentation minimale. D’autres équipes utiliseront des systèmes élaborés de gestion des cas de test qui documentent tous les tests du produit. Et de nombreuses autres possibilités existent entre les deux.
Quel que soit votre choix, il doit être adapté à votre équipe et à votre produit.
Question : Qui écrira l’automatisation des tests ?
Dans certaines équipes, les développeurs écrivent les tests unitaires et les testeurs écrivent les tests API et UI. Dans d’autres équipes, les développeurs écrivent les tests unitaires et API, et les testeurs créent les tests UI. L’idéal est que développeurs et testeurs partagent la responsabilité de la création et de la maintenance des tests API et UI.
De cette manière, les développeurs peuvent apporter leur expertise en gestion du code, tandis que les testeurs apportent leur expertise sur ce qui doit être testé.
Question : Qui réalisera les autres types de tests, comme la sécurité, la performance, l’accessibilité ou l’expérience utilisateur ?
Dans certaines grandes entreprises, il y a des spécialistes de la sécurité et de la performance dédiés à ces tests. Les jeunes startups, quant à elles, ne disposent souvent que d’une seule équipe de développement qui doit prendre tout en charge.
Outils de test
Question : Quels outils seront utilisés pour les tests manuels et automatisés ?
Le choix des outils de test est très important lorsque vous souhaitez que toute l'équipe se sente responsable des tests. Les développeurs voudront très probablement utiliser des outils dans le même langage que celui utilisé pour le développement, car cela minimise le changement de contexte qu'ils auront à effectuer.
Maintenance des tests
Question : Qui est responsable de la maintenance des tests ?
Il est surprenant de voir à quelle vitesse l'automatisation des tests peut devenir obsolète. Un simple changement de mot sur une page peut entraîner un échec de test. Idéalement, l'équipe devrait avoir une politique « tu casses, tu répares » où les tests sont corrigés par la personne qui a intégré le code qui les a cassés.
Si cela n’est pas possible, assurez-vous au moins que tout le monde dans l’équipe comprend comment fonctionnent les tests et comment les corriger rapidement si besoin.
Bugs et dette technique
Question : Comment les bugs sont-ils pris en charge lorsqu’ils sont découverts lors des tests ? Sont-ils discutés par le développeur et le testeur, triés par toute l’équipe, ou consignés dans un backlog à traiter plus tard ?
Il est souvent judicieux de corriger les bugs dès qu'ils sont découverts, car le développeur travaille déjà sur cette partie du code.
Question : Comment l’équipe va-t-elle gérer la dette technique ?
L’équipe a-t-elle convenu de traiter une certaine quantité de dette technique par sprint ? Certaines équipes ont pour règle que lorsqu’un développeur n’a plus de user stories à traiter, il prend en charge des éléments de dette technique dans le backlog.
Livraisons
Question : Quel type de tests allez-vous effectuer avant une livraison ? Aura-t-il un plan de tests de régression que toute l’équipe pourra exécuter ensemble ? Et qu’en est-il des tests exploratoires ?
Une équipe très performante que je connais se réunit pour effectuer des tests exploratoires juste avant de livrer. Cette stratégie leur a permis de découvrir des bugs complexes et de les corriger avant qu’ils ne soient mis en production.
Question : Comment le logiciel sera-t-il livré ?
Dans certaines entreprises, il y a un responsable des livraisons qui se charge d’exécuter la livraison. Dans d'autres, ce sont les membres de l'équipe qui livrent le logiciel à tour de rôle. Une technique très utile est le déploiement continu, où le logiciel est automatiquement déployé et les tests sont exécutés automatiquement pour vérifier le déploiement sur chaque environnement, ce qui fait gagner du temps et des efforts à tout le monde.
Lecture associée : COMMENT EFFECTUER DES TESTS SMOKE API DANS VOTRE PIPELINE DE DÉPLOIEMENT CONTINU
Need expert help selecting the right Other Software?
We’ve joined up with Crozdesk.com to give all our readers (yes, you!) access to Crozdesk’s software advisors. Just use the form below to share your needs, and they will contact you at no cost or commitment. You will then be matched and connected to a shortlist of vendors that best fit your company, and you can access exclusive software discounts!
Maintenance
Question : Comment mesurerez-vous le succès de la livraison ?
Une fois le logiciel livré, il est facile pour les équipes de développement de l’oublier ; mais c’est le moment où les utilisateurs commencent à l’utiliser. Quels types de mesures pourriez-vous utiliser pour évaluer l'efficacité de votre produit ? Vous pourriez suivre les défauts signalés par les clients, ou analyser les journaux pour détecter les erreurs inattendues.
Question : Comment assurerez-vous le suivi de la santé de votre application ?
Il serait judicieux de mettre en place des alertes afin d’être informé des problèmes de votre application avant vos utilisateurs.
Question : Quels types de comportements devez-vous surveiller ?
Les stratégies qualité peuvent être aussi variées que les flocons de neige. Imaginez la différence entre une petite startup de dix personnes développant une application de chat mobile et une entreprise de vingt mille personnes concevant un logiciel qui fait voler des avions. Ces deux entreprises auront besoin de stratégies très différentes !
Vous pouvez concevoir une stratégie qualité adaptée à votre équipe en discutant ensemble de ces questions et en rédigeant une approche qui fasse consensus.
Pour des outils et technologies qui peuvent aider vos processus, consultez cette liste des 10 MEILLEURS OUTILS DE GESTION DES DONNÉES DE TEST.
