Le bug présenté dans notre précédent post a attiré un grand nombre de commentaires tous plus intéressants les uns que les autres.

Donc d’abord, un grand merci à tous ceux qui nous ont fait part de leur point de vue, puisque c’était justement l’objectif de cette publication.

Mon expérience de consultant est plutôt orientée ‘best practices’ en matière de cycle de vie de projet (ex-développeur, ex-chef de projet, puis dans le Configuration Management et la qualité de code). Je ne suis donc pas un expert en QA.

Mais je travaille régulièrement avec de bons professionnels de QA et j’étais très curieux de l’opinion de personnes plus expertes que moi dans ce domaine … avant de formuler quelques hypothèses dans ce second post.

Tout d’abord, un rappel du bug en question.

Un site web marchand propose á la vente chaque jour différents produits de différentes marques, chacune représentant un magasin virtuel dans lequel vous pouvez ‘naviguer’ et ajouter dans votre panier (virtuel) les articles qui vous intéressent. Une fois vos achats validés par un paiement, vous pouvez sélectionner une marque différente et lorsque vous procédez à de nouvelles acquisitions, le site vous propose de grouper ceux-ci avec vos achats précédents en une unique livraison. C’est le fonctionnement par défaut.

Dans mon cas, j’ai acheté deux articles différents d’une même marque, mais lorsque j’ai voulu procéder au paiement, un message m’a averti que ces deux articles nécessitaient deux transporteurs différents et donc deux livraisons. Il me fallait réaliser deux achats et deux paiements distincts. Le fonctionnement par défaut ne s’appliquait donc pas.

J’ai alors repris mes emplettes, effectué un premier achat pour le premier article (2 chaises de jardins), puis un second achat (un hamac portable) et lorsque j’ai voulu valider celui-ci … je me suis vu proposer une livraison unique, c’est-à-dire le process par défaut qui ne devait pas s’appliquer. Je dois confesser que je subodorais le bug, et que la curiosité m’a poussé à accepter, pour me retrouver avec :

• Une page d’erreur générique très imprécise, absolument d’aucune aide.
• Une session ‘web’ complètement instable, avec l’impossibilité de réinitialiser mon panier et retrouver le processus normal qui m’aurait permis de finaliser mes achats.

Sortir du site pour y rentrer à nouveau ne fut d’aucun effet, il m’a fallu clore mon browser et me logguer à nouveau afin de pouvoir effectuer mes achats. J’espère que les articles qui me seront livrés seront à la hauteur des difficultés rencontrées pour les acquérir.

Si je tente de raisonner d’un point de vue projet : le processus de livraison habituel ne s’applique pas, et le développeur a correctement implémenté un processus ‘par exception’. Mais l’intégration de cette nouvelle fonctionnalité avec le processus par défaut existant aboutit à un bug que j’estime grave (au minimum) puisqu’en tant qu’utilisateur de ce site, je suis tombé dessus immédiatement, et en suivant un processus normal d’achat.J’ai tenté d’imaginer quelle pouvait en être la cause, et c’est là que j’ai décidé d’écrire un premier post afin de demandeur son opinion à la communauté des spécialistes QA.

Cherchez l’erreur.

Vos réactions (en résumé) :

• Ce n’est pas un défaut de test : cette fonctionnalité n’a tout simplement pas été testée.
• Ce n’est pas un défaut de test : c’est un problème de design.
• Un bon testeur doit être capable d’abandonner la logique de tests et de passer de l’autre côté : se mettre à la place de l’utilisateur et tester avec une logique d’utilisateurs. Je dois préciser que cette opinion n’a été formulée que par des testeurs ‘hispanisants’.
• Il s’agit d’une classique situation où la pression du time-to-market, le manque de ressources, etc. aboutit à un défaut de tests.

L’objet premier de tout test est de s’assurer qu’un produit – logiciel en l’espèce – réponde correctement à ce qu’on en attend en termes de fonctionnement et de qualité. Le test est un métier, une spécialité en soi, demandant un certain nombre de compétences et pas mal d’expérience. Dans notre exemple, on peut considérer que le résultat n’est pas atteint : cette fonctionnalité n’a pas été testée, ou les tests n’ont pas été effectués correctement.

Le fait que le site renvoie à une unique page pour tous les problèmes éventuels m’a laissé penser que le budget Développement / QA n’est pas forcément à la hauteur de la croissance du site. J’y vois là le signe d’une certaine paresse ou d’un manque de moyens. Un aveu d’impuissance. La gestion des erreurs n’est clairement pas une priorité.

Comment ? Je ne peux pas réaliser un achat et ce n’est pas une priorité ? Ce site web ne veut pas de mon argent ?

J’ai voulu en savoir plus et j’ai appelé un ami, consultant indépendant comme moi, avec une bonne connaissance de ce type de sites marchands et des difficultés qu’ils doivent affronter. Nous avons donc parlé de priorités et de management. Voici ce que j’ai appris :

