sur-test vs sur-qualité

Duel: sur-test vs sur-qualité

Intro

Si vous êtes dans le test, et plus généralement dans l’industrie logicielle vous avez sûrement entendu parler de « sur-qualité ». Ce mot fait peur, surtout parmi les dirigeants, il faut surtout ne pas faire de sur-qualité!

L’argument « éviter sur-qualité » est principalement utilisé lorsque l’on parle de test. Dès que quelqu’un considère que certains tests ne sont pas utiles il parle de « sur-qualité ».

Mais si l’on se penche de plus près a t-on déjà vu un utilisateur se plaindre d’une trop grande qualité ? Ne devrait-on pas parler de sur-test ?

Définitions

Une fois n’est pas coutume, je n’ai pas de définition référence (et donc pas de définition ISTQB) pour définir ces termes. Vous trouverez donc facilement des définitions différentes tout aussi valable et pertinentes.

Sur-Qualité

Isabelle Hoareau définit la sur-qualité dans cet article comme une « conception des produits dont la qualité va au-delà des attentes du client en entrainant, dans un même temps, des coûts inutiles et inattendus »

Le principe est clair: la sur-qualité c’est proposer un produit aux utilisateurs qui dépasse leurs attentes en terme de qualité… Ce qui entraine des dépenses supplémentaires.

Exemples: il ne sert à rien de

  • proposer des images en 4K sur un smartphone qui ne peut afficher que du 1080p.
  • prévoir des serveurs pour une charge de 2 millions d’utilisateurs simultanés pour un blog comme la taverne du testeur

Dans les faits, savoir si l’on est sur de la sur-qualité est complexe avant de remettre le produit dans les mains des utilisateurs… En fait, c’est tout aussi compliqué (voire plus) qu’évaluer précisément la qualité d’un produit. Notamment à cause des multiples paramètres qui rentrent en jeu des des exigences implicites.

Sur-test

Le sur-test est le fait de trop tester tout ou une partie d’un service numérique.

Toute la plus-value d’un testeur est d’identifier ce qu’il faut tester afin d’atteindre le niveau de qualité requis. Le testeur, doit, de par sa conception de test réussir à optimiser le nombre de tests à exécuter (ou plus tôt l’effort nécessaire aux tests) pour atteindre le niveau de qualité attendu.

Il est évident que si l’on teste plus que nécessaire alors il y a des coûts supplémentaires ce qui entraine, sur le papier, des coûts inutiles et inattendus.

On pourrait alors penser à de la sur-qualité… mais il n’en n’est rien!

Pourquoi cette confusion ?

Quand on pense qualité on pense souvent test. Ce n’est pas pour rien que le testeur est souvent appelé « QA » pour, en français, Assurance Qualité.

Le lien est alors vite fait, si la qualité est trop élevé alors c’est qu’il y a eu trop de tests! Malheureusement les choses ne sont pas si simples… Et se contraindre à cette vision est même dangereux.

Pourquoi cette confusion est dangereuse ?

Penser que sur-test = sur-qualité entraine beaucoup de dérives.

Les plus évidentes sont le fait que si l’on a un problème lié à la qualité alors on ne va se tourner que sur le test alors que la qualité est globale. Si l’on reprend mes exemples précédents. Les problèmes de sur-qualité sont apparus dès la conception!

De même, si la qualité n’est pas suffisante on va penser qu’il suffit de faire plus de test. Ce n’est pas le cas! Plus de test ne veut pas dire plus de qualité. L’illusion d’absence d’erreur est là pour nous le rappeler.

Si l’on veut aller plus loin il me semble important de se pencher sur ma définition du sur-test. Le sur-test est rarement global (comme la manque de qualité) mais plutôt localisé. Il est facile de trop tester certains composants ou aspects qualité et ne pas assez d’autres parties du produit. La stratégie de test (plan de test maitre dans de nombreux cas) est là pour aider à limiter ces problèmes. Il faut cependant garder en tête que pour éviter le sur-test, la sur-qualité (ou sous-qualité) il est important de bien répartir son effort de test.

Conclusion

Sur-test et sur-qualité sont deux concepts radicalement différents. Même si une sur-qualité peut être entrainée par du sur-test ce n’est pas toujours le cas. De même on peut (et cela arrive souvent) avoir une mauvaise qualité avec du sur-test !

Pensez à rejoindre le groupe « Le métier du test » si vous souhaitez échanger sur le test

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

N’hésitez pas à faire vos propres retours d’expérience en commentaire.

Laisser un commentaire

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

conférence

Organiser la JFTL: le comité de programme (1/3)

Introduction L’organisation de tout événement est un travail minutieux que l’on a souvent tendance à sous-estimer la première fois que l’on est amené à participer à l’organisation d’un de ces événements. J’ai le plaisir d’avoir (et de continuer) à contribuer à l’organisation de beaux événements comme la STLS, les webinaires

Lire la suite »
Automatisation

Jérôme Beaumont: le RPA appliqué au métier du test – les défis (3/3)

Les 4 défis de l’automatisation pour le test informatique Se lancer dans un projet d’automatisation nécessite de relever les 4 défis suivants : faire face au foisonnement technologique, comprendre les assistants virtuels, relever le défi de la maintenance, obtenir un feedback rapide Faire face au foisonnement technologique L’assistant virtuel doit être

Lire la suite »
Automatisation

Automatiser ou ne pas automatiser? Telle est la question.

Cet article est fortement inspiré de celui-ci, que j’ai lu grâce au groupe Ministry Of Testing un groupe que je recommande fortement à tous les testeurs qui ne sont pas allergiques à la langue de Shakespeare. Pour ces mêmes personnes voici ma version (librement interprétée, ce n’est pas une traduction)

Lire la suite »