Cycle de vie des défauts dans les tests de logiciels - eduCBA

• Cycle de vie des défauts

Cycle de vie des défauts - Comme vous le savez peut-être maintenant, l'exécution du test est la phase où le testeur exécuterait réellement les scripts de test. Le processus d'exécution des scripts de test varie d'une entreprise à l'autre et peut également être différent selon les projets au sein d'une même entreprise.

De nos jours, il existe des outils disponibles pour l'exécution des tests, des outils tels que - Quality Center, Microsoft Visual Studio, etc. Le processus d'exécution réel consistant à effectuer chaque étape pour comparer les résultats réels et attendus reste le même pour le testeur fonctionnel, quels que soient les outils utilisés.

• Que faire si le comportement réel n'est pas égal au comportement attendu?

Lorsqu'un testeur constate que le résultat du test réel n'est pas égal au résultat attendu, un défaut est enregistré.

• Comment enregistrer un défaut?

Il existe de nombreux outils disponibles aujourd'hui, certains des outils de journalisation des défauts sont ClearQuest d'IBM, le centre de qualité de HP, des outils open source comme le cycle de vie des défauts dans JIRA, etc.

Il existe certains des champs obligatoires qui sont communs aux différents outils de journalisation des défauts, ces champs sont -

1. Cycle de vie du défaut Description
2. Résumé du cycle de vie des défauts
3. Défaut consigné par
4. Défaut affecté à
5. Gravité du défaut
6. Priorité aux défauts
7. Instantanés supplémentaires
8. Numéro / nom de la version

Cycle de vie des défauts

Le cycle de vie des défauts commence à partir de l'enregistrement d'un nouveau défaut. Chaque fois qu'un défaut est enregistré, il passe à l'état «Nouveau».

Testeur - Nouveau défaut

Qui attribuer un nouveau défaut?

Un testeur peut attribuer un défaut à un développeur ou à un responsable de développement. Cette décision d'attribution des défauts varie d'un projet à l'autre. Dans certains lieux de travail, il existe un processus de cycle de vie des défauts pour l'attribuer directement à un développeur respectif et à certains endroits, le défaut est d'abord attribué à un responsable de développement et le responsable de développement à son tour l'affecte à un développeur.

Affectation des défauts (nouveau) - Développeur du cycle de vie des défauts

Affectation des défauts (nouveau) - Développeur Dev Leadà

Analyse des défauts

Le développeur analysera le défaut pour vérifier s'il est reproductible. Ici, la contribution la plus importante du testeur est d'inclure tous les détails nécessaires dans le défaut. Résumé des défauts, description détaillée des défauts sont les champs qui aident les parties prenantes à comprendre le défaut en une seule fois. Le résumé des défauts ne doit toujours contenir que les informations de haut niveau du défaut. En même temps, il devrait avoir suffisamment d'informations pour décrire la vue d'ensemble du défaut sur une seule ligne.

La description du défaut est l'endroit où le testeur doit inclure toutes les informations nécessaires comme l'environnement, le scénario, les données de test utilisées, le résultat attendu, le résultat réel, la référence aux fichiers / données et la référence à l'instantané.

Voici un bref aperçu des divers éléments de la description détaillée du défaut -

Environnement

Environnement de test où le défaut a été trouvé. Souvent, les projets ont plusieurs environnements de test où l'équipe de test effectue des tests. Par exemple - AT (environnement de test d'assemblage), PT (environnement de test de produit), UAT (environnement de test d'acceptation par l'utilisateur), etc. Le but d'avoir différents environnements est qu'il offre une flexibilité au sein de l'équipe de développement et de test pour que le code soit déployé sur l'un des environnements disponibles pour démarrer les tests à temps.

Il y a des moments où le test de produit (également appelé test de système) et le test UAT se chevauchent, donc avoir plusieurs environnements est un must pour continuer les tests en parallèle.

Dans certains cas, l'équipe de développement a besoin d'un environnement supplémentaire pour déboguer les problèmes signalés par l'équipe de test. L'équipe de développement dispose également d'un environnement dédié pour la tâche de test unitaire.

Par conséquent, avec plusieurs environnements, il faut mentionner dans le défaut un environnement particulier où le problème a été trouvé.

Scénario

