(du cycle de l'histoire du testeur )Bonjour à tous. Comme vous l'avez peut-être remarqué, l'intensité du lancement de cours en OTUS augmente chaque mois, et en mars il y en a surtout beaucoup. Aujourd'hui, nous voulons coïncider avec le lancement du cours
"Automatisation des tests Web" , qui commence à la mi-mars. Bonne lecture.
Je vois encore de nombreux testeurs qui parlent du nombre de bogues et de vulnérabilités trouvés, comme mesure du succès des tests. Récemment, j'ai vu un autre point de vue, qui a déclaré que l'essentiel est en fait dans la qualité des erreurs, mais pas dans leur quantité. Cependant, avec cette mesure, il convient également d'être prudent. Nous allons maintenant en parler.
L'idée principale est que la méthode de test est déterminée par le type d'erreurs que vous devez rechercher.
J'ai déjà parlé de certains aspects du sujet d'aujourd'hui plus tôt dans la
conversation sur la chasse aux bogues . Je ne veux pas me répéter, je vais donc essayer d'être bref. Je vais formaliser ma pensée de thèse et en relation avec l'équipe dans laquelle je travaille.
Ce qui est important pour moi dans les tests, c'est l'impact sur les utilisateurs afin qu'ils prennent les bonnes décisions plus rapidement. Pour ce faire, vous devez utiliser une boucle de rétroaction étroite pour raccourcir le temps entre les développeurs qui font une erreur et la corrigent par la suite. Ces erreurs sont des domaines où diverses qualités - comportement, performances, sécurité, convivialité, etc. - soit absent, soit aggravé.
Ce n'est certainement pas mesuré par le nombre d'erreurs trouvées, mais la nature de l'erreur joue un rôle. Ma tâche consiste à trouver les erreurs qui menacent le plus l'intégrité et la qualité du développement. Cela peut probablement être attribué à la «qualité» des erreurs, c'est-à-dire que ces erreurs sont d'autant plus importantes qu'elles menacent l'intégrité.
La clé d'une correction d'erreur efficace, à mon avis, est de trouver ces erreurs le plus rapidement possible, idéalement dès qu'elles apparaissent. Bien que de mon point de vue, même la «qualité de l'erreur» est loin d'être la mesure la plus élevée.
Nous attachons tant d'importance à la qualité de l'erreur, mais est-ce vraiment que leur nombre est généralement insignifiant?
En fait, le nombre d'erreurs est important si vous êtes très déterminé à réduire le temps de recherche. Disons que le système a 10 bogues critiques. Et j'en ai trouvé très vite deux, et c'est vraiment cool! Deux erreurs critiques ont été détectées avant l'introduction du produit. Mais je n'en ai pas trouvé d'autres avant le déploiement. Cela signifie que 8 erreurs critiques n'ont pas été trouvées. Dans ce cas, le nombre d'erreurs est une mesure clé, même si nous ne l'avons pas compris à ce moment-là.
Il est important de penser d'une manière légèrement différente. Le nombre d'erreurs ou leur qualité n'est pas aussi important que les mécanismes par lesquels elles se produisent et, par conséquent, les mécanismes de leur recherche. De nombreuses options sont disponibles:
- Des mécanismes qui sont bons pour trouver des bugs, mais qui fonctionnent trop longtemps;
- Mécanismes qui détectent mal les bogues, mais fonctionnent très rapidement;
- Des mécanismes «enclins» à remarquer des bugs d'un certain type, mais en même temps à ne pas en voir d'autres;
- Des mécanismes qui ne sont pas très appréciés des testeurs, mais qui fonctionnent vraiment et ne les utilisent pas, car personne ne les connaît dans l'équipe, c'est pourquoi ce qui peut être trouvé reste à trouver;
- Des mécanismes qui peuvent fonctionner correctement et rapidement, capables de trouver de nombreuses erreurs, mais leur réponse est si floue que les gens ne peuvent pas prendre de décisions en fonction de leur sortie.
Il est important de se concentrer sur ces aspects, pas moins que sur d'autres, car cela permet de contourner certains problèmes traditionnels. Par exemple, ceux lorsque vous avez exécuté une centaine de tests, mais n'avez trouvé aucun bug. Et cela peut être bien, mais seulement s'il n'y a vraiment aucune erreur. Mais s'ils existent, c'est mauvais si les méthodes de test appliquées ne peuvent pas les identifier. Ou la situation lorsque je lance un tas de tests, je trouve des erreurs mineures, tout en sautant les plus difficiles.
Mon équipe et moi devons prendre certaines décisions en fonction des tests effectués. Cela signifie que nous devons croire ce que les résultats des tests nous sont racontés, en conséquence, nous devons d'abord faire confiance aux méthodes de détection qui sont mises en œuvre dans ces tests.
Certaines méthodes de détection proviennent des tests eux-mêmes, en gros, de ce qu'ils recherchent et de leur apparence. D'autres méthodes de détection devraient être inhérentes à l'environnement lui-même et à la testabilité, que nous définissons afin de déterminer la probabilité et la possibilité, en principe, que les tests provoquent une erreur, si elle existe.
À la fin de mes brèves réflexions, je tiens à souligner que je ne détermine le succès des tests par aucun facteur spécifique. Mais si vous voulez toujours le déterminer par vous-même, vous devez le déterminer non pas par le nombre d'erreurs et de vulnérabilités trouvées et non par la qualité de ces erreurs, mais par sa capacité spécifique des mécanismes de test à les détecter.
J'ai trouvé que les testeurs inexpérimentés, après avoir lu cette note, ne verront pas de différence significative entre l'idée de détecter les capacités et les résultats obtenus après avoir mis en évidence ces caractéristiques. Quant aux spécialistes, ils devraient les différencier extrêmement.
Étant en mesure de comprendre et de formuler cette différence, les testeurs peuvent aller au-delà des différences inutiles (uniquement l'opinion de l'auteur) entre «vérification» et «test» et au lieu de cela construire une compréhension constructive des méthodes de détection, à la fois humaines et automatisées, qui permettent des tests pour aider les gens à prendre de meilleures décisions plus rapidement.
Voici un matériel apparemment simple, mais très utile. Selon la tradition établie, nous attendons vos commentaires et nous vous invitons à
un webinaire ouvert , qui sera organisé le 11 mars par
Mikhail Samoilov , le principal outil d'automatisation des tests du Groupe IB.