Menu

Tests exploratoires vs tests scriptés: qui gagne?

exploratory testing vs scripted testing

Essayez Notre Instrument Pour Éliminer Les Problèmes

Avantages concrets des tests exploratoires:

Traditionnellement, les tests logiciels ont été une activité très rigide, mais ces dernières années, on s’est éloigné des tests basés sur des scripts. Essais exploratoires , qui est davantage axée sur le contexte, est apparue au premier plan. C'est parce que cela donne aux testeurs plus de liberté pour exploiter leurs compétences et leurs connaissances, et cela les rend responsables de l'optimisation de la valeur de leur propre travail.

Tests exploratoires vs tests scriptés

Tout le monde n'est pas convaincu de la valeur des tests exploratoires. Le manque perçu de formalité et l'accent mis sur la responsabilité personnelle peuvent déclencher l'alarme. Mais cette préoccupation repose en grande partie sur une mauvaise interprétation des tests exploratoires. Il ne s’agit pas de jeter des règles par la fenêtre et de tester au hasard, c’est en fait très structuré et systématique. Et c'est aussi très efficace.

Les sceptiques veulent des preuves concrètes qu’il fait plus qu’améliorer le moral des testeurs. C’est pourquoi nous avons décidé de mener une étude qui opposerait directement les tests exploratoires basés sur le contexte à une approche de test basée sur des scripts. Les résultats étaient très intéressants, comme vous êtes sur le point de le découvrir.

Ce que vous apprendrez:

qu'est-ce qu'un fichier .jnlp

Équipes de test basées sur le contexte (tests exploratoires) et scripts

Deux équipes, deux approches:

Nous avons commencé par diviser les testeurs en deux équipes de trois. Les testeurs de chaque équipe possédaient les mêmes connaissances applicatives comparables. Les mêmes définitions pour gravité du défaut (majeur, mineur) ont été établis pour les deux équipes. Les deux équipes ont reçu la même version d'application. Une équipe («scriptée») appliquerait une approche de test traditionnelle basée sur des scripts et l'autre équipe («exploratoire») adopterait une approche de test basée sur le contexte. Les activités de test seraient divisées en deux phases de trois jours chacune.

L'équipe basée sur des scripts identifié cinq workflows métier à tester et généré 15 cas de test. Les cas de test avaient une portée limitée, les testeurs n’avaient donc aucune liberté pour explorer en dehors des limites du script.

L'équipe exploratoire créé deux cartes mentales visuelles , l'un qui identifiait la couverture des tests et les chartes de test, et l'autre couvrant les composants / modules du produit. Le processus a produit 24 chartes de test au total. Les chartes définies étaient de haut niveau et permettaient une interprétation contextuelle, élargissant la portée de la session de test pour les testeurs.

La phase 1:

L'équipe scénarisée a réussi à terminer 6 cas de test dans les trois jours alloués. Ils ont signalé 6 défauts majeurs pendant cette période.

L'équipe exploratoire a réussi à réaliser 13 sessions de test allant de 30 minutes à 180 minutes chacune. Ils ont signalé 10 défauts majeurs et 5 défauts mineurs.

test scripté vs test exploratoire 1

Il est intéressant de noter que l'équipe exploratoire a signalé tous les défauts signalés par l'équipe scénarisée.

Phase 2:

L'équipe scénarisée a réussi à terminer 9 cas de test cette fois. Ils ont rapporté 10 défauts majeurs et 8 défauts mineurs .

L'équipe exploratoire a réalisé 18 sessions. Ils ont rapporté 14 défauts majeurs et 5 défauts mineurs.

test scripté vs test exploratoire 2

Au cours de la phase 2, l’équipe chargée du scénario a signalé 2 défauts majeurs et 1 défaut mineur que l’équipe exploratoire n’a pas trouvé, mais l’équipe exploratoire a signalé 3 défauts majeurs et 1 défaut mineur que l’équipe scénarisée n’a pas signalés.

Cela ne prend pas en compte la complexité relative des flux de travail qui peuvent avoir été choisis par les testeurs au cours de ces sessions et des cas de test, mais nous pouvons toujours tirer des conclusions intéressantes.

Qu'est-ce que ça veut dire?

Il semblerait qu'une approche exploratoire, ainsi que la responsabilité et la flexibilité qu'elle engendre, aboutissent à une forme de test plus efficace. Il peut être possible de couvrir plus de terrain en développant et en adaptant vos chartes de test au fur et à mesure que les sessions de test progressent, en fonction de ce qui a du sens dans le contexte. Cette liberté fait défaut dans les tests basés sur des scripts et peut empêcher la découverte de défauts.

syntaxe python vs c ++

S'en tenir rigoureusement aux scripts crée des chemins usés, et ce n'est qu'en s'écartant de ces chemins que nous allons découvrir tous les défauts. Comme mentionné à plusieurs reprises par des leaders d'opinion au sein de la communauté des tests, «Si vous imaginez un produit comme un champ de mines terrestres et que chaque mine terrestre est un défaut, alors il est assez clair que suivre le même chemin encore et encore n'est pas le moyen de les trouver. tout.'

En fin de compte, aucune des deux approches n'était parfaite, car chaque équipe a signalé des défauts que l'autre équipe n'a pas identifiés, même si l'équipe exploratoire a rapporté plus, dans l'ensemble.

De façon réaliste, cela peut signifier que la bonne approche, pour ce qui est de se rapprocher le plus possible des défauts «minimes», sera un mélange des deux. Mais, il y a de nombreux avantages avec le approche contextuelle qui parlent en sa faveur. Cela nécessite moins de temps de préparation, moins de documentation, identifie les problèmes plus tôt et met les testeurs au défi d'utiliser des compétences analytiques et un raisonnement déductif. Ils acquièrent une compréhension plus profonde et plus approfondie du produit et agissent vraiment en tant que défenseurs de l'utilisateur final.

Conclusion

Le résultat final démontre que les tests exploratoires conduisent à signaler davantage de défauts avant la mise en service, ce qui se traduit par un meilleur produit livré par l'équipe, et finalement, testeurs plus satisfaits / satisfaits qui sont tous des résultats souhaitables, de quelque manière que vous les considérez.

A propos de l'auteur

Mush Honda est directeur QA chez Technologie KMS , un fournisseur de services informatiques tout au long du cycle de vie du développement logiciel avec des bureaux à Atlanta, GA et Ho Chi Minh City, Vietnam. Il était auparavant testeur chez Ernst & Young, Nexidia, Colibrium Partners et Connecture. Les services KMS comprennent la gestion des applications, les tests, le support, les services professionnels et l'augmentation du personnel.

Êtes-vous d'accord? N'hésitez pas à poster vos commentaires, questions ci-dessous.

Tutoriel PREV | SUIVANT Tutoriel n ° 4: Tests exploratoires avec HP Sprinter

lecture recommandée

^