Rencontrez les auteurs de l'article de juillet pour le «Calendrier des testeurs » Andrei Marchenko et Marina Tretyakova, testeurs et analystes de Kontur. Ce mois-ci, les gars parleront des modèles de workflow pour tester les analyses et de la façon dont ils ont commencé à tester les analyses avant la phase de développement. L'expérience des gars sera utile aux managers, testeurs et analystes d'équipes de produits de taille moyenne qui ne vivent pas au sein d'une startup et pour qui la qualité est plus importante que la vitesse .

Modèles de workflow de test analytique

Modèle 1

Le testeur travaille avec l'analyse après avoir reçu la tâche terminée. Il valide la tâche en lisant l'analytique comme une documentation de ce que le développeur a fait. Tout se trompe, quel que soit le niveau de professionnalisme. Les défauts peuvent être dans l'analyse ou dans le code développeur.

Inconvénients:

• les défauts d'analyse ne seront pas détectés avant la phase de test,
• il existe un risque que la tâche de test revienne à l'analyse pour révision. Par conséquent, la tâche TimeToMarket augmente considérablement.

Les erreurs d'analyse identifiées lors des tests sont coûteuses ou très coûteuses.

Avantages:

• le temps du testeur est réduit pour les tâches où un analyste n'est pas nécessaire (infrastructure, refactoring).

Modèle 2

Le testeur est connecté à la tâche avant même son transfert au développement. Il regarde des prototypes sur une tâche ou lit simplement la documentation. Le testeur pose à l'analyste toutes les questions sur la tâche. L'analyste corrige rapidement les commentaires. Le testeur effectue des tests d'acceptation.

Inconvénients:

• le testeur devra étudier un domaine adjacent (conception d'analyses et de savoirs traditionnels),
• en passant à ce modèle, le testeur devra d'abord passer plus de temps à tester, car le processus "la tâche terminée est arrivée - je lis les analyses - je teste" s'étend jusqu'à "la description de la future tâche arrive - je lis les analyses - je teste les analyses - la tâche terminée est arrivée - je teste".

Avantages:

• la probabilité de trouver des erreurs d'analyse après le transfert de la tâche au développement diminue
• le testeur est déjà dans le contexte de la tâche, quand il arrive à lui pour le test, il le vérifie donc plus rapidement,
• les tests analytiques élargissent parfaitement les horizons, offrant au spécialiste la possibilité d'une future transition vers l'analytique,
• le développeur améliore la qualité de son code et du produit dans son ensemble, car avant de passer sa solution aux tests, il passe les tests d'acceptation.

Si l'équipe de développement ne dispose pas d'une revue du travail des analystes, le test de l'analyse améliore la qualité du produit et réduit le risque de transfert des tâches vers le développement avec des erreurs dans les TdR.

Lorsque nous avons recommandé le deuxième modèle aux testeurs travaillant sur le premier modèle, nous avons souvent entendu:

• "Nous avons en ligne et avons donc suffisamment de tâches en cours pour en prendre plus."
• "Parlez au manager."

La refonte du processus de développement est une tâche de gestion sérieuse.

Mettre en œuvre des tests analytiques avant le développement

Depuis près d'un an, comme dans le projet Kontur , la norme dans le processus de développement est une étape obligatoire de «test analytique». L'équipe n'y est pas immédiatement arrivée. L'impulsion a été l'augmentation du nombre de retours de tâches des tests à la phase d'analyse et un raffinement supplémentaire.

C'était particulièrement pénible pour les tâches volumineuses avec de nouvelles fonctionnalités. Les tâches frontales transférées à la phase de test étaient brutes, souvent rompues sur les scénarios les plus simples, implémentées différemment compte tenu de la «double pli» des définitions et des termes en analytique.

Le processus de test analytique n'apparaît pas au clic d'un doigt ou de tout type de magie. C'est un travail minutieux, mais il peut être divisé en étapes.

Étape 0. Vendez à l'équipe l'idée de tester l'analytique

Vous pouvez facilement imaginer une situation où vous recevez soudainement des commentaires de votre travail avec des commentaires, des suggestions et des corrections. La première pensée d'une personne normale serait: «Pourquoi avez-vous décidé de me tester? Ils ne me font pas confiance? Ils contrôlent la qualité de mon travail? » À ce stade, il est très important que l'analyste n'ait pas le sentiment qu'il est contrôlé pour la qualité et, en cas d'échec du test, il sera renvoyé.

Un certain nombre de questions peuvent être supprimées si les informations sont présentées dans la clé: «cela nous donnera l'occasion de découvrir plus tôt de nouvelles fonctionnalités, d'accélérer la phase de test et d'éviter l'introduction de défauts même mineurs dans le code.»

Une fois l'étape 0 terminée, vous pouvez continuer.

Étape 1. Mise en œuvre des tests analytiques dans le processus de développement

Après avoir convaincu l'équipe, nous commençons à introduire des tests d'analyse dans le flux de travail quotidien. Si initialement le workflow ressemblait à ceci:

Qu'après la mise en œuvre:

Si votre équipe dispose de plusieurs analystes qui effectuent un examen mutuel avant de confier la tâche au développement, alors nous procédons à un meilleur texte. Nous voulons dire que l'analyse analytique ne le teste pas, mais seulement une partie de celui-ci.

Étape 2. Test de l'analyse

Il existe des tâches lorsque les prototypes remplacent la version texte de l'analyse.

Dans ce cas, le prototype est également vérifié en tant que texte. Si les prototypes complètent l'analyse, il est utile d'examiner les dispositions de conception des fonctionnalités futures avant de lire la documentation. C'est votre seule chance de considérer la tâche en tant qu'utilisateur qui n'a pas lu le mandat et ne sait pas comment tout fonctionne et devrait fonctionner.

Ce qui peut être vérifié en analytique:

1. La solution proposée répond aux objectifs de la tâche.

Par exemple, si le but de la tâche est de recueillir les commentaires des utilisateurs, la solution doit impliquer l'enregistrement et le stockage des réponses des utilisateurs.

2. Unicité d'interprétation.

Par exemple, la formulation «afficher les informations de la journée en cours» peut être interprétée différemment. Vous pouvez comprendre comment «afficher les informations du jour sélectionné dans les paramètres» ou «afficher les informations du jour égal aujourd'hui».

3. Faisabilité de la décision.

La faisabilité est la capacité de mettre en œuvre les exigences écrites en analytique dans les limites bien connues de l'environnement de développement, du langage de programmation et de la complexité algorithmique. Les bons analystes peuvent garder à l'esprit l'algorithme par lequel ils peuvent résoudre le problème qu'ils ont écrit. Ce n'est pas un fait que les développeurs feront selon cet algorithme (ils sont plus compétents, ils trouveront des moyens de rendre l'algorithme optimal, etc.), mais sa présence même indique la faisabilité de la tâche.

