Menu

Mise en œuvre pratique en 7 étapes des tests manuels avant la mise en production

7 step practical implementation manual testing before production release

Essayez Notre Instrument Pour Éliminer Les Problèmes

Dans le post précédent de cette série sur les tests manuels, j'ai essayé de jeter autant de lumière que possible sur les bases des tests manuels.

Si vous l'avez manqué, vous pouvez le lire ici .

J'espère qu'il a réussi à vous amener au plus près des réponses que vous recherchiez.

Dans ce cas, n’aimeriez-vous pas en savoir plus sur la mise en œuvre pratique du test manuel, comment vous familiariser avec celui-ci et comment y démarrer réellement une carrière?

Cet article éclairera tous ces aspects.

Mise en œuvre de tests manuels

Commençons.

Ce que vous apprendrez:

Cycle de test manuel

Comprendre Cycle de test manuel ou le cycle de vie des tests logiciels (STLC), tout d'abord, nous devons comprendre le cycle de vie du développement logiciel (SDLC), que vous connaissez déjà, je suis sûr.

Les gens se réfèrent à eux séparément mais ne savent pas s'ils peuvent réellement coexister. Ils sont si étroitement intégrés les uns aux autres. Eh bien, même ces cycles ont tellement de versions créées et flottant dans l'espace Internet, ils varient principalement selon le modèle de développement sélectionné.

Comme la plupart des le monde devient Agile ces jours-ci, je vais simplifier mon travail autour d'Agile.

7 étapes de test manuel pratique avant la sortie de production

J'y vais.

N'oubliez pas que je parle à la fois de SDLC et de STLC.

# 1) Rassemblement des exigences

Phase de collecte des exigences

L'analyste commercial (personne / équipe responsable de la collecte des exigences) documente les exigences. Ils documentent les exigences, c’est le point culminant, vous pouvez vous concentrer uniquement sur cela. Où il est documenté importe moins.

Les gens utilisent tout ce qui leur convient pour les documenter, mais sans s'y limiter, les plates-formes traditionnelles comme MS word doc, les plates-formes modernes comme Jira / Rally et les outils new age comme Trello.

# 2) Discussion / partage des exigences

Phase de discussion des besoins

L'analyste métier est alors censé partager les exigences documentées avec l'équipe de développement, l'équipe de test et l'équipe UX (si nécessaire). Cela se produit généralement via une réunion formelle où les SPOC (point de contact unique ou une équipe entière, cela dépend) des trois fonctions répondent et comprennent l'ensemble des besoins.

Dans une culture de travail saine, les exigences sont discutées sous tous les angles et chaque membre de la réunion peut poser des questions et des doutes. Une fois que toutes les questions ont été répondues et que les modifications nécessaires ont été apportées à l'exigence, cette phase peut être considérée comme terminée. Encore une fois, ce que l'on appelle cette réunion / étape particulière et sa documentation diffèrent d'une entreprise à l'autre.

Lectures complémentaires=> Comment consulter un document SRS

Une fois que toutes les questions ont été répondues et que les modifications nécessaires ont été apportées à l'exigence, cette phase peut être considérée comme Fait .

Encore une fois, ce que l'on appelle cette réunion / étape particulière et sa documentation diffèrent d'une entreprise à l'autre.

