La taverne du testeur

Une nouvelle vision pour livrer plus rapidement en prod – Ismail JAMIL

Les pratiques de tests doivent évoluer en fonction du contexte du projet, du produit, des contraintes de temps.

Les standards du test préconisent :

  • Tester en phase d’intégration (se baser uniquement sur US ou bug)
  • Tester en recette (concerne de test la fonctionnalité de bout en bout)
  • Tester en phase de pré-prod (Environnement pour faire en principe des TNRS)

Adaptons notre stratégie en fonction du contexte en prenons en compte, l’aspect coût, qualité

La principale occupation de tous les clients reste re répondre à cette question :

Comment avoir la meilleure qualité avec le moindre cout ?

Tester en phase d’intégration est une étape indispensable dans tous types de projet et n’importe quel type de ticket (Bug, US) 

Hypothèse 1 : En agile, une partie de la fonctionnalité ou la totalité de la fonctionnalité peut être développée

  • Supposons que dans un sprint de 2 Semaines nous avons développé 20 US (les 20 US concernent un bout de fonctionnalité)
  • Dans la squad nous avons 2 testeurs pour 7 développeurs
  • La phase de bout en bout nécessite 2J avec 2 testeurs soit 4 jH, 
  • Soit un cout total (4*350)= 1400€

Hypothèse 2 : Supposons que dans un sprint de 2 Semaines nous avons développé 20 US (les 20 US concernent des fonctionnalités terminées avec des cas complexes à tester)

  • Dans la squad nous avons 2 testeurs pour 7 développeurs
  • La phase de bout en bout nécessite 3J avec 2 testeurs soit jH, 
  • Soit un cout total (6*350)= 2100€

Hypothèse 3 : Dans un sprint nous avons 30 bugs et aucune US :

  • Dans la squad nous avons 2 testeurs pour 7 développeurs
  • La phase de bout en bout en recette nécessite 4J avec 2 testeurs soit 8 ETP, 
  • Soit un cout total (8*350) = 2800€

Prenons du recul face à la situation :  Passage directement en pré-prod

Partons sur le principe :

  • La préprod est une copie de la prod à un instant donné
  • Les environnements sont fiables
  • Les données sont iso -prod
  • Pour chaque US, on a rédigé les cas de tests détaillés
HypothèseTest réalisé en phase de recetteNombre de J/h en préprodArgumentation
&              1Oui4Dans cette hypothèse, nous allons gagner en temps et en cout, les TNRs seront les mêmes que si nous sommes passés par la phase de recette
1               1NON4
2Oui6Les TNRs doivent être mis à jour avec les nouvelles fonctionnalités
2Non7Nous avons 1 jours de plus de TNR en préprod pour palier à l’aller / retour en QA et dev sur le fait que nous ne sommes pas passé par la phase de recette
3OUI3Les bugs doivent être couvert par les TNRs , de ce fait une mise à jour des TNRs est nécessaire  . Donc un gain de temps 8 J/H passé en phase de recette
3Non3

Seule l’hypothèse 2 montre allongement des TNRS en préprod, mais le fait de ne pas passer par la phase de recette permet un gain de temps global de 5j/H.

Conclusion

  • Chaque Test Manager / Lead QA en fonction du contexte adaptera sa stratégie en fonction du contexte client et les paramètres qui disposent.
  • Chaque méthode doit être challengée et rien ne doit être figé 
  • Il est possible de proposer des solutions adaptées même si elles proposent une vision différente que celles des standards actuels du test

A propos de l’auteur : Ismail Jamil

Je suis Ismail Jamil Test manager et passionné par le test, j’ai découvert les tests en 2012 lors d’un stage. Après ce stage les tests sont devenus plus qu’un métier mais une passion. Ma spécialité est la création de cellules QA from scratch.

2 réponses

  1. Merci Ismail pour cet article détaillé et pertinent ! Il est crucial de réévaluer constamment nos stratégies de test en fonction du contexte spécifique de chaque projet. La flexibilité et l’adaptation sont essentielles pour optimiser à la fois la qualité et les coûts. J’apprécie particulièrement les hypothèses et les exemples concrets que tu as partagés, ils illustrent bien les défis et les solutions possibles. Continuons à explorer et à proposer des approches innovantes pour améliorer nos pratiques de test.

  2. Cet article souligne l’importance de l’adaptabilité des pratiques de test avec des exemples et scénarios concrets et prend une approche pragmatique en se concentrant sur l’optimisation des coûts et de la qualité, ce qui est une préoccupation majeure pour les clients.
    Il met en évidence le fait de ne pas rester figé sur des méthodes standards et de toujours chercher à challenger et adapter les pratiques de test. Cette flexibilité est cruciale pour répondre aux besoins spécifiques des projets et des clients.
    Merci Ismail pour cet écrit !

Laisser un commentaire

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

culture générale

A la recherche de la qualité perdue: les plages de velours et les rocks éternels

Rappels des chapitres précédents L’application « New Soft » autrefois reconnue pour sa grande qualité n’est maintenant plus que l’ombre d’elle même et est envahie de bugs. Afin de retrouver la qualité perdue les représentants de l’application on nommé une communauté (les fameux Antoine le Berserker (surnommé BA), Délphine la Valkyrie (surnommée

Lire la suite »
Avenir

[Programmez] Comment prédire et prévenir les anomalies ?

La prévention des bugs, la capacité de les anticiper et de les détruire avant même qu’ils n’apparaissent est un Graal pour un bon nombre de testeurs, de développeurs… mais aussi de responsables de SI ou de sociétés éditrices de logiciel. Non, je ne parle pas de Minority Report mais plutôt

Lire la suite »