Quand arrêter les tests (critères de sortie dans les tests logiciels)

when stop testing

Critères de sortie dans les tests:

«Bien commencé, c'est à moitié fait» - S'applique partout, même les tests de logiciels.

Nous voyons souvent des testeurs de logiciels très enthousiastes au début du projet. Nous créons documents de test tels que la stratégie de test, le plan de test ou les cas de test avec empressement et enthousiasme.

Ensuite, nous arrivons à tester le logiciel avec un BANG! Ceci n'est amplifié que par les défauts intéressants que nous trouvons au début du projet. Les résoudre ne fera qu'ajouter à notre accomplissement.

Au fur et à mesure que nous trouvons de nombreux défauts et terminons la première exécution, nous passons à la phase suivante. Quand nous arrivons à la deuxième manche, nous nous détendons un peu et comme la tendance humaine générale s'ennuyer de tester la même chose dans la deuxième manche.

java ajout d'éléments à un tableau

De nombreux testeurs estiment que cela devient travail monotone dans les exécutions ultérieures et commencez à perdre tout intérêt à tester le même logiciel encore et encore. Lorsque nous atteignons, peut-être la troisième manche, une question commence à nous hanter et c'est 'Quand arrêter de tester le logiciel?'

Je parie que vous avez dû ressentir la même chose et demander: «Quand arrêter les tests?», Au moins une fois. Je dirais que la question est 'Quand, où et comment arrêter les tests?' :)

Conceptuellement, nous avons lu et de nombreux testeurs pensent qu'il ne peut y avoir de condition ou d'équation spécifique pour décider 'Quand arrêter les tests?' Il y a un certain nombre de facteurs à considérer avant de conclure sur cette question.

Dans l’article d’aujourd’hui, j’aimerais partager mes réflexions sur la façon de conclure les activités de test lorsque nous atteignons un point de notre cycle de test où nous pouvons dire que ces tests sont suffisants. Nous le ferons à l'aide de quelques exemples réels dans un cycle de test typique.

Ce que vous apprendrez:

• Quand est-ce assez de tests?
• S'arrêter lorsque tous les défauts sont détectés: est-ce possible?
• Décision d'arrêter les tests: critères de sortie
• Qu'est-ce que les critères d'achèvement ou de sortie?
• Que doit contenir les critères de sortie?
• Le test peut être arrêté lorsque:
• Conclusion:
• lecture recommandée

Quand est-ce assez de tests?

Quand pouvons-nous dire que autant de tests sont suffisants? Les tests peuvent-ils être terminés?

Afin de répondre à ces questions, nous devrons analyser les activités de test du début à la fin. Veuillez noter que - je vais définir ces activités en termes de profanes - pas d’une manière technique sophistiquée.

Considérons que vous commencez à tester un nouveau projet.

Activités initiales:

• L'équipe de test reçoit les exigences.
• L'équipe de test démarre Planification et la conception.
• Les documents du test initial sont prêts et révisés.

Essai n ° 1)

• L'équipe de test démarre l'exécution du test une fois qu'ils reçoivent le produit développé.
• Pendant la phase de test, ils exécutent différents scénarios afin de casser le logiciel et de trouver de nombreux défauts. (De plus, le taux de défauts ici est plus élevé car l'application est nouvelle et est en cours d'évaluation pour la toute première fois.)
• Les défauts sont corrigés par les développeurs et renvoyés à l'équipe de test pour un nouveau test.
• L'équipe de test effectue un nouveau test des défauts et exécute une régression.
• Une fois que la plupart des défauts de gravité élevée sont résolus et que le logiciel semble stable, l'équipe de développement publie la prochaine version.

Essai n ° 2)

• L'équipe de test commence la deuxième série de tests et des activités similaires sont exécutées en tant que série 1.
• Dans ce processus lors de la deuxième série de tests, quelques défauts supplémentaires sont détectés.
• Les défauts sont corrigés par les développeurs et renvoyés à l'équipe de test pour un nouveau test.
• L'équipe de test re-teste les défauts et exécute régression .