Le scénario est l'ensemble des étapes effectuées par le testeur qui ont conduit à un défaut. Ici, un testeur est censé mentionner toutes les étapes que le développeur peut effectuer pour reproduire le défaut. Souvent, il y a des moments où le défaut est signalé par le testeur, mais le développeur n'est pas en mesure de le reproduire et, par conséquent, le défaut est rejeté. Cela peut se produire en raison d'étapes incorrectes / d'étapes manquantes mentionnées dans la description. Des étapes claires aident tout le monde à comprendre le défaut et à le reproduire sans avoir la dépendance de contacter un testeur pour obtenir des entrées. Un scénario bien documenté comporte des étapes faciles à lire, faciles à comprendre et précises à suivre pour reproduire le défaut.

Données de test

Un testeur est censé mentionner les données utilisées lors du déroulement des tests qui ont conduit à un problème. Ces informations permettent au développeur d'utiliser les données similaires pour reproduire le défaut et trouver la cause première du même.

Il existe certains scénarios dans lesquels un testeur trouve un défaut en utilisant des données spécifiques, mais le même problème n'est pas reproductible avec des types de données similaires. Cela peut se produire en raison d'une corruption des données, donc la saisie de données donne une chance de découvrir la cause première du défaut. Un développeur peut ne pas creuser au niveau du code si la corruption des données est le cas. Ce type de défaut peut être converti en défaut de données.

Résultat attendu et réel

C'est le point culminant du champ de description détaillée où un testeur prouve que l'erreur rencontrée est bien un défaut. La mention claire du résultat escompté permet à chaque partie prenante de considérer l'erreur comme un défaut. Imaginez qu'un défaut est enregistré avec tous les détails mais il ne spécifie pas le résultat attendu du scénario!

Habituellement, un testeur entre uniquement le résultat attendu peut être sur une ligne ou deux, mais il est très important de mentionner la source du résultat attendu. Source ici référence au document où le résultat escompté est mentionné. Cela pourrait être un document d'exigence ou une référence de storyboard.

Référence aux fichiers / données

Parfois, le défaut implique la génération d'un fichier ou l'entrée en tant que fichier. Dans ce type de scénarios, le testeur est censé fournir des informations sur le fichier qui a été utilisé et qui a provoqué le problème dans l'application. Ces fichiers peuvent être joints à l'aide de l'outil de gestion des défauts ou leur référence peut être fournie. Ces sites de référence devraient être accessibles à toutes les parties prenantes.

Référence à l'instantané

Les instantanés jouent un rôle très important lorsque vous souhaitez leur montrer le message d'erreur de saut de page exact tel qu'il s'affiche à l'écran ou lorsque vous souhaitez afficher les détails de navigation à l'écran. L'instantané donne une idée rapide du défaut rencontré, de l'écran sur lequel le défaut a été trouvé, des données utilisées sur l'écran, etc. Chaque outil de gestion des défauts a la possibilité de joindre les instantanés. Parfois, le testeur peut également joindre les feuilles de calcul Excel ou les documents Word.

Il s'agissait des divers éléments de la journalisation des défauts et des meilleures pratiques pour chacun d'eux. Revenant au cycle de vie du défaut, une fois le défaut attribué à un développeur, il / elle l'analysera en utilisant les données fournies dans l'élément de défaut. Si selon l'analyse, le problème enregistré est en effet un défaut, le développeur «ouvrira» le défaut pour travailler sur sa correction.

Cours recommandés

• Offre de formation sur les services Web dans Java
• Formation sur le développement de jeux en C ++
• Formation complète au piratage éthique
• Cours de formation Vegas Pro 13

Nouveau - Ouvert

Un défaut dans l'état ouvert montre qu'il est dans la plaque de développement et que les développeurs travaillent sur sa correction. Dans le cas où l'analyse découvre que le problème enregistré n'est pas un défaut, cela peut se produire lorsqu'il existe un écart de compréhension dans le comportement attendu du système. Si l'analyse indique que le défaut n'est pas valide, le développeur rejettera le défaut. La terminologie est «rejetée» ou «retour aux tests».

Nouveau - Retour aux tests.

Comment le testeur devrait-il valider si le défaut était effectivement un défaut invalide?

