La qualité est un choix

Introduction :

Idéalement tout produit ou logiciel ne devrait pas avoir de bug. Malheureusement comme déjà vu dans mon article sur le logiciel sans bug la qualité a un coût. La qualité est donc un choix, tant au niveau d’un utilisateur (généralement le prix est un indicateur, un téléphone à 500€ sera de meilleure qualité qu’un téléphone à 200€) qu’au niveau projet pour un logiciel (si on a 10 jours hommes réservé à la qualité pour un logiciel cette dernière sera moins grande que si l’on a 100 jours hommes pour le même logiciel).

Critères pour déterminer le niveau de qualité souhaité :

Il y a de nombreux critères pour déterminer le niveau de qualité d’un logiciel, en voici quelques exemples :

·        La criticité de l’application (Voir mon article sur la gestion des bugs pour plus d’informations), une application mail ou de réseau social peut se permettre d’avoir des défauts comme des crashs applicatifs (personnellement j’en ai avec mon application Linkedin qui de temps en temps crash au démarrage) qu’une application de trajectoire embarquée dans un satellite. Dans le cas d’un crash sur Linkedin je relance juste l’application, dans celui d’un satellite, ce dernier se retrouve perdu et on perd donc des millions d’euros (coût de construction et de lancement).

·        L’image de la marque, une marque « low cost » peut se permettre une moins bonne qualité qu’une marque comme Apple ou Samsung qui axent leur communication sur la qualité. On a vu récemment les impacts d’un défaut de batterie sur les Galaxy Note et sur l’image de marque de Samsung qui a perdu plusieurs milliards avec cette affaire.

·        Le budget de l’application

·        Le prix auquel on veut vendre le logiciel (il est plus facilement accepté d’avoir des bugs sur un éditeur de texte gratuit que sur un logiciel comme Word).

·        Le retour sur investissement, à partir de quel moment cela coûte plus cher d’augmenter que cela ne rapporte ?

Après avoir déterminé quel niveau de qualité l’on souhaite, il faut savoir comment arriver à un coût minimal pour atteindre le niveau de qualité souhaité. Pour cela il y a de nombreuses variables sur lesquelles travailler.

Variables pour cibler le niveau de qualité :

·        On peut d’abord travailler sur les couvertures de test en fonction des niveaux de test.

o  Pour chaque niveau de test (unitaire, intégration, système et acceptance), quel type de couverture je veux utiliser et quel pourcentage doit-on atteindre ?

·        Implémentation process (tests vitaux et tests de régression)

o  C’est une partie cruciale. Les tests vitaux sont, pour moi, quasiment obligatoire et très peux coûteux à mettre en place.

o  Pour les tests de régression se pose une autre question, lesquels choisir ? Quel pourcentage en fonction des fonctionnalités ? Cela dépend évidemment du niveau de couverture souhaité mais aussi de la criticité de la fonctionnalité et de sa stabilité. Il ne faut pas oublier que plus on a de tests de régression plus ils coûtent cher à exécuter et à maintenir.

·        Quels tests automatiser ?

o  La première question est veut-on automatiser des tests ?

§ Si non, il faut assumer d’avoir un coût d’exécution des tests. Si les tests ne sont pas souvent exécutés cela peut-être un choix pertinent. L’automatisation coûte cher, le retour sur investissement se voit sur le moyen voir le long terme.

§ Si oui, il faut sélectionner les tests à automatiser en fonction de leur récurrence d’exécution (c’est pourquoi il faut généralement automatiser les tests vitaux en priorité), de leur stabilité ou facilité de maintenance et de leur coût d’écriture. Automatiser 100% des tests fonctionnels est rarement une bonne solution.

·        Les tests exploratoires

o  Ces tests ne sont pas cher à mettre en place et sont un bon complément aux tests vitaux et aux tests de régression. De plus c’est une très bonne réponse au paradoxe des pesticides.

·        La gestion des bugs

o  Quasiment toutes les logiciels sortent avec des bugs (ou défauts) connus. Néanmoins en fonction du niveau de qualité souhaité on peut décider de mettre en production ce logiciel ou cette application. On utilise généralement plusieurs outils dans ce cas pour savoir si oui ou non l’application peut sortir :

§ Le premier est le pourcentage de tests fonctionnels en succès, si 85% des tests fonctionnels sont en succès l’application peut-elle être adoptée par les utilisateur ? Cela va dépendre de l’application.

§ Le second est le nombre de bugs restants et leur criticité. Peut-on sortir avec 2 bugs majeurs et 5 mineurs ? Généralement une sortie ne se fait jamais avec un bug critique, par contre il y a souvent des critères de mise en production donnant le nombre de bugs majeurs et mineurs autorisés.

·        Les tests non fonctionnels

o  Ces tests regroupent l’ensemble des tests qui ne sont pas fonctionnels tels que les tests de sécurité, de stabilité et de maintenabilité. Ils sont souvent effectués avec des outils.

Conclusion :

Encore une fois tout est dans le compromis. L’objectif 0 défaut est toujours très difficilement atteignable (et très coûteux) par contre il n’est quasiment jamais rentable. Lorsque l’on veut sortir un logiciel il faut également penser à la qualité que l’on veut pour ce logiciel et savoir si oui ou non cette qualité est atteignable avec le budget de ce logiciel.

Ne pas tester une application peut être un choix (par exemple sortir une application android de lancé de dé qui ne fait que donner un entier aléatoire entre 1 et 6 peut ne pas être testée car un bug sur cette application n’aurait quasiment pas d’impact). La qualité est donc bien un choix, un positionnement du produit que l’on veut mettre sur le marché. Sur un marché saturé avec du haut de gamme, avoir un produit avec une qualité moindre et faire du moyen de gamme peut être une stratégie gagnante, cela entraine une baisse du budget de la qualité mais peut également être une source d’amélioration du rapport qualité/prix et séduire un bon nombre d’utilisateurs peu enclin à payer le prix des produits haut de gamme.

Galaxy Note: http://www.lefigaro.fr/secteur/high-tech/2016/10/11/32001-20161011ARTFIG00127-samsung-galaxy-note-7-chronologie-d-une-descente-aux-enfers.php

Tests non fonctionnels: http://istqbexamcertification.com/what-is-non-functional-testing-testing-of-software-product-characteristics/

Pensez à rejoindre le groupe Le métier du test si le test vous intéresse !

N’hésitez pas à me suivre et lire mes autres articles si vous voulez en apprendre plus sur le test ou venir partager vos connaissances

Merci à tous ceux qui mettent « j’aime », partagent ou commentent mes articles

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Bilan

La visibilité des tests

Suite à des entretiens passés récemment je me suis aperçu que le principal reproche remonté par les managers aux équipes de test était souvent le manque de visibilité sur les tests. « Je ne sais pas ce qui est testé », « je ne sais pas comment c’est testé »… Ces retours sont particulièrement

Lire la suite »
culture générale

La maturité des tests: la mesure par l’audit (3/3)

Introduction Les audits représentent probablement la méthode la plus connue pour mesurer la maturité des tests. On parle d’ailleurs souvent d’audits TPI ou TMMi qui peuvent être considérés très lourds en terme d’investissement. Mais les audits ce n’est pas que des audits TPI ou TMMi. La définition ISTQB est celle-ci:

Lire la suite »
Agilité

Livre CFTL – la transformation Agile

La transformation agile n’est pas un long fleuve tranquille !  Pour réussir une transformation agile, il faut l’anticiper et travailler sur plusieurs points. Ces points sont :  La formation des futures équipes aux méthodes et à la philosophie agile  La première chose à faire est de s’assurer que les membres des futures

Lire la suite »