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èse | Test réalisé en phase de recette | Nombre de J/h en préprod | Argumentation |
| & 1 | Oui | 4 | Dans 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 1 | NON | 4 | |
| 2 | Oui | 6 | Les TNRs doivent être mis à jour avec les nouvelles fonctionnalités |
| 2 | Non | 7 | Nous 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 |
| 3 | OUI | 3 | Les 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 |
| 3 | Non | 3 |
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 Responses
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.
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 !