STLC - Exécution des tests

L'exécution de test est le processus d'exécution du code et de comparaison des résultats attendus et réels. Les facteurs suivants doivent être pris en compte pour un processus d'exécution de test -

  • En fonction d'un risque, sélectionnez un sous-ensemble de la suite de tests à exécuter pour ce cycle.
  • Attribuez les cas de test de chaque suite de tests aux testeurs pour exécution.
  • Exécutez des tests, signalez les bogues et capturez l'état des tests en continu.
  • Résolvez les problèmes de blocage au fur et à mesure qu'ils surviennent.
  • Signaler l'état, ajuster les affectations et reconsidérer les plans et les priorités quotidiennement.
  • Signaler les résultats et l'état du cycle de test.

Les points suivants doivent être pris en compte pour l'exécution des tests.

  • Dans cette phase, l'équipe d'assurance qualité effectue la validation réelle de l'AUT sur la base de cas de test préparés et compare le résultat par étapes avec le résultat attendu.

  • Les critères d'entrée de cette phase sont l'achèvement du plan de test et la phase de développement des cas de test, les données de test doivent également être prêtes.

  • La validation de la configuration de l'environnement de test est toujours recommandée par des tests de fumée avant d'entrer officiellement dans l'exécution du test.

  • Les critères de sortie nécessitent la validation réussie de tous les cas de test; Les défauts doivent être fermés ou différés; l'exécution du scénario de test et le rapport récapitulatif des défauts doivent être prêts.

Activités pour l'exécution des tests

L'objectif de cette phase est la validation en temps réel de l'AUT avant de passer à la production / sortie. Pour se déconnecter de cette phase, l'équipe QA effectue différents types de tests pour garantir la qualité du produit. Parallèlement à ces défauts, le signalement et le nouveau test sont également des activités cruciales dans cette phase. Voici les activités importantes de cette phase -

Test d'intégration de système

La vraie validation produit / AUT commence ici. Le test d'intégration de système (SIT) est une technique de test boîte noire qui évalue la conformité du système par rapport aux exigences spécifiées / cas de test préparés.

Les tests d'intégration de système sont généralement effectués sur un sous-ensemble de système. Le SIT peut être effectué avec une utilisation minimale des outils de test, vérifié pour les interactions échangées et le comportement de chaque champ de données au sein de la couche individuelle est également étudié. Après l'intégration, il y a trois états principaux du flux de données -

  • État des données dans la couche d'intégration
  • État des données dans la couche de base de données
  • État des données dans la couche Application

Note- Dans les tests SIT, l'équipe QA essaie de trouver autant de défauts que possible pour garantir la qualité. L'objectif principal ici est de trouver le plus de bogues possible.

Rapport de défauts

Un bug logiciel survient lorsque le résultat attendu ne correspond pas au résultat réel. Il peut s'agir d'une erreur, d'un défaut, d'un échec ou d'un défaut dans un programme informatique. La plupart des bogues proviennent d'erreurs et d'erreurs commises par des développeurs ou des architectes.

Lors de l'exécution des tests SIT, l'équipe d'assurance qualité trouve ces types de défauts et ceux-ci doivent être signalés aux membres de l'équipe concernés. Les membres prennent d'autres mesures et corrigent les défauts. Un autre avantage du reporting est qu'il facilite le suivi de l'état des défauts. Il existe de nombreux outils populaires tels que ALM, QC, JIRA, Version One, Bugzilla qui prennent en charge le signalement et le suivi des défauts.

Le rapport de défauts est un processus de recherche de défauts dans l'application testée ou dans le produit en testant ou en enregistrant les commentaires des clients et en créant de nouvelles versions du produit qui corrigent les défauts en fonction des commentaires du client.

Le suivi des défauts est également un processus important en génie logiciel, car les systèmes complexes et critiques pour l'entreprise comportent des centaines de défauts. L'un des facteurs les plus difficiles est la gestion, l'évaluation et la hiérarchisation de ces défauts. Le nombre de défauts se multiplie sur une période de temps et pour les gérer efficacement, un système de suivi des défauts est utilisé pour faciliter le travail.

Cartographie des défauts

Une fois le défaut signalé et consigné, il doit être mappé avec les cas de test échoués / bloqués concernés et les exigences correspondantes dans la matrice de traçabilité des exigences. Ce mappage est effectué par le Defect Reporter. Cela aide à faire un rapport de défaut approprié et à analyser le malice du produit. Une fois que les cas de test et les exigences sont mappés avec le défaut, les parties prenantes peuvent analyser et prendre une décision sur l'opportunité de corriger / différer le défaut en fonction de la priorité et de la gravité.

Re-tester

Un nouveau test exécute un test précédemment échoué par rapport à AUT pour vérifier si le problème est résolu. Une fois qu'un défaut a été corrigé, un nouveau test est effectué pour vérifier le scénario dans les mêmes conditions environnementales.

Lors des nouveaux tests, les testeurs recherchent des détails granulaires dans la zone de fonctionnalité modifiée, tandis que les tests de régression couvrent toutes les fonctions principales pour s'assurer qu'aucune fonctionnalité n'est interrompue en raison de ce changement.

Les tests de régression

Une fois que tous les défauts sont à l'état fermé, différé ou rejeté et qu'aucun des cas de test n'est en cours / échoué / aucun état d'exécution, on peut dire que les tests d'intégration du système sont entièrement basés sur les cas de test et les exigences. Cependant, une série de tests rapides est nécessaire pour s'assurer qu'aucune des fonctionnalités n'est interrompue en raison de changements de code / corrections de défauts.

Le test de régression est une technique de test boîte noire qui consiste à réexécuter les tests qui ont eu un impact en raison de modifications de code. Ces tests doivent être exécutés aussi souvent que possible tout au long du cycle de vie du développement logiciel.

Types de tests de régression

  • Final Regression Tests- Un "test de régression final" est effectué pour valider la construction qui n'a pas subi de modification depuis un certain temps. Cette version est déployée ou expédiée aux clients.

  • Regression Tests - Un test de régression normal est effectué pour vérifier si la construction n'a pas cassé d'autres parties de l'application par les récents changements de code pour la correction des défauts ou pour l'amélioration.

Diagramme de blocs d'activité

Le schéma fonctionnel suivant montre les activités importantes réalisées dans cette phase; il montre également la dépendance des phases précédentes -