Perfectionnement des tests d'assurance qualité - Un didacticiel sur le flux d'utilisateurs

Alors que les produits et services se déploient de plus en plus vite, l'assurance qualité (AQ) doit s'adapter à l'évolution de l'environnement, atteignant parfois le même niveau de couverture dans un laps de temps plus court. Comment éviter l'erreur de Quantité sur Qualité ? Comment couvrir davantage, augmenter l'efficacité et être toujours efficace dans notre travail ?

Nous savons tous que les cas de test prennent beaucoup de temps à créer. Nous devons appliquer différentes techniques, types de tests et documenter les conditions préalables, les étapes et les résultats attendus. De plus, nous devons créer un plan de test.

Les spécialistes de l'assurance qualité se retrouvent souvent à court de temps, surtout lorsqu'ils essaient d'accomplir toutes les phases du processus d'AQ. Le plus gros casse-tête est la phase de planification et de conception des tests, qui tourne autour de la création de cas de test et de la documentation des tests. Cela peut prendre des heures, parfois même des jours d'efforts pour faire tout le travail, et généralement, ils choisissent de sauter certains livrables et de résumer à la place, en omettant des informations importantes qui peuvent conduire à l'oubli d'un test. Cela se traduit également par la perte du bénéfice du partage des connaissances.

Les tests d'assurance qualité traditionnels rencontrent le flux d'utilisateurs

Je suis un grand fan des cas de test traditionnels et des plans de test. Ils aident non seulement à identifier des tonnes de cas de test, mais ils documentent également très bien le produit. Vous pouvez les utiliser en formation, et toute personne de l'équipe les comprend. Vous n'avez pas à trop compter sur l'expérience pour que quelqu'un commence à tester. Les plans de test contiennent des informations supplémentaires telles que le détail de la portée, les éléments de test, les fonctionnalités que vous testez et celles que vous ne testez pas. Il y a aussi une analyse des risques qui entre dans le plan de test. Ce ne sont là que quelques-uns des avantages, cependant, le temps total que cela prend est trop long dans de nombreux cas.

Le but d'un plan de test est un moyen de communication et un accord entre les parties prenantes du projet. Il aide à détailler les objectifs, les ressources nécessaires et toute approche ou stratégie pour tester le produit. Le plan permet de s'assurer que tout est pensé et donne aux parties prenantes l'assurance que le processus d'assurance qualité est stratégiquement investi. Il n'y a pas de règle concrète selon laquelle ce plan doit faire 10 pages. Nous pouvons le redéfinir pour l'adapter à une équipe au rythme rapide.

L'alternative consiste à rationaliser les cas de test traditionnels et le plan de test d'une manière qui réduit l'investissement en temps requis, mais offre la même couverture et la même documentation, sinon plus, qui ont du sens pour toutes les parties prenantes. Cela implique une seule source de vérité, un flux d'utilisateurs avec une torsion. En structurant et en maintenant un flux d'utilisateurs, l'essentiel de la conception de votre cas de test sera déjà fait pour vous. Cela peut être appliqué à n'importe quel produit ou équipe et est polyvalent dans ses détails et sa structure.

L'utilisation de la méthode de flux vous aidera à obtenir un délai d'exécution plus rapide avec votre documentation de test. Ce n'est pas seulement pour l'AQ manuelle mais aussi pour l'automatisation. Le flux peut également contribuer à certaines sections du plan de test.

Aller dans le sens du courant

Sans plus tarder, plongeons-nous directement dans la création d'un flux d'utilisateurs pour un site Web de messagerie simple.

Nous aurons d'abord besoin d'un outil de cartographie mentale gratuit. Personnellement, j'utilise XMind. N'hésitez pas à télécharger n'importe quel outil avec lequel vous êtes à l'aise - nous n'utiliserons que des fonctionnalités de base telles que le dessin d'un organigramme, l'ajout de "notes" à certains des sujets, la coloration de différentes conditions et l'utilisation d'étiquettes.

