J'ai été à jouer avec l'Automation de Test depuis 15 ans, et une chose qui revient sans cesse est de savoir comment mesurer le succès de l'automatisation.
Au départ, nous avons utilisé pour mesurer le % de cas de test qui ont été automatisés. Nous avons fixé un objectif - X % de cas de test qui doit être automatisé dans un laps de temps, et puis nous avons utilisé s'y prendre pour mesurer les progrès, de tendance et de se sentir bien quand nous avons battu l'objectif.
Nous avons compris dès que cela a des limites sérieuses. Par exemple, nous pourrions avoir 70 % des cas de test qui ont été automatisés, mais lors d'un cycle particulier de régression, nous pouvons exécuter seulement 25 % - parce que d'autres n'étaient pas pertinentes pour ce cycle de régression. Très vite, nous nous sommes retrouvés avec quelques intéressantes (lire « chauffée ») des discussions avec les intervenants sur comment 70 % ramené à 25 % et ainsi de suite. automaticiens utilisés pour se plaindre que les intervenants ne comprenais pas ce qui est impliqué avec l'automatisation des tests et des tests de régression. Ainsi, à la fin - ni nous, ni les parties prenantes étaient heureux avec la situation.
Il n'a pas à être de cette façon. Revenons à l'essentiel.
Pourquoi faisons-nous Automation de Test ?Pour améliorer l'efficacité de l'essai.
Okay - donc, ce que cela signifie ?Cela signifie que nous pouvons sauver effort, temps et peut-être aussi bien.
Très bien - si c'est ce qui est la valeur que nous sommes censés pour obtenir d'automatisation des tests - ils pourquoi nous ne mesurons que ?
Au lieu de mesurer le % de cas de test qui ont été automatisés, test automation métriques devraient se concentrer sur les économies que nous recevons de l'exécution de ces cas de test - en termes de temps et d'efforts ?
Il semble simple. Mais calculer les économies de temps et d'efforts par le biais de l'exécution du test automation est tout sauf simple. Pour arriver à l'épargne -
Nous avons besoin de savoir combien de temps et effort qu'il faut pour exécuter chaque cas de test manuel
Nous avons besoin que capturer quelque part
Nous devons ensuite cette carte pour les scripts d'automation de test réel qui ont été exécutés et calculez ce.
Il faudra quelques efforts, en collaboration avec l'équipe de test manuel pour arriver à cela.
Convenu. Mais alors le % de cas de test qui ont été automatisés n'apportait pas out la valeur que l'automatisation des tests devait pour atteindre, il est donc logique de le changer au système métrique valeur d'Automation de Test.
Nous avons fait exactement cela et commencé à mesurer les économies d'automation de test. Croyez-moi, c'était douloureux de recueillir ces renseignements - l'outil de gestion de test que nous utilisions n'appuyait pas facilement saisir l'information, agrégation il et en nous donnant la métrique ainsi que de la tendance. Nous avons dû compter sur notre bon vieil ami MS Excel pour arriver à cela. Parfois, les économies sont réalisées au cours de plusieurs cycles d'essai.
Mais les résultats ne valaient la douleur. Une fois, nous sommes passés de la métrique à l'épargne de l'automatisation, nous sommes passés du comportement dans la bonne direction.Puisque nous calculons les économies de temps et d'efforts sur ce que nous exécutons, tester des automaticiens fortement concentrés en automatisant les cas de test -
Qui ont été d'effort intensif, qui a donné les meilleures économies
Qui ont été entreprises critiques, puisque des cas de test hautement prioritaire exécutés plus souvent pendant le cycle de régression
Cas de test qui devait être exécuté à travers différentes configurations - OS, navigateur, DB, devicecombinations - car ils ont entraîné des économies énormes.
Les gens ont tendance à aligner leurs comportements basés sur ce qui est mesuré. Lorsque nous mesurons les bonnes choses, nous permettons les bons comportements. S'il vous plaît partager ce que sont les métriques qui fait meilleur sens des affaires et comment il a changé le comportement dans la bonne direction. Merci