• Ce site gère plus de 100 000 connexions par jour, avec un temps de réponse optimal et sans jamais aucune interruption. Les ventes en 2011 ont portées sur environ 1 500 marques.
• Le développement et la QA sont gérés en interne, par une soixantaine de personnes. Pas d’outsourcing.
• Ce département effectue ses propres développements mais utilise également différents ERPs. . Méthodologies en V et Scrum.
• L’entreprise a ouvert régulièrement des filiales dans différents pays. Une rumeur circule sur un éventuel projet d’aller dans le Cloud et proposer une infrastructure type SaaS qui permettrait de disposer de sa propre boutique en ligne.

Une anecdote fournie par cet ami. Tout acheteur peut demander à se voir rembourser un achat si, une fois celui-ci reçu, il s’aperçoit qu’il ne correspond pas à ses souhaits : produit défectueux, taille incorrecte, ou tout simplement, vous n’en voulez plus. Dans ce cas, vous renvoyez le produit et vous demandez son remboursement. Il est arrivé que tous les remboursements soient suspendus pendant plusieurs semaines à cause d’un bug. Le management avait tout simplement stoppé les remboursements le temps de réécrire l’application ou d’implémenter un ERP avec la même fonction. Vous imaginez la fureur des utilisateurs / acheteurs et la mauvaise publicité pour le site ?

Ne pas faire de ses utilisateurs une priorité n’est pas le choix d’un simple développeur ou d’un testeur paresseux : c’est un choix de management. Et je ne connais qu’une seule priorité au-dessus des utilisateurs, du point de vue du management : le budget.
Ce qui n’est pas le cas en l’espèce. Ce site web est pionnier et leader sur son marché des ventes privées, avec une croissance impressionnante. Je vous parle d’une startup en train de conquérir le monde, pas d’une entreprise centenaire sur un marché en déclin.

Je pense donc que nous sommes en présence d’une informatique pour laquelle la priorité est de faire face à la croissance du business, d’être prêt pour l’ouverture de chaque nouvelle filiale, de pouvoir gérer la logistique de 1 500 fournisseurs différents pour des dizaines de milliers de clients, d’éviter toute interruption de fonctionnement ou mauvaise perfornance du site, … L’IT a pour ce faire accumulé des strates de différentes technologies : applications développées en interne à un rythme important, duplication / spécialisation des systèmes en fonction de la réglementation de chaque nouveau pays, intégration de différents ERPs, etc…

Il arrive alors un moment où l’accumulation de dette technique est telle que :

• Un module entier – tel que celui des remboursements – peut cesser de fonctionner : on cesse de rembourser pendant plusieurs semaines, sans même chercher à trouver un palliatif, le temps de mettre en place un nouveau logiciel ou de réécrire l’application.
• Le nombre de bugs rencontrés est trop important pour gérer chacun de manière indépendante : on met en place une unique page d’erreur générique et que l’utilisateur se débrouille.
• Et puisque l’utilisateur n’est pas une priorité, et puisque toutes les erreurs possibles sont ‘gérées’, pourquoi perdre du temps en tests ?

Il arrive un moment où il y a tellement de fuites qu’on ne cherche plus à colmater chacune d’entre elles : on place un grand tonneau et on écope.

En tant que consultant Qualité, mes recommandations seraient les suivantes :

• Une analysis systématique de la qualité du code sur l’ensemble du porfefeuille d’applications.
• Vérifier quels sont les systèmes trop lourds à maintenir, qui n’autorisent plus aucune souplesse en termes de time-to-market, qui connaissent des retards de réalisation, des efforts de QA importants, etc.
• Croiser ces données de projet avec celles de la qualité de code afin de décider sur quelles parties du portefeuille d’applications effectuer un refactoring.

J’en profiterais également pour vérifier si la méthodologie utilisée – par exemple en V – peut expliquer certains mauvais résultats en termes de projet. Si la QA découvre trop de bugs trop tard dans le cycle de vie de projet, il arrive un moment où l’effort de correction est trop important pour le délai imparti.

Si la rumeur est fondée qui suppose de proposer le site en tant que Service as a Software, alors le refactoring est non seulement justifié mais impératif. Il ne s’agit pas simplement de remettre l’utilisateur au centre de l’IT, il s’agit tout simplement de retrouver un niveau de qualité des applications qui permette à ce site de poursuivre sa croissance.

J’ai déjà rencontré ce type de situations avec des Telcos. Ils ont du faire face à une croissance très forte et leurs départements informatiques ont expérimentés ces mêmes problèmes, et doivent maintenant gérer des systèmes applicatifs de piètre qualité, un nombre incalculable de bugs, … sauf que ces sociétés ne sont plus sur un marché en croissance et que les budgets IT se réduisent et qu’aucun refactoring n’est maintenant possible.

Et c’est alors que le management décide de replacer l’utilisateur au centre de sa stratégie parce qu’en l’absence de croissance, quand il n’est plus possible de gagner de nouveaux clients, vous commencez à soigner ceux que vous avez et éviter de les perdre devient la priorité.

Cherchez l’erreur… avant qu’il ne soit trop tard.

 

Cette publication est également disponible en Leer este articulo en castellano : liste des langues séparées par une virgule, Read that post in english : dernière langue.