Introduction au travail du testeur de logiciels
Quelle est la première chose qui vous vient à l'esprit lorsque vous pensez à un test de logiciel? Un travail non codant? Ou un métier qui est très facile car il vous donne la possibilité de trouver des erreurs dans le travail des autres (trouver des erreurs quand dans les autres est la tâche la plus facile pour nous tous)? Ou pensez-vous que c'est la profession qui s'occupe de vérifier l'exactitude du produit? Toutes ces pensées sont correctes et constituent les activités quotidiennes d'un travail de testeur de logiciels. Cependant, les tests de logiciels ne se limitent pas à ces activités.
Comprendre l'application
L'application peut provenir de n'importe quel domaine - Santé, Assurance, Finance, etc. L'apprentissage du domaine d'application est très important pour tout travail logiciel pour ouvrir les portes à la réflexion sous différents angles et différentes perspectives d'utilisateurs lors du test de l'application. Découvrir et valider les voies d'application évidentes et moins évidentes en est toujours la principale attente. Une connaissance approfondie de l'application permet de valider efficacement le produit en même temps que le testeur peut devenir un atout pour un projet où il est considéré comme l'une des principales sources de connaissances en matière de comportement du produit.
Bien que l'apprentissage du domaine et des fonctionnalités soit un processus continu, tout autre facteur important est la connaissance du processus de test.
Processus de test
Le processus de test peut varier d'une entreprise à l'autre ou même d'un projet à l'autre. Aujourd'hui, nous avons différents modèles de développement logiciel comme le modèle V, le modèle de prototypage ou une méthodologie totalement différente comme l'approche Agile du développement logiciel. Avec le changement de modèle de développement, l'approche de test à suivre varie également. Travailler dans un modèle V aura des processus bien définis tandis que ce travail dans une méthodologie agile devrait être testé dans des conditions en constante évolution.
Le travail n'est pas encore facile avec une connaissance du domaine acceptable et une compréhension du processus de test, le prochain défi qui vient avec la vie de l'apprentissage de divers outils.
Outils
Les outils impliquent des outils de gestion de test, des outils de journalisation des défauts, des outils de gestion de base de données, etc.
Avec divers logiciels de journalisation des défauts, qualités et outils, certains open source et certains sous licence, il est toujours avantageux d'avoir la connaissance de plusieurs outils. Il l'aide à faire facilement la transition des projets ou des équipes en suivant différents outils. Avec une connaissance adéquate du domaine, des processus et des outils, la vie du travail du testeur de logiciels est plus importante, ce qui rend ses journées de travail difficiles et passionnantes. La collaboration au sein des équipes est l'un des facteurs importants de la réussite de tout projet et pour une collaboration efficace, la communication joue un rôle très important.
Cours recommandés
- Cours complet J2EE
- Formation à la programmation R en ligne
- Cours de programmation Go
- Formation de certification en ligne dans le programme Haskell
la communication
La communication joue un rôle très important pour les qualités des logiciels dès les phases initiales de développement logiciel, les membres de l'équipe de test sont impliqués (en tant que meilleure pratique) dans la discussion des exigences, interrogeant les analystes commerciaux en cas de questions ou de lacunes dans les exigences. Un tster avec des compétences de communication efficaces peut communiquer efficacement les risques, peut communiquer efficacement avec l'équipe de développement et peut communiquer efficacement les résultats et les rapports de test.
Planification des travaux du testeur de logiciels
Comme son nom l'indique, la planification des tests est la phase où la préparation des tests est effectuée. La préparation d'un tster impliquera différents types d'activités qu'un tster fait pour une application efficace. Cela vous aidera à valider l'application et à découvrir efficacement les défauts de l'application. Afin de commencer la planification, un teste passe par les exigences pour comprendre les attentes.
1. Exigences
Les exigences pourraient être données à l'équipe de test sous forme de wireframes, de storyboards, de feuilles Excel. Le but de tous ces documents est de présenter les exigences du client de manière efficace et facile à comprendre. Le document filaire n'est rien d'autre qu'un document qui peut prendre la forme d'une présentation PowerPoint qui décrit les exigences du client. Dans le même ordre d'idées, les story-boards décrivent généralement l'aspect / la conception requise des écrans. De nos jours, divers outils sont disponibles sur le marché qui peuvent être utilisés pour préparer les documents requis. La création des documents requis est la responsabilité principale d'un analyste d'affaires. Un goût devrait comprendre les exigences à fond. Afin que le testeur ainsi que les développeurs comprennent correctement les exigences, les analystes commerciaux gardent le forum ouvert pour que tout le monde puisse soulever et obtenir des réponses aux questions sur l'une des exigences. La plateforme pour discuter et communiquer les questions et requêtes ouvertes varie d'un projet à l'autre. Il peut s'agir de la chaîne d'e-mails ou d'une conférence téléphonique ou même d'un référentiel de lecteur partagé maintenu pour garder une trace de toutes les questions ouvertes et de leurs réponses fournies par l'analyste métier.
Une communication claire et un dossier de communication jouent un rôle très important pour une preuve. Une petite supposition dans l'exigence peut parfois conduire à un défaut majeur du produit. A chaque étape, il est recommandé à un testeur logiciel de qualités de maintenir la communication propre. La communication de travail de testeur de logiciel pourrait être avec des analystes d'affaires ou même au sein d'une équipe. Une communication claire permet d'éloigner les hypothèses lors de la planification et de l'exécution. Dans le même temps, il est recommandé d'avoir un dossier de communication (de préférence une communication par e-mail). Le fait d'avoir une communication écrite sur les requêtes dans les exigences aide aux étapes ultérieures de l'exécution du test où la fonctionnalité peut ne pas avoir été développée comme confirmé dans la communication enregistrée.
2. Scénario
Une fois les exigences comprises, le testeur commence à documenter les scénarios dans le document Scénario de test. Un scénario comme son nom l'indique est un flux de fonctionnalités que l'utilisateur suit pour accomplir une tâche.
Exemples de scénarios -
- L'utilisateur doit pouvoir se connecter avec succès.
- L'utilisateur doit pouvoir réserver des billets dans le système.
- L'utilisateur doit pouvoir annuler les tickets dans le système.
- L'utilisateur doit pouvoir visualiser / mettre à jour les détails du profil.
Ce sont les tâches logiques qu'un utilisateur effectue dans le système. Ces tâches logiques, lorsqu'elles sont regroupées, aident le prouveur à prendre note de tous les scénarios possibles qu'un utilisateur est censé exécuter. Ces scénarios sont généralement documentés dans les feuilles Excel ou parfois à l'aide de certains outils. Un prouveur prospère pour extraire tous ces scénarios des documents d'exigence. Un document contenant de tels scénarios est appelé document de scénario de test (ou quelque part en tant que document de scénario de haut niveau). Ce document sert de document d'entrée pour la rédaction des cas de test.
3. Cas
Ce cas est la version la plus détaillée du scénario de travail de Software Tester où le scénario est décomposé en étapes plus détaillées que l'utilisateur effectuera réellement lors de l'utilisation de l'application. Un exemple simple basé sur les scénarios mentionnés ci-dessus est:
Scénario - L'utilisateur doit pouvoir se connecter avec succès.
Cas de test:
- Vérifiez que l'utilisateur est en mesure d'entrer le nom d'utilisateur correct.
- Vérifiez que l'utilisateur est en mesure d'entrer le mot de passe.
- Vérifiez qu'en cliquant sur le bouton Connexion après avoir entré le nom d'utilisateur et le mot de passe corrects, l'utilisateur peut se connecter avec succès.
Une telle liste de ces cas peut continuer pour inclure une vérification de validation sur chaque champ, la vérification des scénarios négatifs et ainsi de suite.
Voici quelques exemples supplémentaires de ces cas -
- Vérifiez que le nom d'utilisateur n'est pas entré, le système génère une erreur appropriée.
- Vérifiez que le mot de passe lorsqu'il n'est pas entré, le système génère une erreur appropriée.
- Vérifiez que le nom d'utilisateur et le mot de passe lorsqu'ils ne sont pas entrés, le système génère une erreur appropriée.
- Vérifiez qu'en entrant un mot de passe incorrect, le système envoie un message d'erreur approprié.
- Vérifiez qu'en entrant un nom d'utilisateur incorrect, le système envoie un message d'erreur approprié.
4. Matrice de traçabilité des exigences (RTM)
La matrice de traçabilité des exigences, comme son nom l'indique, permet de vérifier et d'intégrer la couverture des exigences fournie par Business dans les documents de test, comme les scénarios et les cas de test.
À titre de meilleure pratique, il s'agit d'un document distinct montrant la correspondance du numéro d'exigence avec celui des scénarios / cas incorporant cette exigence.
Ce document peut ne pas être utilisé par toutes sortes de projets, mais lorsqu'il est utilisé, il aide de manière efficace à tracer la correspondance des scénarios de haut niveau avec les exigences. Il indique la couverture et peut être utilisé pour vérifier la présence d'au moins un de ces cas par rapport à chaque exigence. La création et la maintenance du document RTM est considérée comme la meilleure pratique, mais tous les types de projets (comme Agile) n'utilisent pas de document de travail logiciel. Lorsque les exigences changent très fréquemment, la maintenance de ce document peut être entendue. Afin d'éviter ce surcoût et d'avoir en même temps un moyen de suivre les exigences, certains projets intègrent la partie traçabilité dans le cas de travail de Software Tester ou son document de scénario lui-même.
L'aspect important est d'avoir un moyen de tracer les scénarios / cas aux exigences et vice-versa. Des exigences bien documentées facilitent la tâche de Prover pour créer et gérer ces documents. Des exigences ambiguës, des exigences en constante évolution rendent la vie du prouveur plus difficile et peuvent conduire à avoir des documents livrables incohérents qui entraînent une absence de validation et donc un défaut dans le produit final.
Jusqu'ici, un testeur planifiait et préparait les tests. La préparation à la guerre faisant partie de la guerre, il en va de même ici. Plus ces documents sont concis, plus il est facile pour le prouveur de valider la fonctionnalité et de découvrir presque tous les défauts. La prochaine phase du parcours du testeur est l'exécution.
Exécution des travaux du testeur de logiciels
Il s'agit de la phase où tous les documents susmentionnés sont mis en service. Les exigences ont été utilisées pour créer un scénario, le scénario a été utilisé pour le créer des cas. ce document de cas est le document autosuffisant ici pour commencer à valider la demande. Prover commence à valider l'application en exécutant les étapes de ce document de cas. Plusieurs de ces cas peuvent être utilisés pour valider un seul scénario ou même un seul cas de test peut correspondre à un seul scénario de test. Tout dépend de la complexité des scénarios ou parfois de la norme suivie dans l'équipe de test. Par conséquent, un seul document de cas de test peut contenir de 20 à 50 cas de test ou il peut contenir de 100 à 120 cas de test. Ces chiffres sont uniquement à des fins d'explication, ils peuvent varier énormément d'un projet à l'autre. Le résultat de cette phase est des défauts de test. Le nombre de défauts valables soulevés dans cette phase donne une bonne idée de la stabilité de l'application, de la qualité des tests, de la qualité de la construction et de nombreux facteurs de ce type qui ont un impact direct sur le produit. Cette phase est la phase la plus importante car le testeur s'efforce de couvrir tous les cas de test (en validant presque tous les chemins utilisateur requis) et en même temps de soulever autant de défauts valides que possible. Toute la préparation, les compétences en communication, les requêtes demandées à l'entreprise interviennent pour agir dans cette phase de test.
Défauts du testeur de logiciels fonctionne
Lors de l'exécution de ces cas, tout comportement qui n'est pas égal au résultat attendu est signalé comme le défaut. Chaque scénario de test a une description, un résultat attendu et une colonne pour le résultat réel. Bien que ces documents de planification de travail de testeur de logiciel aient une description et les résultats attendus et une colonne vide pour les résultats réels. Lors de l'exécution des cas de test, le testeur est censé remplir la colonne de résultat réelle. Dans le même temps, si le réel n'est pas égal au résultat attendu, le défaut est enregistré. Consigner un défaut ne signifie tout simplement pas informer le développeur du problème. Il s'agit là encore d'un processus formel généralement effectué à l'aide d'un outil. Actuellement, il existe divers outils sur le marché, certains open source et certains sous licence. Tout outil de journalisation des défauts a les champs suivants -
- Nom du projet / version
- Résumé des défauts
- Description détaillée du défaut
- Gravité du défaut
- Priorité aux défauts
- Phase de détection du défaut
- Assigné à
- Pièces jointes
Comme nous pouvons le voir, le but de tous ces champs est d'avoir un processus formel détaillé sur le problème trouvé. Cela aide les développeurs à reproduire le défaut dans leur environnement et à le corriger. Ci-dessous la brève description de tous ces champs -
- Nom du projet / version - Nom de la version dans laquelle le défaut a été détecté, généralement le projet a plusieurs versions et le même projet peut avoir plusieurs sous-projets. Ce champ permet de soulever un problème pour une version spécifique.
- Récapitulatif des défauts - Une courte description à une ligne du défaut trouvé.
- Description détaillée du défaut - Il s'agit de la description détaillée du défaut, elle doit inclure des détails tels que l'environnement où le défaut a été trouvé, et les données de test utilisées, les résultats réels attendus du résultat et toute information supplémentaire qui ajoute des informations plus précieuses pour que les parties prenantes comprennent le défaut.
- Gravité du défaut - Cela signifie la gravité du défaut. Habituellement, il a des valeurs similaires aux valeurs critiques, élevées, moyennes, basses ou numériques comme 4, 3, 2, 1.
- Priorité aux défauts - Cela signifie à quel point il est urgent de réparer le défaut.
- Phase où le défaut a été trouvé - Comme il existe de nombreuses phases où un défaut peut être enregistré, phase de test unitaire, SIT (test d'intégration du système), UAT (test d'acceptation par l'utilisateur) ou même phase de production.
- Attribué à - Nom du développeur ou du responsable du développement.
- Pièces jointes - Cela a donné une option au testeur pour joindre l'instantané de l'écran où le problème a été rencontré.
L'exécution des tests et la journalisation des défauts est la phase où de nombreux défis peuvent être rencontrés par un testeur. Certains d'entre eux communiquent efficacement avec les développeurs. Pouvons-nous affirmer que l'enregistrement d'un défaut avec toutes les informations nécessaires n'est pas suffisant pour que les développeurs comprennent le défaut?
C'est le cas et dans certains cas, cela nécessite des explications / discussions supplémentaires avec les développeurs. Il existe des cas où un testeur rencontre un comportement inattendu dont il / elle peut ne pas être sûr (e) s'il s'agit d'un défaut. Ces circonstances sont généralement rencontrées par le prouveur qui est nouveau dans l'équipe, ayant une connaissance limitée du domaine ou ayant une ambiguïté sur les exigences. Eh bien, le testeur n'est pas à blâmer ici s'il y a des délais serrés et des exigences en constante évolution et dans la plupart des cas, le prouveur apprend le domaine tout en planifiant et en exécutant des cas de test. Comme nous pouvons le voir, le cheminement d'un testeur n'est pas aussi facile qu'il est perçu. Cela nécessite toujours une attitude d'apprentissage, de bonnes compétences en communication, de bonnes compétences en collaboration et un empressement à s'adapter aux conditions où il y a des changements dans les domaines, les outils et les processus utilisés. Alors que nous avons parlé du parcours des testeurs manuels, le processus global s'applique également aux testeurs Automation. L'automatisation, d'autre part, a des changements importants dans le processus car la portée des tests et de la planification, l'exécution varie considérablement.
Compte tenu du parcours du prouveur tel que discuté ci-dessus, peut-on encore dire que le travail de qualités de testeur de logiciel est plus facile que celui de développeur?
On peut dire que plus que de comparer les rôles de développeur v / s du testeur, il sera plus utile d'avoir une discussion sur la façon dont la collaboration de deux peut conduire à un succès majeur du produit dans son ensemble. On oublie parfois que le travail du testeur est de trouver des problèmes dans l'application et non de pointer les erreurs des développeurs. Lorsque nous oublions l'idée même de notre travail, cela conduit parfois à des discussions inutiles. Cependant, il a été observé qu'il existe des équipes de développement tout aussi bonnes, où tout le monde comprend que l'objectif final est de faire fonctionner l'application comme prévu. Espérons que tout le monde considère le côté positif du travail de test comme un rôle qui aide au nettoyage du produit et non comme celui qui trouve juste des erreurs!
Articles recommandés
Cela a été un guide pour découvrir et valider les chemins d'application évidents et pas si évidents est toujours la principale attente d'un travail de testeur de logiciel. Il s'agit du lien externe suivant lié au travail du testeur de logiciels.
- Cycle de vie des défauts dans les tests de logiciels
- 6 questions d'entrevue de test de logiciel les plus étonnantes
- Carrières dans les tests de logiciels