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

Publié par

Laisser un commentaire

Entrez vos coordonnées ci-dessous ou cliquez sur une icône pour vous connecter:

Logo WordPress.com

Vous commentez à l'aide de votre compte WordPress.com. Déconnexion /  Changer )

Photo Google+

Vous commentez à l'aide de votre compte Google+. Déconnexion /  Changer )

Image Twitter

Vous commentez à l'aide de votre compte Twitter. Déconnexion /  Changer )

Photo Facebook

Vous commentez à l'aide de votre compte Facebook. Déconnexion /  Changer )

Connexion à %s