STLC - Guide rapide
STLC signifie Software Testing Life Cycle. STLC est une séquence d'activités différentes effectuées par l'équipe de test pour garantir la qualité du logiciel ou du produit.
STLC fait partie intégrante du cycle de vie du développement logiciel (SDLC). Mais, STLC ne s'occupe que des phases de test.
STLC démarre dès que les exigences sont définies ou que SRD (Software Requirement Document) est partagé par les parties prenantes.
STLC fournit un processus étape par étape pour garantir la qualité des logiciels.
Au début du STLC, pendant le développement du logiciel ou du produit, le testeur peut analyser et définir la portée des tests, les critères d'entrée et de sortie ainsi que les cas de test. Cela aide à réduire la durée du cycle de test avec une meilleure qualité.
Dès que la phase de développement est terminée, les testeurs sont prêts avec les cas de test et commencent l'exécution. Cela aide à trouver les bogues dans la phase initiale.
Phases STLC
STLC comporte les différentes phases suivantes, mais il n'est pas obligatoire de suivre toutes les phases. Les phases dépendent de la nature du logiciel ou du produit, du temps et des ressources alloués aux tests et du modèle de SDLC à suivre.
Il y a 6 phases principales de STLC -
Requirement Analysis - Lorsque le SRD est prêt et partagé avec les parties prenantes, l'équipe de test lance une analyse de haut niveau concernant l'AUT (Application under Test).
Test Planning - L'équipe de test planifie la stratégie et l'approche.
Test Case Designing - Développer les cas de test en fonction de la portée et des critères.
Test Environment Setup - Lorsque l'environnement intégré est prêt à valider le produit.
Test Execution - Validation en temps réel du produit et recherche de bugs.
Test Closure - Une fois les tests terminés, la matrice, les rapports et les résultats sont documentés.
Dans ce chapitre, nous comprendrons les facteurs de comparaison entre STLC et SDLC. Considérons les points suivants et comparons ainsi STLC et SDLC.
STLC fait partie de SDLC. On peut dire que STLC est un sous-ensemble de l'ensemble SDLC.
STLC est limité à la phase de test où la qualité du logiciel ou du produit garantit. SDLC a un rôle vaste et vital dans le développement complet d'un logiciel ou d'un produit.
Cependant, STLC est une phase très importante du SDLC et le produit final ou le logiciel ne peut pas être publié sans passer par le processus STLC.
STLC fait également partie du cycle post-publication / mise à jour, la phase de maintenance du SDLC où les défauts connus sont corrigés ou une nouvelle fonctionnalité est ajoutée au logiciel.
Le tableau suivant répertorie les facteurs de comparaison entre SDLC et STLC en fonction de leurs phases -
| Phase | SDLC | STLC |
|---|---|---|
| Rassemblement des exigences |
|
|
| Conception |
|
|
| Développement |
|
|
| Configuration de l'environnement |
|
|
| Essai |
|
|
| Déploiement / Sortie de produit |
|
|
| Entretien |
|
|
L'objectif commun des tests est de trouver les bogues le plus tôt possible. Et, une fois les bogues corrigés, assurez-vous qu'il fonctionne comme prévu et qu'il ne rompt aucune autre fonctionnalité.
Pour atteindre ces objectifs, sept principes de base sont donnés pour les tests logiciels -
Que montre les tests?
Les tests peuvent montrer que des défauts sont présents mais il n'y a aucun moyen de prouver qu'il n'y a pas de défaut dans le produit. Les phases de test garantissent que l'application testée fonctionne en fonction de l'exigence donnée et contribuent à réduire la probabilité de défauts non découverts dans l'application. Mais, même si aucun défaut n'est trouvé, cela ne signifie pas qu'il est absolument correct. Nous pouvons supposer qu'AUT correspond à nos critères de sortie et maintient les exigences selon SRD.
Des tests exhaustifs sont-ils possibles?
Une couverture à 100% ou des tests de toutes les combinaisons d'entrées et de combinaisons possibles ne sont pas possibles, sauf dans des cas triviaux. Au lieu de tests exhaustifs, l'analyse des risques et les priorités sont utilisées pour définir la portée des tests. Ici, la plupart des scénarios en temps réel peuvent également envisager d'inclure le scénario négatif le plus probable. Cela nous aidera à suivre l'échec.
Test précoce
Les activités de test doivent commencer dès que possible et se concentrer sur les objectifs définis dans la stratégie de test et les résultats attendus. Le stade précoce des tests permet d'identifier les défauts d'exigence ou les écarts au niveau de la conception. Si ces types de bogues sont capturés au stade initial, cela nous permet de gagner du temps et est également rentable. La réponse à la question de savoir pourquoi les tests doivent commencer à un stade précoce est très simple: dès que le SRD est reçu, les testeurs peuvent analyser l'exigence du point de vue du test et peuvent remarquer une divergence d'exigence.
Regroupement de défauts
Sur la base d'une analyse précédente des défauts du produit, on peut dire que la plupart des défauts sont identifiés à partir d'un petit ensemble de modules qui sont essentiels pour l'application. Ces modules peuvent être identifiés en fonction de la complexité, des différentes interactions du système ou de la dépendance vis-à-vis de différents autres modules. Si les testeurs peuvent identifier ces modules cruciaux, ils peuvent se concentrer davantage sur ces modules pour identifier tous les bogues possibles. Dans une étude, on constate que 8 défauts sur 10 sont identifiés à partir de 20% de fonctionnalité de AUT.
Paradoxe des pesticides
Qu'est-ce que le paradoxe des pesticides - si les pesticides sont fréquemment utilisés sur les cultures, il arrive que les insectes développent une certaine résistance et progressivement les pesticides ainsi pulvérisés semblent inefficaces sur les insectes.
Le même concept s'applique également aux tests. Ici, les insectes sont des insectes tandis que les pesticides sont des cas de test qui sont utilisés pour fonctionner encore et encore. Si les mêmes ensembles de cas de test sont exécutés encore et encore, ces cas de test deviennent inefficaces après un certain laps de temps et les testeurs ne pourront pas identifier de nouveau défaut.
Pour surmonter ces conditions, les cas de test doivent être révisés et revus de temps en temps et des cas de test nouveaux et différents peuvent être ajoutés. Cela aidera à identifier les nouveaux défauts.
Le test dépend du contexte
Ce principe stipule que deux types d'application différents ne peuvent pas être testés en utilisant la même approche tant que les deux applications ne sont pas de même nature. Par exemple, si un testeur utilise la même approche pour une application Web et une application mobile, c'est complètement faux et il y a un risque élevé de mauvaise qualité de la publication du produit. Les testeurs doivent utiliser différentes approches, méthodologies, techniques et couvertures pour différents types et nature d'applications.
Absence d'erreur - erreur
Ce principe stipule de trouver les défauts et de les corriger jusqu'à ce que l'application ou le système soit stable, prend du temps et consomme également des ressources. Même après avoir corrigé 99% des défauts, il existe un risque élevé d'application instable. La première chose essentielle est de vérifier la stabilité de l'application et les prérequis de l'environnement. Si ces deux conditions sont remplies, alors seulement nous pouvons commencer par les tests détaillés.
L'analyse des exigences est la première phase de STLC et elle commence dès que le SRD / SRS est partagé avec l'équipe de test. Considérons les points suivants pour comprendre l'analyse des exigences dans STLC.
Le critère d'entrée de cette phase est la fourniture de SRS (Software Requirement Specification); il est également recommandé que l'architecture de l'application soit pratique.
Dans cette phase, l'équipe QA analyse à un niveau supérieur ce qu'il faut tester et comment tester.
L'équipe QA assure le suivi avec diverses parties prenantes telles que l'analyste commercial, l'architecture système, le client, le gestionnaire de test / responsable au cas où une question ou une clarification serait nécessaire pour comprendre l'exigence.
Les exigences peuvent être fonctionnelles ou non fonctionnelles comme les performances, la sécurité, la facilité d'utilisation, etc. ou à la fois fonctionnelles et non fonctionnelles.
Le critère de sortie de cette phase est de compléter le document RTM, le rapport de faisabilité de l'automatisation et une liste de questions le cas échéant pour être plus précis sur les exigences.
Activités effectuées pour l'analyse des besoins
Il y a trois activités principales qui sont exécutées par l'équipe d'AQ dans cette phase. Les activités ont été décrites ci-dessous.
Définition de la portée
L'équipe QA identifie la portée des tests à des niveaux élevés et se divise en divers modules fonctionnels. L'équipe identifie également les types de tests requis pour effectuer - tests de fumée, tests de santé mentale, tests fonctionnels, tests de régression, etc. L'équipe QA analyse les prérequis et les détails de l'environnement où les tests sont censés être effectués. L'équipe rassemble des détails sur les priorités de test et se concentre sur la séquence des modules à valider. Il identifie également les défauts d'exigence si les modules sont contredits et que la fonctionnalité n'est pas transférée avec d'autres modules.
Préparer RTM
Le traçage des exigences est un processus de documentation des liens entre les exigences et les produits de travail développés pour mettre en œuvre et vérifier ces exigences. Le RTM capture toutes les exigences lors de l'analyse des exigences ainsi que leur traçabilité dans un seul document. Tout cela est livré à la fin du cycle de vie.
La matrice est créée au tout début d'un projet car elle constitue la base de la portée du projet et des livrables qui seront produits.
La matrice est bidirectionnelle, car elle suit l'exigence en avant en examinant la sortie des livrables et en arrière en examinant l'exigence commerciale qui a été spécifiée pour une caractéristique particulière du produit.
Analyse d'automatisation
Dans la phase d'exigence, l'équipe d'assurance qualité analyse la portée de l'automatisation des tests de régression. Si l'automatisation est ajoutée dans la portée, l'équipe décide quel outil peut être utilisé, quelles fonctionnalités seront couvertes comme l'automatisation, le calendrier et l'allocation des ressources impliquées pour le développement de l'automatisation. Une fois cette analyse terminée, l'équipe d'assurance qualité fournit le rapport de faisabilité de l'automatisation aux différentes parties prenantes pour les approuver.
Dans ce chapitre, nous verrons les critères d'entrée et de sortie à différents niveaux de STLC. Les points suivants doivent être pris en compte pour comprendre les critères.
Idéalement, l'équipe d'AQ ne passe pas à la phase suivante tant que les critères de sortie de la phase actuelle ne sont pas satisfaits. Les critères d'entrée devraient inclure l'achèvement des critères de sortie de la phase précédente.
En temps réel, il n'est pas possible d'attendre la phase suivante jusqu'à ce que les critères de sortie soient remplis. Désormais, la phase suivante peut être lancée si les livrables critiques de la phase précédente ont été achevés.
Dans chaque phase du STLC, les critères d'entrée et de sortie doivent être définis.
Critère d'entrée
Les critères d'entrée pour les phases STLC peuvent être définis comme des conditions spécifiques; ou, tous les documents qui sont nécessaires pour démarrer une phase particulière de STLC devraient être présents avant d'entrer dans l'une quelconque des phases STLC.
Les critères d'entrée sont un ensemble de conditions qui permettent à une tâche de s'exécuter, ou en l'absence de l'une de ces conditions, la tâche ne peut pas être exécutée.
Lors de la définition des critères d'entrée, il est également important de définir la période pendant laquelle l'élément de critères d'entrée est disponible pour démarrer le processus.
Par exemple, pour démarrer la phase de développement des cas de test, les conditions suivantes doivent être remplies -
- Le document d'exigence doit être disponible.
- Une compréhension complète du flux d'application est requise.
- Le document du plan de test doit être prêt.
Critère de sortie
Les critères de sortie pour les phases STLC peuvent être définis comme des éléments / documents / actions / tâches qui doivent être achevés avant de conclure la phase en cours et de passer à la phase suivante.
Les critères de sortie sont un ensemble d'attentes; ceci doit être respecté avant de conclure la phase STLC.
Par exemple, pour conclure la phase de développement des cas de test, les attentes suivantes doivent être satisfaites -
- Les cas de test doivent être rédigés et révisés.
- Les données de test doivent être identifiées et prêtes.
- Le script d'automatisation de test doit être prêt, le cas échéant.
Les critères d'acceptation désignent le comportement attendu d'une fonctionnalité, d'un module et d'une application comme indiqué dans les documents d'exigence. Ce sont des étapes de vérification / points de contrôle pour déterminer si le système logiciel a satisfait ou non aux spécifications des exigences. L'objectif principal de ce test est d'évaluer la conformité du système aux exigences de l'entreprise et de vérifier s'il répond aux critères requis.
Les critères d'acceptation sont un ensemble d'énoncés qui mentionnent clairement le résultat de réussite / échec attendu. Les critères d'acceptation spécifient à la fois les exigences fonctionnelles et non fonctionnelles. Ces exigences représentent des «conditions de satisfaction ou de comportement attendu». Il n'y a pas d'acceptation partielle; soit un critère est satisfait, soit il ne l'est pas.
Ces critères définissent les limites et les paramètres d'une fonctionnalité / d'un module et déterminent si la fonctionnalité / le module est terminé et fonctionne comme prévu.
Les critères d'acceptation de haut niveau sont mentionnés au niveau du plan de test. Les critères d'acceptation sont convertis en une liste de points à vérifier ou de résultats attendus au niveau des cas de test.
Les critères d'acceptation sont définis sur la base des attributs suivants -
- Exactitude fonctionnelle et exhaustivité
- Intégrité des données
- Conversion de données
- Usability
- Performance
- Timeliness
- Confidentialité et disponibilité
- Capacité d'installation et de mise à niveau
- Scalability
- Documentation
Un plan de test décrit la stratégie qui sera utilisée pour tester une application, les ressources qui seront utilisées, l'environnement de test dans lequel les tests seront effectués, ainsi que les limites des tests et le calendrier des activités de test. En règle générale, le chef d'équipe d'assurance qualité sera responsable de la rédaction d'un plan de test.
Que comprend un plan de test?
Un plan de test comprend les éléments suivants.
- Introduction au document du plan de test.
- Hypothèses lors du test de l'application.
- Liste des cas de test inclus dans le test de l'application.
- Liste des fonctionnalités à tester.
- Le type d'approche à utiliser lors du test du logiciel.
- Liste des livrables à tester.
- Les ressources allouées pour tester l'application.
- Tous les risques encourus pendant le processus de test.
- Un calendrier des tâches et des jalons à atteindre.
Points importants pour la planification des tests
Les points suivants doivent être pris en compte pour la planification des tests dans STLC.
Idéalement, l'analyste de test (chef de file) / le gestionnaire prépare le document de stratégie de test / plan de test.
L'analyse est davantage axée sur les données / informations relatives aux applications.
C'est la première phase des tâches de test réelles.
Cette phase répond «CE QUI doit être testé» et «QUELLES RESSOURCES doivent être testées».
Les critères d'entrée de base de cette phase sont la fourniture de documents d'exigences (version mise à jour des exigences peu claires / manquantes / clarifiées) ainsi que la matrice de traçabilité des exigences.
Si l'automatisation est dans la portée, le rapport de faisabilité de l'automatisation doit être préparé avant d'entrer dans cette phase.
Les critères de sortie de cette phase sont l'achèvement du document de stratégie de test / plan de test et le document d'estimation de l'effort de test.
Aspects de la phase de planification des tests
L'objectif principal de cette phase est de préparer un document de plan de test / stratégie de test. Il comprend trois aspects principaux: la portée des livrables, l'estimation de l'effort et le plan des ressources.
Portée des livrables
Les activités suivantes doivent être effectuées pour conclure sur la portée des livrables -
- Identifier un modèle d'engagement et de prestation approprié.
- Définir les objectifs des tests, la portée des tests, les phases et activités des tests.
- Examiner les exigences commerciales et les exigences système pour identifier la faisabilité des tests.
- Définir le processus de test, le type de test et les procédures.
- Définir les procédures de gestion des défauts et de gestion des changements.
- Identifier les outils de test, les techniques et les meilleures pratiques.
- Définir l'analyse des risques.
- Définir la solution d'automatisation et identifier les candidats appropriés pour l'automatisation, le cas échéant.
Estimation de l'effort
L'estimation est le processus de recherche d'une estimation, ou approximation, qui est une valeur qui peut être utilisée à certaines fins même si les données d'entrée peuvent être incomplètes, incertaines ou instables.
L'estimation détermine combien d'argent, d'efforts, de ressources et de temps il faudra pour construire un système ou un produit spécifique. L'estimation est basée sur -
- Données passées / expérience passée
- Documents / connaissances disponibles
- Assumptions
- Risques identifiés
Les quatre étapes de base du test d'estimation sont:
- Estimation de la taille de l'AUT (Application Under Test).
- Estimation de l'effort en personnes-mois ou personnes-heures.
- Estimation du calendrier en mois calendaires.
- Estimation du coût du projet dans la devise convenue.
Plan de ressources
Les plans de ressources sont l'élément clé des phases de test. Ces plans sont inversement proportionnels au temps pris par l'équipe de test pour accomplir une tâche particulière. L'augmentation du nombre de ressources diminuera le nombre de jours d'achèvement pour une certaine limite, après quoi elle sera saturée et l'augmentation de la ressource n'aura pas beaucoup d'impact et pourrait ne pas conduire à une diminution des jours d'achèvement.
Un demandeur de ressources, généralement un chef de projet, crée des plans de ressources pour demander des ressources, suivre les efforts et les coûts. Un gestionnaire de ressources peut modifier et approuver les plans de ressources avant que les plans ne soient utilisés.
Le flux de travail normal pour un plan de ressources est -
- Planification par chef de projet
- Demande soulevée par le chef de projet
- Approuver / Modifier / Rejeter par Resource Manager
- Terminé - Clôture de la demande après validation par Resource Manager
Une fois le plan de test prêt, l'équipe QA lance le développement de cas de test. L'objectif principal de cette phase est de préparer des cas de test pour une unité individuelle. Ces cas de test fonctionnels et structurels couvrent les fonctionnalités, les points de vérification et de validation mentionnés dans le plan de test.
Les points suivants doivent être pris en compte pour le développement de cas de test dans STLC.
Dans cette phase, l'équipe QA écrit le cas de test avec une approche par étapes. Le scénario de test est ensuite approuvé par un analyste métier après avoir examiné ou retravaillé les scénarios de test au cas où des modifications seraient nécessaires.
Une fois les cas de test prêts, l'équipe QA prépare les données de test en fonction des conditions préalables.
Le critère d'entrée de cette phase est que les activités de planification des tests doivent être terminées et que le plan de test doit être prêt.
Le critère de sortie de cette phase est que les cas de test doivent être validés, les données de test doivent être prêtes et les scripts de test préparés si l'automatisation est dans la portée.
Les cas de test doivent être mappés avec la matrice de traçabilité des exigences pour assurer le suivi de la couverture des exigences si quelque chose est oublié.
Activités de la phase de développement du scénario de test
Voici les trois activités qui sont menées dans la phase de développement de cas de test -
Identification des scénarios de test
Les scénarios facilitent les tests et l'évaluation d'un système complexe. Les stratégies suivantes aident à créer de bons scénarios -
Énumérez les utilisateurs potentiels, leurs actions et leurs objectifs.
Évaluez les utilisateurs avec l'état d'esprit du pirate et répertoriez les scénarios possibles d'abus du système.
Répertoriez les événements système et comment le système gère-t-il ces demandes.
Répertoriez les avantages et créez des tâches de bout en bout pour les vérifier.
Renseignez-vous sur les systèmes similaires et leur comportement.
Etudier les plaintes concernant les produits des concurrents et leur prédécesseur.
Rédaction de cas de test
Un cas de test est un document, qui comprend des données de test, des conditions préalables, des résultats attendus et des conditions postérieures, développé pour un scénario de test particulier afin de vérifier la conformité à une exigence spécifique.
Le scénario de test sert de point de départ pour l'exécution du test. Après l'application d'un ensemble de valeurs d'entrée; l'application a un résultat définitif et quitte le système à un certain point final, également appelé condition de post-exécution.
Préparation des données de test
Les données de test sont utilisées pour exécuter les tests sur les articles de test. Les données de test doivent être précises et exhaustives pour découvrir les défauts. Pour atteindre ces trois objectifs, il est suivi d'une approche par étapes comme indiqué ci-dessous -
- Identifier les ressources ou les exigences de test
- Identifier les conditions / fonctionnalités à tester
- Définir les conditions de test prioritaires
- Sélectionnez les conditions de test
- Déterminer le résultat attendu du traitement des cas de test
- Créer des cas de test
- Documenter les conditions de test
- Effectuer un test
- Vérifier et corriger les cas de test en fonction des modifications
Diagramme de blocs d'activité
Le diagramme suivant montre les différentes activités qui font partie du développement de cas de test.
L'environnement de test se compose d'éléments qui prennent en charge l'exécution des tests avec une configuration logicielle, matérielle et réseau. La configuration de l'environnement de test doit imiter l'environnement de production afin de détecter tout problème lié à l'environnement / à la configuration.
Les points suivants doivent être pris en compte dans une configuration d'environnement de test.
C'est une combinaison d'environnement matériel et logiciel sur lequel les tests seront exécutés.
Il comprend la configuration matérielle, les paramètres du système d'exploitation, la configuration logicielle, les terminaux de test et d'autres supports pour effectuer le test.
C'est l'aspect le plus crucial du processus de test. L'indisponibilité ou la configuration de l'environnement défectueuse peuvent ruiner tous les efforts de test.
En pratique, l'équipe d'assurance qualité ne peut pas commencer le travail réel sans disposer du bon environnement à tester.
Il s'agit d'une activité indépendante et peut être démarrée avec le développement de cas de test.
De manière plus générique, cette activité est effectuée par les développeurs dans les aspects techniques tandis que les conditions d'exigence peuvent être effectuées par les clients / analystes commerciaux.
La préparation de l'environnement de test peut être validée par des tests de fumée et effectuée par l'équipe d'assurance qualité.
Idéalement, nous pouvons dire que les critères d'entrée de cette phase sont la fourniture d'un plan de test, la préparation des cas de test de fumée et la préparation des données de test.
Le critère de sortie de cette phase est que l'environnement de test doit être prêt et que les tests de fumée doivent être effectués avec succès avec les résultats attendus.
Activités effectuées pour la configuration de l'environnement de test
Les activités suivantes sont effectuées dans cette phase.
Environnement de test de conception
Les facteurs suivants jouent un rôle important dans la conception d'un environnement de test.
Déterminez si l'environnement de test doit être archivé pour pouvoir effectuer des sauvegardes.
Vérifiez la configuration du réseau.
Identifiez le système d'exploitation du serveur, les bases de données et les autres composants requis.
Identifiez le nombre de licences requises par l'équipe de test.
Mise en place de l'environnement
Analysez les exigences de configuration de l'environnement et préparez une liste des exigences logicielles et matérielles pour la configuration. Obtenez la confirmation officielle de la configuration de l'environnement de test et configurez-le pour accéder à l'environnement de test.
Test de fumée
Une fois que l'environnement est configuré et que l'équipe d'assurance qualité y a accès, une série rapide de tests de fumée doit être effectuée pour valider la stabilité de construction de l'environnement de test. Si les résultats sont comme prévu, l'équipe d'assurance qualité peut passer à la phase suivante, sinon signaler les écarts et attendre le déploiement après les correctifs.
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 -
Le cycle de vie d'un défaut, également connu sous le nom de cycle de vie d'un bug, est le parcours d'un défaut, le cycle qu'un défaut traverse au cours de sa vie. Il varie d'une organisation à l'autre et également d'un projet à l'autre, car il est régi par le processus de test logiciel et dépend également des outils utilisés.
Cycle de vie des défauts - Workflow
Le diagramme suivant montre le flux de travail d'un cycle de vie d'anomalie.
États d'un cycle de vie de défaut
Voici les différents états du cycle de vie d'un défaut.
New - Défaut potentiel soulevé mais à valider.
Assigned - Affecté à une équipe de développement à traiter.
Active- Le défaut est en cours de résolution par le développeur et une enquête est en cours. À ce stade, deux résultats sont possibles: différé ou rejeté.
Test / Fixed / Ready for Retest - Le défaut est corrigé et prêt à être testé.
Verified - Le défaut qui est retesté et le test a été vérifié par QA.
Closed - L'état final du défaut qui peut être fermé après le nouveau test QA ou peut être fermé si le défaut est dupliqué ou considéré comme PAS un défaut.
Reopened - Lorsque le défaut n'est PAS corrigé, QA rouvre / réactive le défaut.
Deferred - Lorsqu'un défaut ne peut pas être résolu dans ce cycle particulier, il est reporté à une version ultérieure.
Rejected - Un défaut peut être rejeté pour l'une des trois raisons - défaut dupliqué, PAS un défaut, non reproductible.
Les défauts sont classés du point de vue de l'équipe d'assurance qualité comme Priority et du point de vue du développement comme Severity(complexité du code pour y remédier). Ce sont deux classifications majeures qui jouent un rôle important dans le calendrier et la quantité de travail nécessaire pour corriger les défauts.
Qu'est-ce que la priorité?
La priorité est définie comme l'ordre dans lequel les défauts doivent être résolus. Le statut de priorité est généralement défini par l'équipe QA tout en signalant le défaut à l'équipe de développement en mentionnant le délai pour corriger le défaut. Le statut de priorité est défini en fonction des exigences des utilisateurs finaux.
Par exemple, si le logo de l'entreprise est mal placé dans la page Web de l'entreprise, la priorité est élevée mais elle est de faible gravité.
Liste prioritaire
Une priorité peut être classée des manières suivantes -
Low - Ce défaut peut être corrigé après la correction des problèmes critiques.
Medium - Le défaut doit être résolu dans les versions suivantes.
High - Le défaut doit être résolu immédiatement car le défaut affecte l'application dans une large mesure et les modules concernés ne peuvent pas être utilisés tant qu'il n'est pas corrigé.
Urgent - Le défaut doit être résolu immédiatement car le défaut affecte gravement l'application ou le produit et le produit ne peut pas être utilisé tant qu'il n'a pas été corrigé.
Qu'est-ce que la gravité?
La gravité est définie comme l'espièglerie d'un défaut sur l'application et la complexité du code pour y remédier du point de vue du développement. Itest lié à l'aspect développement du produit. La gravité peut être décidée en fonction de la gravité / importance du défaut du système. L'état de gravité peut donner une idée de l'écart de fonctionnalité dû au défaut.
Example - Pour le site Web d'exploitation de vols, le défaut de génération du numéro de billet contre réservation est de haute gravité et également de haute priorité.
Liste de gravité
La gravité peut être classée des manières suivantes -
Critical /Severity 1- Un défaut affecte les fonctionnalités les plus cruciales de l'application et l'équipe d'assurance qualité ne peut pas continuer avec la validation de l'application testée sans la corriger. Par exemple, l'application / produit plante fréquemment.
Major / Severity 2- Un défaut impacte un module fonctionnel; l'équipe d'assurance qualité ne peut pas tester ce module particulier mais continue la validation des autres modules. Par exemple, la réservation de vol ne fonctionne pas.
Medium / Severity 3- Le défaut a un problème avec un seul écran ou lié à une seule fonction, mais le système fonctionne toujours. Le défaut ici ne bloque aucune fonctionnalité. Par exemple, Ticket # est une représentation qui ne suit pas les caractères alphanumériques appropriés comme les cinq premiers caractères et les cinq derniers comme numériques.
Low / Severity 4- Cela n'a aucun impact sur la fonctionnalité. Il peut s'agir d'un défaut esthétique, d'une incohérence de l'interface utilisateur pour un champ ou d'une suggestion pour améliorer l'expérience de l'utilisateur final du côté de l'interface utilisateur. Par exemple, la couleur d'arrière-plan du bouton Soumettre ne correspond pas à celle du bouton Enregistrer.
Une vérification par rapport aux critères de sortie du test est très essentielle pour affirmer que le test est maintenant terminé. Avant de mettre fin au processus de test, la qualité du produit est mesurée par rapport aux critères de réalisation du test.
Le critère d'entrée de cette phase est que l'exécution du cas de test est terminée, les résultats des tests sont disponibles et le rapport de défauts est prêt.
Les critères de réussite du test comprennent les éléments suivants:
- La couverture spécifiée a été atteinte.
- Non showstoppers ou défauts critiques
- Il existe très peu de défauts connus de priorité moyenne ou faible. Celles-ci n'affectent pas l'utilisation du produit.
Le critère de sortie de cette phase est la fourniture de rapports de clôture de test et la préparation de matrices qui sont ensuite validées par le client.
Parlons maintenant de la activities involved in the closure of Test Cycle.
Rapport de fin de test
Le rapport d'achèvement de test est un processus par lequel les mesures de test sont rapportées sous forme de résumé pour mettre à jour les parties prenantes. Cela leur permet de prendre une décision éclairée.
Le rapport de fin de test contient les informations suivantes.
- Identifiant du rapport de résumé de test
- Summary
- Variances
- Résumé des résultats
- Evaluation
- Efforts prévus et efforts réels
- Approuver
Un bon rapport d'achèvement de test indique la qualité, mesure les risques exceptionnels et identifie le niveau d'un logiciel testé.
Matrice d'achèvement des tests
Une fois les tests terminés, diverses matrices sont collectées pour préparer les rapports de test. Les critères de préparation des rapports sont les suivants:
- Nombre de tests exécutés
- Nombre de tests réussis
- Nombre de tests échoués
- Nombre d'échecs de test en fonction de chaque module
- Nombre de défauts de test soulevés pendant le cycle d'exécution
- Nombre de défauts de test acceptés
- Nombre de défauts de test rejetés
- Nombre de défauts de test différés
- Statut des défauts actifs
- Calcul de l'indice de qualité de la construction
Résultats de test
Lors de l'exécution d'un scénario de test, d'un nouveau test des défauts et de l'exécution d'un scénario de test de régression, Test results articulate doivent être sauvegardés et peuvent être produits avec les documents de clôture du cycle de test pour soutenir l'achèvement de l'exécution du test.
Les articulations peuvent être des captures d'écran, des résultats de requêtes de base de données, des enregistrements, des fichiers journaux, etc.