Cela peut durer éternellement. Exécutez 3, puis 4 jusqu'à ce que tous les défauts du logiciel soient détectés et que le logiciel devienne sans bogue.

Si nous voulons dessiner un organigramme pour ces activités, il ressemblera à peu près à ci-dessous:

À partir de l'organigramme ci-dessus, nous pouvons clairement conclure que les tests peuvent se poursuivre jusqu'à ce que tous les défauts du logiciel soient détectés.

Mais la question est: est-il possible de trouver chaque défaut du logiciel? Essayons de trouver la réponse à cette question à un million de dollars :).

S'arrêter lorsque tous les défauts sont détectés: est-ce possible?

La plupart des logiciels sont complexes et ont une portée de test énorme. Il n'est pas impossible de trouver tous les défauts du logiciel mais cela prendra une éternité.

Même après avoir trouvé de nombreux bogues dans le logiciel, personne ne peut garantir que le logiciel est sans défaut maintenant. Il ne peut pas y avoir de situation où nous pouvons affirmer en toute confiance que nous avons terminé les tests, trouvé tous les défauts du logiciel et qu'il n'y a plus de bogues.

De plus, le but des tests n'est pas de trouver tous les défauts du logiciel. Le but des tests logiciels est de prouver que le logiciel fonctionne comme prévu en le cassant ou en trouvant un écart entre son comportement actuel et son comportement attendu.

Il y a des défauts illimités dans le logiciel et il est donc impossible de le tester tant que tous les défauts ne sont pas trouvés car nous ne pouvons jamais savoir quel défaut est le dernier. La vérité est que nous ne pouvons pas dépendre de la recherche de tous les défauts du logiciel pour conclure nos tests.

Honnêtement parlant, les tests sont sans fin et les cycles de test se poursuivront jusqu'à ce qu'une décision soit prise quand et où s'arrêter. Maintenant, il devient encore plus compliqué de prendre la décision d'arrêter les tests. Si «s'arrêter lorsque tous les défauts sont détectés» n'est pas le critère pour arrêter les tests, sur quelle base faut-il décider?

Décision d'arrêter les tests: Critère de sortie

Essayons maintenant de comprendre - Quels sont les facteurs les plus importants à prendre en compte lors de la conclusion des activités de test? Je pense que la décision d'arrêter les tests dépend principalement de Temps, budget et étendue des tests.

L'approche la plus courante consiste à s'arrêter lorsque le temps / budget est épuisé ou que tous les scénarios de test sont exécutés. Cependant, avec cette approche, nous ferons des compromis sur la qualité des tests et cela ne donnera pas assez de confiance sur le logiciel; Comment?

Voyons voir avec unExemple.

Scénario de test:

Supposons que vous testiez un module logiciel. Un certain budget vous a été alloué pour le couvrir. Les délais du projet sont d'un mois. Le total des scénarios de test est de 200. Vous êtes le seul à tester ce module.

Scénario 1)

Semaine 1: Vous trouvez le défaut showstopper / gravité 1 le jour 1 et l'ensemble du test est bloqué pendant 3 jours. Par conséquent, vous ne pouvez exécuter aucun des scénarios tant que le défaut de gravité 1 n'est pas résolu. Après avoir perdu 3 jours, le bloqueur est résolu et vous continuez votre exécution.

À la fin de la semaine, vous terminez 20 scénarios avec quelques hauts plus importants défauts prioritaires .

Semaine 2: Vous commencez à tester le logiciel en vous concentrant davantage sur la recherche de défauts. Vous ouvrez quelques autres défauts de gravité 1, de gravité 2 et de gravité 3 au cours de la deuxième semaine et à la fin de la semaine, vous êtes en mesure de couvrir 70 scénarios.

Semaine 3: Au début du 3^rdsemaine, vous obtenez tous les défauts de haute priorité résolus, donc avec l'exécution des scénarios en attente, vous devez maintenant tester à nouveau tous les défauts qui ont atterri dans le seau de test. En poursuivant vos progrès, vous couvrez 120 scénarios avec des défauts supplémentaires.

