Ce que j’ai découvert, c’est que la couverture est un bon début, et peut être suffisante pour la plupart des équipes (parmi les équipes qui ne peuvent pas exécuter tous leurs tests rapidement à chaque construction). Cependant, ajouter quelques autres facteurs de sélection (ou heuristiques) et appliquer quelques poids peut vous faire aller un peu plus loin.
Certaines heuristiques que j’ai utilisées dans le passé pour la priorisation/sélection des tests incluent :
- Le test a-t-il déjà trouvé un bug ? Certains tests sont efficaces pour détecter des bugs dans le produit. Je donne plus de poids à ces tests.
- Quand le test a-t-il été exécuté pour la dernière fois ? Si un test a été exécuté tous les jours pendant un an sans échec, je ne lui accorde pas beaucoup de poids. Nous, testeurs, sommes toujours paranoïaques à l’idée que le moment où nous choisissons de ne pas exécuter un test, une régression apparaîtra. Cette heuristique pondérée contribue à résoudre le dilemme de l’exécution du test qui ne échoue jamais par rapport à la peur de manquer la régression.
- La stabilité du test : Si vous n’avez jamais de tests instables, passez cette étape. Pour tous les autres, il est logique d’exécuter mes tests qui retournent de faux positifs moins fréquemment (ou à la fin de la série de tests).
- Combien de temps prend le test ? Je donne plus de poids aux tests qui s’exécutent plus rapidement {…}
Continuez à lire l’article complet ici sur Tooth of the Weasel, des notes et des critiques sur les logiciels et la qualité des logiciels.
À PROPOS DE NOTRE EXPERT Q-LEAP QUI RECOMMANDE CET ARTICLE
Stefan Papusoi est un spécialiste des tests chez q-leap. En tant que testeur axé sur le contexte et exploratoire, il accroît constamment son expérience en matière de tests, d’automatisation de scripts, et de gestion et d’amélioration des processus de test.