4. testabilité.

Comment vérifier que la condition "améliorer les résultats de recherche" est remplie n'est pas claire. Mais si nous réécrivons la condition «les résultats de la recherche doivent être affichés à l'utilisateur dans la seconde qui suit la pression du bouton« Rechercher »- c'est clair.

5. La disponibilité de scénarios alternatifs.

Dans le libellé «Si le numéro et la date sont indiqués, nous imprimons le numéro et la date. Si la date n'est pas précisée, nous n'imprimons que le nombre "il n'y a pas assez de scripts:

• il n'y a pas de nombre, mais il y a une date,
• pas de données.

6. Traitement des exceptions.

Dans le libellé «Vous pouvez télécharger un document uniquement au format Excel», il n'est pas clair ce qui devrait se produire si nous téléchargeons des fichiers d'autres formats, et quelle erreur nous verrons lors de leur téléchargement.

Artefacts lors du test de l'analyse

Quels artefacts peuvent rester après le test de l'analyse:

• cas de test compilés
• listes de contrôle pour les développeurs.

Liste de contrôle pour le développeur - les vérifications de base nécessaires et complètes des principaux scénarios qui devraient fonctionner pour être testés. C'est aussi un outil pour améliorer la qualité du code. Avant de soumettre la tâche à tester, le développeur passe la liste de contrôle, identifiant rapidement les bogues par lui-même.

Le développeur doit être persuadé de parcourir la liste de contrôle du testeur, en supprimant les soucis intérieurs du développeur "ils me testent", en se concentrant sur "l'accélération du processus, l'accélération des tests, l'amélioration de la qualité". En conséquence, notre développeur passe en revue ces listes de contrôle et est heureux que ce ne soit pas le testeur qui ait trouvé les erreurs, mais lui-même ("personne ne découvrira ce que j'ai foiré dans un tel scénario de conneries").

Quel est le résultat

À première vue, il semble que l'introduction d'une nouvelle étape dans le processus de développement ne fera qu'augmenter TimeToMarket, mais c'est une illusion. Au début, bien sûr, le processus de test analytique sera nouveau et non testé, et le testeur y consacrera plus de temps. À l'avenir, acquérant de l'expérience, il pourra la mener plus rapidement. Et les résultats obtenus au stade des tests analytiques réduiront le temps au stade des tests directs et réduiront le nombre de retours au minimum.

Ce processus de test analytique a été mis en œuvre dans plusieurs équipes Contour. Les équipes de développement ont bénéficié d'un certain nombre d'avantages indéniables:

• gain de temps au stade des tests: la conception et l'analyse des tests ne coûtent rien, car tout a déjà été fait à l'avance,
• accélérer la rétroaction au développeur via la liste de contrôle, avant de trouver des bogues critiques,
• toutes les parties intéressées peuvent pré-vérifier les listes de contrôle et ajouter des contrôles (au stade du test, cette action est "plus coûteuse").

Nous pensons que vous pourrez bénéficier de ces avantages en mettant en œuvre la phase de test analytique dans votre projet.

Liste des articles du calendrier:
Essayez une approche différente
Test de paire raisonnable
Commentaires: comment cela se passe
Optimiser les tests
Lire un livre
Tests analytiques
Le testeur doit attraper le bug, lire Caner et organiser le déplacement.
Service de chargement
Mesures de service d'assurance qualité
Test de sécurité
Apprenez à connaître votre client
Prendre l'arriéré