À ce moment-là, tous les défauts de haute priorité sont déjà détectés et signalés. Il ne vous reste donc plus que les défauts de gravité 3 à trouver.

Semaine 4: À la semaine 4, vous devez tester à nouveau la plupart des défauts ouverts et les 80 scénarios restants. Avec cela d'ici la fin de la semaine 4, vous êtes en mesure de terminer jusqu'à 180 scénarios avec tous les défauts de priorité élevée et moyenne corrigés et retestés.

Mettre ces informations sous forme tabulaire:

Devriez-vous vous arrêter ici?

La raison pour laquelle tu as épuisé Temps de test complètement et ont signalé et corrigé la plupart des défauts hautement prioritaires. L'arrêt à ce stade vous donnera-t-il confiance dans le logiciel? Pas vraiment pour les raisons ci-dessous:

• Les scénarios ne sont pas exécutés complètement.
• Peu de flux ne sont même pas testés une seule fois.
• Tous les scénarios qui sont couverts ne sont exécutés qu'une seule fois.
• Le logiciel présente encore des défauts.
• La régression n'est pas couverte.

Scénario n ° 2)

Semaine 1: Vous trouvez un défaut de gravité 1 le jour 1 et le test complet est bloqué pendant 3 jours. Par conséquent, vous ne pouvez exécuter aucun des scénarios tant que le défaut de gravité 1 n'est pas résolu. Après avoir perdu 3 jours, le bloqueur est résolu et vous continuez votre exécution.

À la fin de la semaine, vous terminez 20 scénarios avec quelques défauts supplémentaires. Cette semaine reste la même que le scénario 1.

Semaine 2: Vous ouvrez quelques autres défauts de gravité 1, de gravité 2 et de gravité 3 au cours de la deuxième semaine, mais l'objectif est de couvrir davantage de scénarios pour couvrir l'arriéré de la semaine 1. À la fin de la semaine, vous êtes en mesure de couvrir 120 scénarios.

Semaine 3: Au début du 3^rdsemaine, vous obtenez tous les défauts ouverts résolus, donc avec l'exécution des scénarios en attente, vous devez maintenant tester à nouveau tous les défauts qui sont déposés dans un bucket de test. Toujours avec de bons progrès à la fin, le nombre de scénarios achevés devient 200 avec des défauts supplémentaires.

Désormais, vous ne pouvez signaler que les défauts de gravité 2 et de gravité 3.

Mettre ces informations sous forme tabulaire:

Devriez-vous vous arrêter ici?

meilleure entreprise de récupération de données de disque dur

Tu as couvert complètement tous les scénarios de test une fois et ont ouvert quelques défauts majeurs. L'arrêt à ce stade vous donnera-t-il confiance dans le logiciel?

Pas vraiment pour les raisons ci-dessous:

• Tous les scénarios ne sont exécutés qu'une seule fois.
• Le logiciel présente encore de nombreux défauts majeurs.
• La régression n'est pas couverte.

Nous pouvons voir que la qualité est compromise dans les deux scénarios ci-dessus. La meilleure approche sera de trouver un point où tous les facteurs du scénario 1 et du scénario 2 sont couverts et où la qualité n'est pas non plus compromise. Pour y parvenir, nous devrons définir certains critères au début des tests.

Ces critères sont appelés critères d'achèvement ou de sortie. C'est la réponse à notre question - «Quand arrêter les tests?».

Qu'est-ce que les critères d'achèvement ou de sortie?

Les critères de sortie sont évalués à la fin du cycle de test et sont définis dans le plan de test. C'est l'ensemble des conditions ou activités qui doivent être remplies pour conclure les tests.

Les critères de sortie définissent la quantité de tests suffisante et le moment où les activités de test peuvent être déclarées terminées. Couverture et les critères d'achèvement sont combinés pour définir les critères de sortie des tests.

Que doit contenir les critères de sortie?

Idéalement, les critères de sortie ou d'arrêt sont définis en combinant divers facteurs et sont donc uniques dans tous les projets. Cela dépend des exigences du projet et doit donc être défini lors de la planification des tests; au début du projet. Les paramètres qui y sont définis doivent être quantifiés autant que possible.

