Reléguer les tests à la seule fin du projet peut conduire à découvrir les problèmes au moment où ils sont le plus imbriqués les uns dans les autres. Une approche plus utile consiste à discuter du comportement attendu avant le développement et à contrôler les éléments terminés tout au long du processus. Le jour de la livraison n'est alors plus le premier véritable essai.
01Mettez-vous d'accord sur le comportement attendu
Pour une tâche, l'expression « créer un écran de rapport » ne signifie pas nécessairement la même chose pour tout le monde. Quelle plage de dates sera utilisée, à quoi ressemblera un résultat vide, qui pourra exporter le rapport ? Lorsque les réponses à ces questions sont transformées en scénarios de test, le développeur, le designer et le client peuvent évaluer le même résultat. Cette clarté précoce aide à réduire les reprises ultérieures.
02Testez aussi les parcours en échec
L'utilisateur peut saisir une information erronée, voir sa session expirer ou cliquer une seconde fois sur le bouton d'enregistrement. Le plan de test ne doit pas se limiter à une personne qui suit les bonnes étapes ; il doit aussi couvrir ces situations. L'information enregistrée est-elle conservée, le message d'erreur est-il compréhensible, l'opération se duplique-t-elle par erreur ? La fiabilité d'un produit se révèle dans ces petits moments.
03Contrôlez les points de convergence entre les équipes
Lorsque différents développeurs travaillent en parallèle sur le même projet, il ne suffit pas que chaque module fonctionne isolément. L'information transmise d'un écran à l'autre, le rôle utilisateur et le format des données doivent aussi rester cohérents. La large équipe de développeurs et l'équipe de test professionnelle de Paradigma7 traitent ces points de convergence comme faisant partie du plan de livraison. Ce mode de travail en parallèle est détaillé dans notre article sur l'équipe mondiale. La rapidité ne s'obtient pas en supprimant les étapes de contrôle.
04Présentez la preuve de livraison de façon compréhensible
Le résultat d'un test ne doit pas se résumer au mot « réussi ». Il faut consigner la version testée, le scénario concerné, l'impact d'un problème éventuel restant et le résultat du nouveau contrôle. Le client peut ainsi voir quel périmètre est réellement achevé. Les tests réduisent les risques ; mais plutôt que de promettre l'absence totale de bugs en toutes circonstances, ils offrent une qualité visible et un processus traçable. La place de la preuve de test dans le pack de livraison est traitée dans notre guide du logiciel clé en main. Dans notre service de logiciel sur mesure, les tests occupent cette place à chaque étape.
05Checklist rapide
- Le comportement attendu de chaque tâche importante a-t-il été transformé en scénario écrit ?
- Les parcours en échec, comme une donnée erronée, une session expirée ou un double clic, ont-ils été testés ?
- Le transfert de données entre modules et les droits par rôle ont-ils été testés ensemble ?
- Les résultats de test sont-ils consignés avec le numéro de version ?
- L'impact des problèmes restants a-t-il été expliqué au client ?
Écrit par
L'équipe Paradigma7
Produit, ingénierie et opérations
Nous sommes une équipe basée à Ankara construisant des logiciels pour l'Europe. Rien ici n'est théorie : ce sont les processus que nous exécutons réellement sur les projets clients.
À propos