Le test, combien ça coûte ?

Au moment de chiffrer le coût d’un projet de développement pour une solution logicielle ou objet connecté IoT – la prise en compte du budget test & validation est cruciale : une estimation juste permettra de mener le projet à bien et livrer un produit fiable et fonctionnel. Ici, il n’est pas question de donner un chiffrage ni même une estimation à la louche – la part du coût du test dépend notamment de l’ambition et la complexité du projet.

Dans le cadre d’une mission de tests et validation d’une solution logicielle, deux étapes bien distinctes seront chiffrées :

1-La rédaction des cas de tests utilisateur et la construction du plan des tests

Faire connaissance avec le projet permettra de préparer les cas de tests. Ainsi, l’étude des éléments déjà disponibles (cahier des charges, Product Requirement Document, spécifications, stories…) et la manipulation d’une version préliminaire de la solution rentrent dans cette phase d’approche.

Ensuite, l’équipe réfléchit à la conception de tous les cas de tests envisageables – le travail de test a déjà démarré lorsque ces éléments sont en place. Logiciel type SAAS, objet connecté – faire le tour du périmètre des tests et rédiger les cas de test nominaux peut prendre de 3 à 5 jours de travail

Cette première phase est loin d’être figée, car le plan de test sera enrichi au fur et à mesure des développements (pour intégrer les tests des nouvelles fonctions/stories développées) et des retours des sessions de tests (pour améliorer les descriptions des cas de tests existants, les compléter avec de nouvelles idées).

En conséquent, il faudra compter du temps en plus au fil des versions pour la mise à jour du plan de tests.

2-L’exécution des tests

Le plan de test est déjà bien abouti, c’est le moment de démarrer les sessions de tests !

Lors d’une campagne de tests d’une nouvelle itération, l’ingénieur Tests vérifiera les corrections de bugs remontés sur la version précédente, jouera tous les cas de tests afin de tester les nouvelles fonctionnalités mais aussi déceler les régressions, il remontera de nouveaux bugs dans une base dédiée, et la campagne s’achève avec la rédaction d’un compte-rendu de la qualité de la version.

Là encore, les critères qui modifient le chiffrage comprennent la quantité de cas de tests disponibles, le nombre de devices sur lesquels seront réalisés les tests (dans le cas d’une application mobile : Android, iPhone) et dans le cas d’une SAAS, le nombre de navigateurs sur lesquels on veut tester la solution (Chrome, Firefox, etc).

Lorsqu’il s’agit d’un projet AGILE avec des Sprints, on évalue le temps de test à 30% par rapport au temps de développement.

« Ok mais on va vite sur les tests alors »

On a forcément tous entendu cette phrase dans la bouche d’un chef de projet. Il n’a pas le budget, pas les ressources, pas le planning. Pas toujours évident à dimensionner ? Pourtant il est important d’anticiper et intégrer la phase de tests (voire la ressource ad hoc) au budget et au planning de développement – négliger les tests, c’est prendre le risque de sortir un produit aux fonctionnalités aléatoires. De gérer des retours clients assez mitigés. C’est devoir reprendre l’intégralité du projet et d’y adjoindre les coûts d’un redéveloppement. Si là encore, le chiffrage est difficile à envisager, il est en revanche aisé d’imaginer l’ambiance dans laquelle se déroulera ce redéveloppement…

Du bonus !

L’ingénieur Test connaît très bien son produit pour l’avoir minutieusement exploré et examiné sous tous les angles. Par conséquent, il est tout à fait en mesure de prendre en charge une partie du SAV, voire de proposer la rédaction des FAQ utiles aux clients. Idem, dans le prolongement de l’accompagnement client, l’ingénieur Test pourra proposer des supports de formation (vidéos tutorielles) pour la prise en main du produit.

Il est utile d’intégrer ces éléments au chiffrage du test pour profiter des compétences assises de l’ingénieur qui a pris en charge la phase de tests.