Vous trouverez ci-dessous quelques conseils à prendre en compte lors de la définition des critères de sortie en cas de test fonctionnel ou système. Vous pouvez combiner quelques-uns ou tous les facteurs ci-dessous tout en décidant où arrêter les tests selon les besoins de votre projet.

Le test peut être arrêté lorsque:

Conditions:

• La couverture des exigences à 100% est atteinte.

Défauts:

• Le nombre de défauts défini / souhaité est atteint.
• Tous les défauts Show Stopper ou Blockers sont corrigés et aucun défaut Critique / Gravité 1 connu n'est à l'état Ouvert.
• Tous les défauts de haute priorité sont identifiés et corrigés.
• Le taux de défaut tombe en dessous du taux acceptable défini.
• Très peu de défauts de priorité moyenne sont ouverts et ont une solution de contournement en place.
• Très peu de défauts ouverts de faible priorité qui n'affectent pas l'utilisation du logiciel.
• Tous les défauts de haute priorité sont retestés et fermés et les scénarios de régression correspondants sont exécutés avec succès.

Couverture de test:

• La couverture du test doit être atteinte à 95%.
• Le taux de réussite du scénario de test doit être de 95%. Cela peut être calculé par formule
  • (Nombre total de CT réussis / Nombre total de CT) * 100.
• Tous les cas de test critiques sont réussis.
• 5% Les cas de test peuvent échouer mais les cas de test ayant échoué sont de faible priorité.
• Une couverture fonctionnelle complète est atteinte.
• Tous les principaux flux fonctionnels / commerciaux sont exécutés avec succès avec diverses entrées et fonctionnent correctement.

Délais:

• La date limite du projet ou la date limite de fin du test est atteinte.

Documents de test:

• Tous les documents de test / livrables (exemple - Rapport de synthèse des tests ) sont préparés, examinés et publiés dans l'ensemble.

Budget:

• Le budget de test complet est épuisé.

Réunions «Go / No Go»:

• ' Va ne va pas ' Rencontre a été menée avec les parties prenantes et une décision est prise si le projet doit être mis en production ou non.

Conclusion:

Rendons les choses très simples à la fin.

Veuillez répondre aux questions par un simple oui ou non.

Si vous obtenez la plupart des réponses par Oui, cela signifie que vous pouvez arrêter le test à ce stade. Si la plupart des réponses sont non, cela signifie que vous devez vérifier ce qui manque au test et cela peut vous aider à trouver un défaut de production qui s'échappe :)

• Tous les cas de test sont-ils exécutés au moins une fois?
• Le taux de réussite du scénario de test est-il tel que défini?
• La couverture complète des tests est-elle atteinte?
• Tous les flux fonctionnels / commerciaux sont-ils exécutés au moins une fois?
• Le nombre de défauts décidé est-il atteint?
• Tous les défauts majeurs de priorité élevée sont-ils résolus et fermés?
• Tous les défauts ont-ils été retestés et fermés?
• Une régression a-t-elle été effectuée pour tous les défauts ouverts?
• Avez-vous épuisé le budget de test?
• L'heure de fin du test est-elle atteinte?
• Tous les livrables de test sont-ils examinés et publiés?

A propos de l'auteur: Il s'agit d'un article invité de Renuka K. Elle a plus de 11 ans d'expérience dans les tests de logiciels.

J'espère que cet article vous a été utile. J'aimerais également connaître vos réflexions / commentaires sur le sujet.

Bon test!

lecture recommandée

• Meilleurs outils de test de logiciels 2021 (Outils d'automatisation des tests QA)
• Emploi d'assistant QA en test logiciel
• Programme de cours de test de logiciels - Plan de formation détaillé du cours en ligne
• Cours de test logiciel: à quel institut de test logiciel dois-je adhérer?
• Choisir les tests de logiciels comme carrière
• Travail d'indépendant de rédacteur de contenu technique de test de logiciels
• Quelques questions d'entretien intéressantes sur les tests de logiciels
• Commentaires et évaluations du cours de test de logiciels