Notre première étape consiste à comprendre le produit. Habituellement, vous ferez référence à des images de maquette ou à des wireframes. Si aucun de ces éléments n'est disponible, un appel de rattrapage rapide avec un développeur donnera exactement les écrans auxquels s'attendre. N'hésitez pas à suivre et à pratiquer au fur et à mesure que nous progressons. Le flux n'est pas seulement limité à une interface utilisateur et peut également être utilisé pour cartographier les appels d'API à API, les diagrammes de base de données, les structures de dépendance, etc. Les mêmes principes s'appliquent.

Conditions, États, Actions

Nous restreignons notre flux en n'utilisant que trois acteurs. Vous aurez une Condition , qui est comme un utilisateur avec un rôle particulier, un cache vidé ou un utilisateur se connectant pour la première fois. Deuxièmement, nous avons un State/Page , qui est un véritable composant de l'interface graphique, comme une page d'accueil ou une fenêtre de connexion. Vient ensuite l' Action , qui est une interaction physique de l'utilisateur qui provoque le changement d'état. Voyons cela en action.

Analyse des besoins

Ceci est notre page d'accueil, qui est l'État. Nous avons deux actions possibles : s'inscrire et se connecter.

Ensuite, nous avons la fenêtre de connexion, un autre État. Les actions ici sont Retour et Connexion. Notez que nous ne classons pas les champs d'entrée comme des actions. Vous êtes plus que bienvenu pour le faire. D'après mon expérience, j'ai constaté que lorsque vous travaillez sur des systèmes complexes qui s'exécutent sur quelques dixièmes de profondeur, cela devient un peu difficile à maintenir, mais pour des applications simples, cela peut être un excellent choix.

Enfin, nous arrivons au tableau de bord sur lequel l'utilisateur arrivera lorsqu'il se sera connecté avec succès. Ici, nous avons trois actions : nous pouvons créer, modifier ou supprimer un message.

Nous avons maintenant suffisamment d'informations pour commencer le flux d'utilisateurs. Résumons ce que nous avons. Nous notons les états du produit. D'après ce que nous pouvons voir, il y a quatre pages :

1. Page d'accueil
2. Fenêtre de connexion
3. Fenêtre d'enregistrement
4. Tableau de bord

Nous écrivons nos actions sur chaque page/état qui peut être "interagi" avec :

1. Page d'accueil
   1. Connexion
   2. S'inscrire
2. Fenêtre de connexion
   1. S'identifier
   2. Annuler
3. Fenêtre d'enregistrement
   1. À déterminer (selon le produit)
4. Tableau de bord
   1. Créer
   2. Éditer
   3. Supprimer

Nous commençons par le nom du produit , qui peut être modifié pour s'adapter à votre environnement, mais cela convient à la plupart des équipes et à leurs produits et constitue également un bon point de départ. Ci-dessous, nous remarquerons un point d'interrogation à côté de S'inscrire .

Souvent, vous rencontrerez un composant dans Agile qui n'est pas encore dans la portée ou prévu pour une future version. Prenez note de son existence, mais laissez-le comme inconnu jusqu'à ce que nous obtenions plus d'informations.

Dessiner le diagramme de flux

Nous dessinons ce qui précède dans XMind pour ressembler à :

Vous remarquerez que je suis simplement en train de coder par couleur ce qui est un état et ce qui est une action. J'ai également ajouté une ligne de l'action d'annulation à la page d'accueil pour représenter ce flux avec précision. Nous voyons également deux conditions lorsqu'un utilisateur sélectionne "Connexion". Bien que les deux aillent au tableau de bord, nous voulons toujours tester les deux conditions possibles.

La bonne chose avec XMind est que si nous travaillons sur une grande application complexe, nous pouvons créer différents niveaux du diagramme, donc si vous voulez diviser le flux en plusieurs flux mais les garder liés, c'est très facile à faire avec la liaison les sujets sur des feuilles séparées. Vous pouvez choisir d'insérer un lien hypertexte, et à partir de la fenêtre contextuelle de l'assistant, vous pouvez choisir un "État" auquel l'action mène. Cela signifie que si vous sélectionnez "Connexion" sur XMind et qu'il renvoie vers "Tableau de bord", le curseur de votre souris passera à "Tableau de bord", même s'il se trouve sur une feuille différente. Plutôt cool.

