Le Systems Sciences Institute de IBM déclare que les coûts liés à la correction d’une erreur lors de l’implémentation sont environ six fois plus élevés que lors de la découverte de l'erreur pendant la phase de conception, et 15 fois plus élevés que lors de sa découverte dans la phase de test. Pouvez-vous imaginer les économies pouvant être réalisées avec un processus de test approprié mis en place dès le début de la phase de développement ?
Et il ne s'agit pas seulement de la localisation de bugs ou d'un code ne réagissant pas comme l'a prévu le développeur. Les tests sont essentiels pour assurer la performance et l'efficacité des systèmes, depuis leurs fonctionnalités et leur facilité d'utilisation jusqu'à la façon dont ils répondent aux exigences et aux objectifs finaux de l'entreprise. Qu'il s'agisse d'un projet interne ou d'une solution livrée par un partenaire, chaque logiciel doit être testé de la même manière que n'importe quel nouveau produit avant sa mise sur le marché.
De quoi avez-vous besoin avant de pouvoir commencer les tests fonctionnels ?
En tant que chef de projet, il vous faut un plan détaillé. Vous devez établir un calendrier clair pour toutes les parties prenantes, définir les domaines prioritaires à vérifier et disposer de directives de test précises. Vous devez également savoir qui va effectuer les tests, connaître les rôles assignés à chaque personne et le moment où elle devra être libérée pour cette tâche.
En tant que testeur, votre rôle est tout aussi important sinon plus. Être un bon testeur est un rôle à part entière. Que vous le fassiez à titre de propriétaire d'entreprise, d'éditeur de contenu ou à un tout autre rôle, vous devez savoir exactement quand et comment les tests devront être effectués et sur quels domaines vous devrez vous concentrer. En tant que testeur dédié, vous devez avoir une vision claire des exigences relatives aux solutions, à la fois fonctionnelles et non fonctionnelles. Vous devez comprendre les besoins des différents utilisateurs de la plateforme et les intégrer à votre processus de test.
Imaginez que quelque chose a été livré. Quelles doivent être les prochaines étapes ? Voici une liste de vérification :
- Qu'est-ce qui a été livré, et plus important encore, n’a pas été livré ?
- Quelles sont les exigences relatives à ce que je vais tester ?
- Comment puis-je réaliser les tests et où : puis-je me connecter au système, puis-je faire les tests avec différents navigateurs...?
- Comment suis-je censé signaler des bugs, des changements ou des questions ?
- Existe-t-il des directives pour guider les testeurs ?
Ne serait-il pas avantageux que cette liste de vérification de tests soit livrée avec un message indiquant que quelque chose a été livré ?
Les différentes phases de tests et les rôles respectifs : qui effectue les tests et pour quelle raison ?
Pour tout projet de test de taille raisonnable, vous devez vous attendre aux rôles suivants :
- Développeurs
- Quoi : vérification de son propre travail par des tests unitaires, des tests fonctionnels de base, des examens par des pairs
- Quand : pendant tout le développement
- Analyste fonctionnel
- Quoi : contrôle de sécurité, tests fonctionnels, tests de facilité d’utilisation et de cohérence
- Quand : avant et après chaque version (également les versions dans l’environnement de développement interne)
- Éditeur de contenu :
- Quoi : tests de facilité d’utilisation et tests fonctionnels
- Quand : après chaque version mise à jour dans l’environnement de l’éditeur
- Détenteur du produit :
- Quoi : contrôle qualité, tests fonctionnels
- Quand : après chaque version mise à jour dans des environnements autres que ceux des développeurs
Il peut sembler inutile d'avoir un testeur fonctionnel examinant la totalité du produit après que le responsable technique a déjà approuvé une fonctionnalité spécifique, sachant notamment que les développeurs ont écrit des tests unitaires et fait une révision par les pairs pour cette fonctionnalité particulière. Cependant, il est important de garder à l'esprit que les développeurs ont un objectif différent lors des tests et des révisions. Lors de la révision, ils s'assureront que le code est de bonne qualité (nous pourrions consacrer tout un article de blog à la façon dont nous définissons un bon code) et feront ce qu'ils sont censés faire. Mais cela ne signifie pas toujours qu'ils font ce qui est nécessaire d'un point de vue fonctionnel, que le résultat est intuitif ou qu'il fonctionne dans l'ensemble de la solution. De plus, les tests sont effectués par des êtres humains, et les êtres humains peuvent commettre des erreurs. C'est la raison pour laquelle il est si important de faire des contrôles qualité supplémentaires tout au long des phases de test.
Cela vaut également pour le propriétaire du produit qui doit effectuer beaucoup de tests en bout de ligne. Il se pourrait que l'analyste fonctionnel ait négligé un problème, qu'une exigence n'ait pas été remplie ou qu’un changement soit nécessaire après y avoir jeté un coup d'œil.
La chaîne de tests est longue, mais très importante et ne peut en aucun cas être négligée. Si elle n'est pas respectée, empêchant la détection de problèmes et donc le ralentissement du développement, la solution complète risque d’être compromise.
Updated