Il s'agit du scénario dans lequel un document d'exigence précis aide tous les membres de l'équipe à conclure si le défaut consigné était invalide ou valide. Se référer aux documents d'exigence aide le testeur ainsi que le développeur à arriver à la même conclusion et cela facilite vraiment le processus de discussion.

Il existe des scénarios où l'exactitude des documents de conception et d'exigence est remise en question lors du renvoi de ces documents en cas de discussions sur les défauts, dans ces cas, le retour à Business Analyst est considéré comme la meilleure option pour clarifier les requêtes.

En tant que meilleure pratique, les documents d'exigence et de conception doivent toujours être à jour afin de pouvoir les renvoyer sans ambiguïtés.

Dans le statut «Ouvert», l'équipe de développement travaille sur la correction du défaut, une fois le défaut corrigé, le statut passe à «Prêt pour le déploiement».

Ouvert - Prêt pour le déploiement

Le déploiement est le processus où les modifications sont téléchargées sur le serveur afin que l'équipe de test puisse travailler sur la version fixe du code. Habituellement, chaque projet a une équipe de déploiement distincte pour cette tâche.

Donc, à haut niveau, une équipe logicielle se compose principalement de ces 3 groupes -

1. Développement
2. Cycle de vie des défauts dans les tests
3. Déploiement (ou parfois appelé équipe de build)

Une fois que la version est déployée et que le défaut est à nouveau disponible pour un nouveau test, il est attribué à un testeur approprié pour la tâche de nouveau test.

Défaut attribué à - Cordon de test.

Cordon de test - Testeur individuel.

Défaut attribué - testeur individuel.

Sur certains lieux de travail, le défaut est d'abord attribué au cordon de test et il / elle l'affecte à son tour au testeur individuel.Cependant, à certains endroits, le défaut est directement attribué au testeur qui le testerait ou à celui qui avait soulevé le défaut.

Le statut ici passe de Ready for Deployment - Ready SIT Testing.

Maintenant, le défaut est dans la plaque du testeur. L'équipe de test validera le défaut et il y a 2 possibilités, soit le correctif fonctionnera correctement, soit le même problème se reproduira. Selon le résultat, le défaut peut passer aux états suivants -

Test SIT prêt - Fermé

Test Ready SIT - Rouvrir

Dans les deux cas, le testeur doit ajouter les commentaires des tests effectués. Cela comprend la mention des scénarios testés et des données utilisées. Si le défaut est rouvert, le testeur doit fournir les étapes exactes qui ont à nouveau conduit à l'erreur.

Le statut de réouverture est identique au statut de défaut «Nouveau».

Une fois le défaut rouvert, il recommencera le même cycle.

Défis du cycle de vie des défauts

1. Décider de la gravité des défauts - c'est l'un des sujets de discussion communs (souvent des combats) parmi les développeurs de testeurs v / s.
2. Le défaut n'est pas reproductible sur le système du développeur.
3. Défaut soulevé sur le scénario qui n'est pas mentionné dans les exigences et les documents de conception.
4. Un défaut est constaté mais ne peut pas être soulevé car l'occurrence du scénario sur l'environnement de production n'est pas réalisable.

Comment un testeur devrait surmonter les défis ci-dessus?

1. La gravité est directement proportionnelle à l'impact du défaut sur l'application, si le testeur ne peut pas continuer en raison du défaut, il est sûrement marqué avec la gravité la plus élevée.
2. S'il existe une solution de contournement pour continuer les tests, elle doit être marquée comme étant de gravité moyenne. Outre la prise en compte de l'impact d'autres tests de cycle de vie des défauts, la gravité peut également être décidée en tenant compte de la situation dans laquelle un module entier échoue, dans ce cas, même si le test d'un autre module peut être effectué mais que la gravité du module actuel est élevée. le défaut doit donc être marqué avec la gravité la plus élevée.
3. Si un défaut n'est pas reproductible sur le système du développeur, il y a des chances que l'environnement de développement et de test ne soit pas synchronisé. Un défaut reproductible sur le système de test est toujours considéré comme un défaut valide.
4. Il existe des situations où un défaut est consigné compte tenu du scénario commercial global, mais le scénario direct n'est pas mentionné dans les exigences ou le document de conception. Il est toujours considéré comme une meilleure pratique de considérer les scénarios commerciaux réels au lieu de simplement suivre les étapes du test. La communication avec les analystes commerciaux et les autres parties prenantes du produit joue un rôle important pour consigner ces défauts.
5. Il existe des scénarios où un testeur découvre une lacune dans la logique métier pendant la phase de test. Trouver de tels écarts est à nouveau considéré comme un gros plus pour un testeur. Les lacunes de conception sont généralement traitées via des améliorations.
6. Amélioration - Si un comportement doit être modifié pendant la phase de test du cycle de vie du logiciel, une amélioration est créée qui peut être prise dans la version actuelle ou suivante en tenant compte des délais et de la bande passante des équipes de développement et de test.
7. Il existe certains scénarios qu'un testeur pourrait tester lors de tests ad hoc qui pourraient en fait être des scénarios invalides, compte tenu de la possibilité de leur apparition dans la production.

