easi
youtube twitter linkedin facebook rss newsletters
0
right left

10.12.2015

Sebastien Santarelli,
Project Coordinator

who
back

Les 8 raisons de ne pas tester vos applications

2641 read – 2 comments – Mobile – Tags:

Actif depuis maintenant deux ans sur les projets mobiles, j'ai rassemblé pour vous toutes les raisons de ne pas inclure une phase de testing dans les projets de développement !

Après tout, qui est contre un gain de temps et d'argent ?

Si vous êtes un convaincu du testing et que vous voulez que l'on se dispute, lisez uniquement les titres en gras et envoyez moi un e-mail. Si vous voulez que l'on ait une chouette discussion, lisez l'ensemble de l'article et commentez, je suis curieux de partager avec vous sur ce sujet. Merci déjà !

1. Le développeur doit tester le fruit de son travail

Le développeur doit tester l'application mais toute personne qui a déjà développé sait que l'on a une fâcheuse tendance à tester les "bons cas", le chemin évident dans l'application mais pas les chemins annexes, qui seront plus difficilement supportés par l'application. Le développeur testera l'application, mais cela ne suffira pas.

2. Ce développement est simple, un collègue de bureau le testera vite fait

Un test d'acceptation utilisateur est très intéressant mais il y a d'autres tests à effectuer avant celui-là. Uniquement effectuée sur un coin de table, entre deux coups de fils, le testing réalisé ne sera pas d'une grande aide pour le projet.

3. Tester ça prend du temps

C'est clair mais je vous laisse imaginer le temps que prennent les modifications et corrections quand on livre un projet qui n'a pas été testé depuis l'écriture de la première ligne de code.

4. Tester ça coûte de l'argent

Le testing dans un projet de développement sur mesure représente une part croissante des dépenses, tout le monde s'en rend compte et Capgemini nous indique dans son rapport annuel (lien vers : https://www.be.capgemini.com/thought-leadership/world-quality-report-2015-16 ) que les dépenses en Quality Assurance & testing augmentent chaque année pour atteindre 35% cette année et 40% en 2018.

Le coût de certaines erreurs (impact sur le business, sur l'image, sur la sécurité, etc) est bien supérieur au coût du testing.

5. On a pas le temps de faire les tests si on veut livrer à temps

C'est vrai on livrera à temps, mais le client ne démarrera pas en production et sa perception de la qualité du travail fourni sera impactée. Les tests font partie des projets et la livraison doit s'effectuer quand ils ont été réalisés. Votre client vous sera davantage reconnaissant d'une mise en production sans encombre 2 semaines après l'échéance initiale, que d'une mise en production dramatique, à temps.

6. C'est le client qui doit tester

Vous aurez beau appliquer tous les cas de tests définis avec votre client, il aura toujours une meilleur perception des données présentées dans une application, de la correspondance de l'application avec les besoins du terrain.

Il y a quelques années, nous avons réalisé la mise en place d'un outil de gestion des interventions de techniciens sur le terrain. Lors des phases de test, je téléphonais systématiquement à un des utilisateurs finaux de l'application, pour récolter son feedback sur les améliorations mises en place. Ce monsieur travaillait depuis plus de 30 ans dans ce domaine, une incohérence de prix ou de pièces sélectionnées pour une intervention lui sautait au yeux en quelques instants. Cela nous permettait d'ajuster les derniers paramètres de l'application, avant son passage en production.

7. C'est le fournisseur de service qui doit tester

Cependant, tout ce qui peut être testé au niveau du prestataire de service, en correspondance avec l'analyse fonctionnelle du projet, devra l'être afin de ne pas créer de frustration chez le client qui serait confronté à un crash de l'application lors d'un simple cas d'utilisation.

L'analyse fonctionnelle permettra de réaliser des tests cases et des plans de tests, qui seront exécutés par le fournisseur de service qui s'efforcera de tester l'application à fond.

Toutefois, il est difficile pour un client d'externaliser le testing à 100%, pour les raisons évoquées au point précédent.

8. Le client testera quand on livrera le dev complet

En attendant la fin du projet pour effectuer les tests et inclure votre client dans le testing, vous augmenterez le coût des modifications à effectuer et certaines d'entre-elles seront impossibles ou du moins très couteuses (modification dans la modélisation des données par exemple).

Les méthodes agiles de développement nous offrent un délivrable utilisable à chaque grande étape du projet, qu'il serait dommage de ne pas tester avec votre client.

Vous l'aurez compris, je suis un convaincu du besoin croissant de testing pour les projets de développement et j'ai rassemblé ici les remarques les plus marquantes que j'ai pu rencontrer chez des clients, en discutant avec des collègues ou tout simplement autour d'un verre avec des amis.

Je pense sincèrement que nous vous ferons gagner du temps et d'argent en consacrant la part nécessaire du temps de votre projet, à son testing. 

Nous en discuterons ensemble lors de nos prochaines rencontres dans le cadre de vos projets, afin de réaliser un testing sur mesure de ceux-ci, en concordance avec vos besoins. 

Leave a comment

2 comments

Très bon cet article !

10.12.2015

08:56:44

Fabrice
Merci Fabrice

10.12.2015

09:34:58

seb

Post your comment