En cas de conflit dans notre vie personnelle, l’attitude recommandée consiste à prendre son courage à deux mains (et sa lucidité) et tenter de résoudre le conflit du mieux que nous pouvons.

Pour une entreprise, les options sont plus nombreuses, et bien moins claires. Il arrive fréquemment qu’une organisation déplace les conflits au lieu de les résoudre.

Par exemple, cet éditeur, confronté à l’obligation de refondre le produit qui fait son succès sous peine de perdre son marché, a choisi, après quelques semaines de réflexion la voie suivante :

Nous ne pouvons pas laisser la concurrence nous voler notre “pole position”. Nous allons donc moderniser le produit. Mais plutôt que d’investir des sommes colossales dans sa réécriture, nous le ferons évoluer petit à petit, tout en améliorant la qualité. Et la qualité chez nous, c’est l’affaire du département QA. Nous allons revoir sa mission.

L’équipe QA, composée de 5 personnes, part en formation aux frameworks à nom de conifères et de cucurbitacées. Objectif : automatiser les tests de non-régression.

Que sont les tests de non-régression ? Dans cette entreprise – précisons, car il existe probablement une définition des TNR par entreprise – il s’agit des tests que l’équipe QA effectue afin de s’assurer que le produit fonctionne toujours après livraison d’une nouvelle version significative.

Comment s’y prend elle ? Chaque testeur dispose de comptes dans l’environnement de recette, et déroule des cas d’usage représentatifs en s’appuyant sur une copie des données de production. La liste de ces cas, ainsi qu’une description succincte des actions et vérifications attendues, se trouvent dans une grande feuille de calcul. Certains testeurs maîtrisent SQL et manipulent la base pour y constituer des jeux de test.

Ce processus, loin de permettre la vérification du produit sur l’ensemble de ses comportements possibles, permet de détecter seulement 20% des problèmes rencontrés. Chaque problème fait l’objet d’un ticket + une discussion en comité QA/DEV + une tentative de reproduction + une correction + une re-soumission. Les 80% restants sont interceptés par l’équipe SUPPORT (et donc détectés par les clients). Certains tickets résident dans jirotrella depuis plus d’un an.

La nouvelle stratégie est la suivante :

  • l’équipe QA démultiplie sa productivité grâce aux tests autos
  • l’équipe de DEV réalise les évolutions fonctionnelles
  • l’équipe QA “couvre” l’équipe de DEV contre les régressions

L’équipe QA encaisse habituellement ses pics de charge en réduisant le nombre et la portée des cas de test. Une réduction tacitement admise par le reste de la Tech. Les défauts indétectés sont simplement (et tacitement) reportés vers la PROD.

Mais l’automatisation des tests est une routine fastidieuse et semée d’embûches. L’équipe QA est rapidement surchargée, puis débordée.

Le conflit s’est déplacé d’un état de l’art stratégiquement inadapté vers un problème de ressources (manque de temps)

Stay Tuned

conflict-moved-elsewhere

Stay Tuned ! Publié sur Linked In le 15/09/2024