Qui est le meilleur ami du testeur?

Où doit aller un testeur en cas d'ambiguïté? La réponse dépend du type de requête, si une requête concerne les exigences, il est conseillé de discuter d'abord au sein de l'équipe pour corriger la compréhension du système peut être en consultant les membres seniors. Le prochain point de contact devrait être les analystes commerciaux.

Si la requête concerne le processus de test, il est conseillé de contacter le responsable du test ou le responsable du test.

Si la requête concerne la compréhension des détails techniques de l'application, le membre de l'équipe de développement pourrait être la bonne personne à contacter.

Étant donné que le test est un processus qui nécessite une compréhension globale du système, la communication aide un testeur à obtenir une réponse rapide aux questions, cela dépend simplement de poser les bonnes questions aux bonnes personnes. Éviter de poser des questions au bon moment peut entraîner un défaut de fuite dans l'environnement de production.

Quelle est l'importance du rôle d'un testeur dans l'entreprise aujourd'hui?

Dans certains projets, l'équipe de test est tout aussi importante que l'équipe de développement et, dans certains scénarios, la dépendance à l'égard de l'équipe de test est plus importante que celle de l'équipe de développement. Le dernier scénario est rare, mais il existe sur certains lieux de travail. Cela s'est produit au fil du temps et pourrait être pour une période de temps spécifique lorsque l'équipe de développement n'a pas beaucoup d'expérience par rapport à l'équipe de test. Il y a des gens qui comprennent mieux le flux global et les fonctionnalités que la plupart des autres membres de l'équipe. Une telle personne pourrait faire partie d'une équipe de test / développement. C'est l'un des facteurs qui décide de la dépendance d'une équipe / personne pour le projet spécifique.

Quel est le cheminement de carrière d'un testeur?

Un individu peut prendre un certain temps pour comprendre le processus de test global, le domaine et d'autres tâches sur lesquelles il / elle est censé travailler dans la vie quotidienne. Sur la base de cette compréhension, il est conseillé de prendre la décision d'explorer d'autres domaines qu'un testeur pourrait aborder. Il y a toujours des opportunités dans le processus pour automatiser différents flux. La création de petits utilitaires peut également aider l'équipe de manière considérable. Si un testeur est bon en programmation, il est considéré comme un gros plus. Cela ouvre des opportunités pour les rôles d'automatisation. Les tests de performance sont également l'une des pistes de carrière des testeurs. L'analyste d'affaires est une autre option. Une bonne connaissance du domaine et de bonnes compétences en communication sont les compétences requises pour être analyste d'entreprise. Les tests offrent de nombreuses opportunités aux testeurs de travailler sur divers domaines, outils, processus, etc. Cela ne dépend que d'un individu pour ramasser et commencer à aller profondément dans l'une des zones centrales de test. Il existe de nombreuses certifications spécifiques à divers outils pour se spécialiser dans l'un des domaines des tests. Avoir une certification du fournisseur standard est un avantage pour stimuler la carrière, mais le certificat à lui seul ne peut pas vous aider à long terme s'il n'est pas combiné avec la bonne expérience de travail.

Articles recommandés

Voici quelques articles qui vous aideront à obtenir plus de détails sur les tests de logiciels, alors suivez simplement le lien.

1. 6 questions d'entrevue de test de logiciel les plus étonnantes
2. Carrières dans les tests de logiciels
3. Comment obtenir une meilleure croissance de carrière dans le travail de testeur de logiciels