Ce qui manque à notre flux, ce sont les étiquettes. Nous donnons au produit une étiquette de 0, car c'est la racine du flux. Ensuite, pour chaque État (bleu), nous ajoutons une étiquette S#, pour chaque Action (vert), nous ajoutons une étiquette A#, et enfin, pour chaque Condition (cyan), nous ajoutons une étiquette C#. Chaque étiquette doit être unique. Nous terminons avec ce qui suit :

Pour savoir quel numéro vous avez utilisé en dernier, car à mesure que le produit grandit, essayer de trouver le numéro le plus élevé peut être difficile, je le stocke dans le sujet racine du flux, comme ci-dessous :

Nous arrivons maintenant à la partie de la création des cas de test. Nous allons nous concentrer sur les résultats attendus, qui sont probablement les informations les plus importantes dans un cas de test et font partie des critères d'acceptation de la fonctionnalité. Je vais ajouter un titre pour chaque section ou test, puis énumérer les résultats attendus en dessous. Je ne le ferai que pour un sous-ensemble afin de garder cet article concis :

Ensuite, la fenêtre de connexion :

Ensuite, l'action de connexion :

Ça prend vraiment forme. Notez les tests de limite et de sécurité ajoutés. Vous pouvez l'intituler comme bon vous semble, selon ce qui est le plus facile à étiqueter pour vous. Je tague parfois le titre avec un type de test, tel que Sécurité - JS Inject - Email Field, puis liste les résultats attendus ci-dessous.

Dans la plupart des équipes, nous trouvons que les exigences changeantes sont difficiles à maintenir. Pas plus. Disons que nous venons d'apprendre que tous les nouveaux utilisateurs doivent se voir présenter la fenêtre Ts and Cs et doivent accepter avant de passer à leur tableau de bord - pas de problème. Nous pouvons ajouter l'état et les actions relativement facilement, comme ci-dessous :

Nous voyons maintenant l'impact de l'ajout d'un nouvel état. Notez que la numérotation peut être étrange au début, mais tant que nous nous en souvenons, les numéros ne servent qu'à identifier de manière unique chaque acteur, un peu comme une clé primaire sur une base de données. N'oubliez pas de mettre à jour vos notes "Dernière utilisation" pour garder une trace des numéros que vous utilisez.

Création des cas de test à partir du flux

Après tous ces progrès, nous arrivons maintenant à la partie la plus facile : la création de cas de test. Permettez-moi de souligner quelques points importants. Nous avons des étiquettes pour chaque acteur, nous avons des titres pour chaque test et nous avons des résultats attendus pour chaque test, avec des conditions intégrées dans notre flux. Cela ressemble à la recette d'un cas de test, vous n'êtes pas d'accord ?

Tout ce que nous faisons maintenant est de copier-coller ce qui se trouve sur notre flux dans n'importe quel outil de gestion de cas de test, site Confluence ou document Excel que vous souhaitez. J'utilise toujours le bon vieux fidèle Excel. Je garde une trace de tous mes cas de test dans un fichier appelé "Baseline" - très original. Une fois le copier-coller terminé, je me retrouve avec ceci :

N'hésitez pas à ajouter des colonnes pour les types de test, l'état du test et les configurations de test selon vos besoins. Les conditions peuvent être mieux placées avant l'action "Connexion", cependant, il n'y a pas de bonne ou de mauvaise façon de le faire, cela dépend de vos préférences personnelles et de la façon dont vous vous organisez.