Par exemple, la documentation est appelée ou décomposée en SRS (spécification d'exigence système), document d'exigence, épique, histoire d'utilisateur, point d'histoire (éventuellement, plus petite unité d'exigence), etc. Exigence Réunion de discussion, toilettage, réunion de perforation, etc., j'espère que vous comprenez mon point?

En appuyant sur ces terminologies pour que vous vous souveniez toujours de l'idée principale indépendamment des différents noms.

Publier cette réunion deux étapes se déclenche en même temps, sans ordre particulier, reportez-vous aux deux étapes suivantes.

# 3) Conception

L'équipe de développement commence par leur conception technique dès que les exigences sont discutées et lorsqu'il n'y a pas de points importants en attente. Ce qui est fait dans cette phase diffère encore d'une entreprise à l'autre.

Cette phase peut impliquer, mais sans s'y limiter, les tâches suivantes:

  • Décider de l'approche de développement
  • Préparation du document de conception
  • Conception des organigrammes
  • Estimer les efforts
  • Comprendre l'impact de cette nouvelle exigence sur toute fonctionnalité existante
  • Besoin de patcher les données existantes, etc.

L'équipe UX peut également s'impliquer dans cette phase lorsqu'il y a un changement d'interface utilisateur ou qu'un nouvel écran doit être développé. L'équipe UX aide l'équipe de développement et l'équipe de test avec un prototype d'interface utilisateur pour la fonctionnalité / fonctionnalité de la discussion. Cela peut être un document Photoshop, une simple image, une présentation PowerPoint ou tout autre élément qui permettra à l'équipe de développement de comprendre comment les écrans doivent être développés.

Remarque: Idéalement, ces écrans, ou au moins leurs versions préliminaires, ne sont affichés dans la session de discussion sur les exigences que pour aider l'équipe à mieux comprendre. Il est étiqueté selon l'exigence d'origine afin de pouvoir y faire référence à tout moment.

# 4) Conception de scénario de test / cas de test

Phase de conception du scénario de test

Parallèlement à la phase de conception, l'équipe de test commence par créer des scénarios de test et / ou des cas de test en fonction des exigences discutées. Le fait que les scénarios de test soient toujours écrits en premier, puis se décomposent en cas de test est quelque chose qui n'est pas constant.

À mon avis, que vous documentiez les scénarios de test ou non, ils sont toujours là avant les cas de test. Le scénario de test est votre puce que vous pouvez dire, il vous guide pour approfondir les choses. Une fois l'écriture du cas de test terminée, elle peut être partagée avec l'équipe de développement pour leur donner une idée de la portée du test et ils peuvent également s'assurer que le développement qui a eu lieu ou qui se produit satisfait les cas de test écrits.

Une fois l'écriture du cas de test terminée, elle peut être partagée avec l'équipe de développement pour leur donner une idée de la portée du test et ils peuvent également s'assurer que le développement qui a eu lieu ou qui se produit satisfait les cas de test écrits.

Les cas de test une fois écrits sont idéalement examinés par un responsable de test ou un pair sous de nombreux angles tels que:

  • Couverture des besoins
  • Grammaire orthographique
  • Normes d'écriture de cas de test (rien d'autre qu'un modèle que suit une équipe / entreprise)
  • Rétrocompatibilité
  • Compatibilité de la plateforme
  • Références des données de test
  • Types de tests ciblés, etc.

Lectures complémentaires=> Écriture de cas de test à partir d'un document SRS

Idéalement, seulement après examen et modification nécessaire, ils sont transmis à l'équipe de développement.

Quand j’ai dit «une fois l’écriture des cas de test terminée», je voulais dire une fois que «tous les cas de test sont écrits sur la base d’une connaissance complète des exigences données et des scénarios de test possibles découverts jusqu'à ce moment-là». Il est presque impossible d'avoir une couverture de cas de test à 100% du premier coup.

Il y aura des défauts que vous trouverez dans des actions aléatoires (mais intentionnelles), dans des actions purement aléatoires (test de singe) et dans certains scénarios rares. Il y a des chances que vous manquiez certains d'entre eux. Et à un moment donné, vous pourriez manquer même les plus basiques, après tout, vous êtes humain. Mais ici, au moins une bonne revue de cas de test et une méthode structurée d'écriture de cas de test peuvent vous sauver.

Le plus souvent, un testeur ou une équipe de test continue d'ajouter de plus en plus de cas de test au bloc existant à mesure qu'ils découvrent la vérité ou réfléchissent davantage aux exigences.

Eh bien, à l'heure actuelle, certains d'entre vous doivent douter de ma connaissance du test logiciel car un mot (qui est en quelque sorte devenu une norme dans le test logiciel) n'est pas encore utilisé par moi. Plan de test, non?

Laissez-moi dire quelque chose à ce sujet. Je crois fermement à la nécessité de la plupart des informations mentionnées dans le plan de test, mais les documenter toutes au même endroit et les rendre absolument obligatoires est quelque chose que je trouve discutable.

Quoi qu’il en soit, c’est un sujet distinct à discuter. Partager une information «convient à tous» à ce sujet est difficile, mais laissez-moi essayer.

Soit vous, avec votre responsable de test ou votre responsable de test, préparez le plan de test, soit vous documentez les informations requises à différents endroits.

Lectures complémentaires=> Comment rédiger un document de plan de test

Informations qui doivent être absolument figées à ce stade:

  • La portée des tests: Exigence, compatibilité descendante, plates-formes, appareils, etc.
  • Personne / équipe qui va tester
  • Estimation de l'effort de test
  • Limites: Toutes les hypothèses ou limitations acceptées à l'avance.
  • Les gens documentent en outre les critères d'entrée, les critères de sortie, les risques, etc., ce qui, à mon avis, n'a pas vraiment besoin d'être mentionné séparément car cela devrait plutôt être une compréhension normale.
    • Critères d'admission (Quand commencer les tests): rares sont ceux qui démarrent lorsqu'il y a une partie testable de la fonctionnalité disponible pour les tests. Rares sont ceux qui attendent que la fonctionnalité entière soit testable. Une fois que le flux de base fonctionne, le test démarre.
    • Critère de sortie (Quand arrêter): Lorsqu'il n'y a pas de bloqueur, les défauts critiques et majeurs (soumis à un impact) dans les tests en phase ouverte peuvent être arrêtés. Ou à mi-chemin, lorsqu'il y a beaucoup trop de défauts rencontrés, les tests peuvent être arrêtés par les parties prenantes appropriées.
    • Risque : Risque commercial ou risque fonctionnel si les tests ne se déroulent pas conformément au plan documenté.

# 5) Phase de développement

Phase de développement logiciel

L'équipe de développement après la phase de conception commence par le développement réel et les tests unitaires au fur et à mesure qu'ils sont terminés avec le développement de blocs d'exigences testables. Ils peuvent transmettre la fonctionnalité de test par blocs au fur et à mesure de sa mise en œuvre ou transmettre toutes les fonctionnalités en même temps.

Dans un scénario idéal, une révision formelle du code et des tests en boîte blanche ont lieu avant de transmettre la fonctionnalité développée pour les tests. Idéalement, l'équipe de développement devrait également se référer aux cas de test fournis par l'équipe de test en plus des exigences et des documents de conception.

# 6) Phase de test

Comme mentionné précédemment, le début de cette phase diffère d'une entreprise à l'autre, d'une équipe à l'autre.

L'équipe de test commence à tester soit quand une partie testable (quelque chose qui peut être testé indépendamment) de l'exigence entière est développée, soit lorsque l'exigence entière est développée.

quelles sont les étapes du sdlc

Permettez-moi d'approfondir cette phase et de parler des tâches importantes:

  • L'équipe de testeurs / tests commence par la phase de test (tests exploratoires et exécution de cas de test écrits) et enregistre les défauts
  • L'équipe de développement les résout selon la priorité.
  • La nouvelle construction (code) est prise sur l'environnement sur lequel les tests sont en cours
  • Les défauts résolus sont ensuite vérifiés par le testeur / l'équipe de test et marqués comme corrigés
  • Ce cycle se poursuit jusqu'à ce que les critères de sortie de temps soient atteints.
  • Veuillez noter que si nécessaire, les défauts sont également marqués comme non valides, dupliqués et peuvent également être classés comme améliorations.

Une autre chose qui diffère d'une entreprise à l'autre est le nombre d'essais à effectuer. Comme dans certains cas, la première série de tests a lieu sur les petites fonctionnalités au fur et à mesure qu'elles sont prêtes, suivie d'une série de tests de bout en bout sur un autre environnement une fois que toutes les exigences sont développées. Mais encore une fois, j'ai également entendu parler de personnes effectuant trois essais complets et une quatrième ronde de santé mentale / fumée.

Le premier ordre du jour derrière la réalisation de plusieurs cycles de test consiste à tester la fonctionnalité sur différents environnements et le second à effectuer des tests de bout en bout une fois que tous les points d'histoire sont développés. Le tour de santé mentale arrive généralement à gagner rapidement en confiance une fois que toutes les histoires d'une version sont développées et testées indépendamment.

Lire les étapes détaillées=> Phase d'exécution du test

# 7) Examen de Business Analyst (BA)

L'analyste commercial examine la fonctionnalité demandée en se référant au résultat du test ou en se référant au résultat du test et en jouant avec l'application pour obtenir une impression réelle. Cette étape est à nouveau soumise à différentes actions à travers les entreprises.

Le BA peut revoir la portée de la version entière en une seule fois ou en morceaux. En fonction de la même chose, cette étape peut intervenir avant le test de cohérence final ou après le cycle de test de cohérence final par l'équipe de test.

Au-dessus de 7 étapes se produisent pour toutes les user stories / exigences à remplir en particulier Release (Shipment). Une fois que toutes ces étapes sont terminées pour toutes les exigences, la version est dite prête à être expédiée.

# 8) Expédition / Libération

La version est étiquetée comme Prêt pour l'expédition après examen réussi par l'analyste commercial.

Lecture recommandée=> Processus de libération des tests

Types de tests manuels (lus sur l'homme)

Eh bien, si nous devons parler des types globaux de tests en chiffres, alors j'ai trouvé quelque part 100 types de tests avec des noms différents . Pour être honnête, je ne suis pas assez intelligent pour comprendre la distinction entre tous ces types (jeu de mots).

C'est direct et simple: Tester la fonctionnalité de l'application par rapport à l'exigence donnée avec des efforts humains et de l'intelligence. Il est divisé en quelques types en fonction de la portée et du programme des tests. Types énumérés au paragraphe suivant.

Il est divisé en quelques types en fonction de la portée et du programme des tests. Types énumérés au paragraphe suivant.

Si je suis autorisé à le faire, permettez-moi de parler de quelques lignes de test humain (que j'encourage chaque testeur à faire plus que des tests fonctionnels manuels). Maintenant, ne soyez pas confus, à mon avis, les tests fonctionnels manuels sont un sous-ensemble des tests humains. Parce qu'il y a tellement de choses que seul l'esprit humain peut faire.

Vous trouverez ci-dessous la liste de certains des types de tests populaires et importants qui peuvent être classés en tests humains:

  • Test fonctionnel manuel : Tester la fonctionnalité de l'application par rapport à l'exigence donnée avec des efforts humains et de l'intelligence. En outre, il est divisé en plusieurs types en fonction de la portée et de l'ordre du jour des tests, tels que les tests système, les tests unitaires, les tests de fumée, les tests de cohérence, les tests d'intégration, les tests de régression, les tests d'interface utilisateur, etc.
  • Test de performance : Cela est classé dans les tests non fonctionnels, n'est-ce pas? Mais encore une fois, c'est l'humain qui l'implémente, bien que l'exécution soit faite par l'homme ou par un outil. Le testeur devrait au moins faire ces tests en termes de temps de réponse (pour voir si cela est acceptable) s'il n'est pas censé utiliser un outil pour les tests de charge et tout.
  • Le navigateur / Test de compatibilité de plate-forme: L'application testée doit ressembler et fonctionner comme prévu (il peut évidemment y avoir une différence mineure selon le moteur du navigateur) entre les navigateurs et les plates-formes (ou les appareils s'il s'agit d'une application mobile).
  • Tests d'utilisation : Permettez-moi tout d'abord de convenir qu'il s'agit d'un vaste sujet en soi et généralement détenu par des spécialistes des tests d'utilisabilité. Je crois toujours qu'en tant que testeur, nous devrions au moins signaler ou souligner si nous trouvons quelque chose comme moins utilisable, ou nous devrions partager notre point de vue.
  • Test de sécurité : Encore une fois très gros type de test et nécessite bien sûr beaucoup de connaissances pratiques. Le testeur doit essayer d'apprendre et d'exécuter au moins des tests de base tels que la falsification d'URL, les scripts intersites, l'injection SQL, le détournement de session, etc. en fonction des connaissances disponibles et le cas échéant.
  • Test multiclient: Si votre application est multi-locataire, c'est-à-dire une instance unique contenant les données de plusieurs clients, ce test est indispensable. Indépendamment de la mention explicite dans les exigences, cela devrait être fait. Les données d’un client présentées à un autre sont en quelque sorte un crime de développement et de test.

Remarque: Les vues ci-dessus sont mes vues personnelles. Je vous recommande également de consulter la liste exhaustive des types de tests pour vos connaissances et de les suivre / les utiliser si vous le jugez nécessaire. Au fil des années, j'ai compris que, que vous utilisiez quelque chose ou non, que vous croyiez en quelque chose ou non, vous devriez toujours avoir une certaine connaissance des concepts largement utilisés dans votre domaine.

C’est tout pour cette partie. Merci pour la lecture. Partagez vos opinions / commentaires dans les commentaires.

Dans la prochaine et dernière partie de ceci série de didacticiels de test manuel , Je vais essayer de vous aider tous avec quelle préparation vous devriez faire si vous cherchez à entrer dans le domaine des tests et quelles sont les façons possibles d'y accéder.

lecture recommandée

^