Il y a quelques éléments à souligner. La première est que j'ai fusionné des cellules qui partagent les mêmes informations - pas besoin de copier-coller à plusieurs reprises, cela fait perdre du temps et est plus difficile à maintenir. Un autre élément est les étapes. Vous remarquerez que deux des tests comportent des étapes qui intègrent les numéros d'état et d'action. Cela peut être utilisé lorsque vous avez le flux dans le cadre du SDLC dans votre équipe. Toutes les parties prenantes contribuent ensuite au flux en fournissant des informations, des maquettes, en augmentant les risques, etc. Cela signifie qu'en indiquant les numéros de flux, tout le monde dans l'équipe saura quoi faire, et s'il y a un nouveau membre dans l'équipe, c'est aussi simple comme "suivre la piste, référencer les notes".

Cela aide également à l'automatisation. Vous pouvez donner à chaque étape ou action une référence unique. En créant un pack d'automatisation structuré comme votre flux, vous constaterez que le cadre d'automatisation que vous pouvez créer a le potentiel d'être très robuste, modulaire et compatible dans toute l'application. Il utilisera des objets de pagination à plus grande échelle, ce qui réduira le temps de maintenance et vous permettra de remplacer les fonctions de test par de nouvelles.

Le flux peut être la seule source de vérité pour toute la documentation du produit, y compris les spécifications techniques, les spécifications fonctionnelles, les cas de test, la transition d'état, les flux de données, etc.

L'approche du plan de test simplifié

Alors qu'en est-il des plans de test ?, vous devez penser. C'est simple. Un plan de test contient des sections telles que :

1. Présentation et portée
2. Articles de test
3. Fonctionnalités à tester
4. Fonctionnalités à ne pas tester
5. Hypothèses
6. Critère d'entrée
7. Critère de sortie
8. WBS
9. Des risques
10. Exigences environnementales

L'introduction et la portée seront l'histoire JIRA ou toute tâche ou histoire dans un autre outil. Les éléments de test sont simplement les versions logicielles ou les numéros de validation actuellement déployés sur votre environnement, que vous pouvez lier au ticket JIRA ou lors de votre test sur Confluence ou l'outil de gestion des tests.

Les fonctionnalités à tester et les fonctionnalités à ne pas tester sont en fait vos cas de test. Les cas de test choisis pour être exécutés pour cette histoire JIRA sont des « fonctionnalités à tester », et tout ce qui n'est pas répertorié est des « fonctionnalités à ne pas tester ». Tout simplement, listez les états et les actions que vous allez tester sur le ticket de l'histoire.

Les hypothèses, les risques et même les exigences d'environnement peuvent être compilés dans un document ou ajoutés aux commentaires sur JIRA, parfois même placés sur Confluence et liés à l'histoire.

Un WBS est une estimation que vous attribuez à l'histoire en termes de points d'histoire ou d'heures, selon votre projet. Les critères d'entrée et de sortie feront déjà partie de l'histoire.

Si vous voulez être proche des plans de test "traditionnels", vous pouvez demander au développeur ou à d'autres parties prenantes de commenter l'histoire avec un Oui ou un Non pour voir s'ils sont d'accord avec le plan d'assurance qualité ou non. Ceci sert techniquement de votre signature numérique. Tout cela peut être inclus assez facilement dans votre processus d'assurance qualité et vous aider à rationaliser votre documentation d'assurance qualité.

Qu'avons-nous appris ?

Le flux d'utilisateurs avec l'approche ci-dessus et les plans de test simplifiés pour utiliser les outils disponibles aujourd'hui nous aideront à réduire le travail répétitif et à aider l'AQ à atteindre un délai d'exécution plus rapide sans sacrifier la qualité.

Cette approche m'a aidé à rester organisé, à couvrir toutes les bases et à créer une documentation que toute l'équipe comprend. En Agile, cela sera vraiment utile, et la meilleure partie de cela est que nous respectons toujours l'une des approches Agile : "Simplifier la documentation".

J'espère vraiment que l'information a été utile. Tout dépend de vous en tant que lecteur. Il ne s'agit pas d'un ensemble concret de règles à suivre, ce ne sont que des lignes directrices pour vous donner des idées pour grandir et améliorer votre efficacité. Aucune technique ne conviendra à tous les projets, équipes ou produits, mais elle peut ouvrir la voie à une autre idée innovante.