Vous pouvez certainement vous passer d'une stratégie de test si vous avez un nombre infini d'employés qualifiés, de temps et d'argent. En un mot, la possibilité de couper une version au fil des ans. Dans de telles conditions idéales hypothétiques, aucune stratégie n'est nécessaire, car vous pouvez tester votre produit de toutes les manières existantes aussi longtemps que vous le souhaitez, en appliquant les techniques dans n'importe quel ordre, pour plusieurs cercles, et tôt ou tard d'une manière ou d'une autre, vous arriverez à une qualité prête à la production.

En réalité, le projet brûle toujours le délai, les capacités / compétences de travail de l’équipe ne sont pas élastiques et les exigences des produits évoluent constamment - et ici, vous ne pouvez pas vous passer d’un bon plan. Par conséquent, une stratégie de test vient à la rescousse.

Dans cet article, nous proposerons des questions qui doivent être discutées afin d'élaborer une stratégie de test et montrerons avec des exemples comment les décisions sont prises concernant les outils de test dans un cas particulier.

0. Voyons cela sur le rivage

Pourquoi avons-nous besoin d'une stratégie de test?

• Organiser le processus dans des conditions de ressources limitées. Par conséquent, pour commencer, il serait bon de se rendre compte de nos ressources.
• Afin que tous les participants au projet comprennent le rôle du test, ce qu'il peut apporter, quels bénéfices nous en retirerons. Pour que chacun ait des attentes et une compréhension égales de ce qui se passe dans le domaine du contrôle qualité. Et aussi pour identifier les problèmes possibles qui deviendront inévitablement apparents dans le processus de discussion.

Qui compose la stratégie?

Tout d'abord, bien sûr, l'AQ et nécessairement un chef de projet.

Alors, prenez le chef de projet testeur ou le manager testeur par la main, versez du café, prenez du papier, des marqueurs, des ordinateurs portables, et ... c'est parti!

1. Quels types de tests utiliserons-nous sur le projet et pourquoi

Au tout début, nous proposons de rappeler tous les types de tests existants et de décider de chacun: allons-nous l'utiliser et pourquoi. Examinons quelques exemples de la façon dont vous pouvez décider de la nécessité d'un type spécifique de test.

Test de l'installation de la version

Dans tous les cas, même si l'application est complètement nouvelle et est installée (déployée) pour la première fois, vous devez vérifier comment elle a décollé: si elle démarre, s'il est possible de commencer à travailler avec. Qu'il s'agisse d'une application mobile, d'un ordinateur de bureau ou du Web.

Pour les applications Web, il est utile de discuter de la façon dont nous vérifions que les données après la mise à jour ne sont pas perdues. Quel genre de comportement nous attendons d'une session active.

Pour les applications de bureau et mobiles, vous devez penser à un moyen de fournir la nouvelle distribution à l'utilisateur et au processus de mise à jour, qui est lancé par l'utilisateur.

Pour tous les projets, il est utile de discuter de choses telles que l'échauffement du système: l'installation de répertoires, la configuration des utilisateurs et d'autres données dont l'utilisateur a besoin pour démarrer avec le système.

Test de performance

De tels facteurs influenceront la décision: combien d'utilisateurs travailleront dans le système, combien de données seront traitées.

Étant donné	Solution
Nous savons que 10 personnes utiliseront le produit. Et nous savons qu'ils vont remettre des tableaux de plusieurs milliers d'enregistrements.	Il est judicieux de planifier des tests de volume avec de grandes quantités de données.
Nous savons que lors de l'utilisation du produit, les utilisateurs téléchargeront de nombreux fichiers multimédias sur le serveur du client.	Vous devez savoir pour quel type de charge ce serveur est conçu et garder ces données à l'esprit.
L'application est utilisée par plusieurs personnes par semaine, la quantité de données est minime.	Les tests de performance ne sont pas requis.

Test de régression

Une vérification complète de l'ensemble du système prend toujours beaucoup de temps. Par conséquent, pour prendre une décision, il est nécessaire d'évaluer la pertinence: combien de temps est nécessaire pour une régression complète et les risques qui peuvent survenir si nous ne la réalisons pas.

Étant donné	Solution
Nous déployons la première version d'un module produit ou programme.	Un test de régression n'est pas requis.
Le projet est très important, et une régression complète avant la sortie de nouvelles fonctionnalités prend un temps comparable à la période de développement. Le taux d'approvisionnement requis ne le permet pas.	Nous décidons de ne pas effectuer de tests de régression, mais accordons plus d'attention aux autres types de tests et de surveillance.
L'interaction entre les microservices est couverte par des tests contractuels.	Une régression complète n'est pas pratique. Dans le cadre des tests manuels, nous effectuons une régression des fonctionnalités sur recommandation du développeur.

Test d'intégration

Pour déterminer la nécessité de tests d'intégration, il est utile de répertorier tous les systèmes externes avec lesquels le produit interagit et d'indiquer les données que nous recevons et transmettons.

Étant donné	Solution
Les données de vente du portail sont transférées vers le système analytique.	Il est important non seulement de vérifier que les ventes ont disparu, sont passées dans le bon format, mais aussi qu'elles sont arrivées dans le bon format - rien n'a été perdu en cours de route.

Test de localisation

Il est important de répondre aux questions sur le projet:

• quelles langues doivent être prises en charge
• prévoyons-nous la connexion de localisations supplémentaires pendant le fonctionnement de la solution,
• Dans quels pays nos utilisateurs travailleront,
• y aura-t-il des ventes et dans quelles devises
• Avez-vous besoin de travailler avec des fuseaux horaires?

Étant donné	Solution
Le système a 2 langues: russe et anglais.	Il est logique de discuter de la façon dont nous comprendrons l'interface dans quelle langue montrer l'utilisateur.
Le client demande de rendre l'application multilingue.	Il vaut la peine de répondre vous-même aux questions de savoir comment nous vérifierons les textes, d'où nous obtiendrons les textes en arabe, comment l'écran sera adapté pour le texte qui est écrit de droite à gauche.

Multi-navigateur et multi-plateforme

Nous ne pouvons pas vérifier le bon fonctionnement de l'application mobile sur tous les appareils en général. Dans le cas d'une application Web, la question se pose immédiatement: prendrons-nous en charge IE9? Avant d'entrer ce type de test dans la stratégie, nous analysons (si la solution fonctionne déjà) ou supposons (si elle ne fonctionne pas déjà) à quoi ils vont l'utiliser.

Étant donné	Solution
Les utilisateurs d'applications mobiles sont des employés à travers le pays.	Nous examinons les statistiques existantes sur l'utilisation des plates-formes de notre application et décidons lesquelles d'entre elles nous testerons.
Notre application a des utilisateurs d'entreprise sur des machines stationnaires.	Très probablement, nous pouvons recommander d'utiliser un seul navigateur. Et réduisez ainsi le temps de test et la prise en charge de la compatibilité entre navigateurs.

De même, vous devez analyser tous les autres types de tests:

• Fonctionnel (conduit ou non),
• Acceptation (qui la dirige et comment),
• UX / UI (quels sont les critères objectifs pour une bonne interface)
• Modulaire et unitaire (qui écrit les tests de contrat, qui écrit les tests unitaires et si nous les écrivons du tout),
• Tests de sécurité (qui garantit la sécurité des données et la résistance du système au piratage),
• Échec et récupération (comment le système se comportera en cas d'urgence)

et d'autres.

2. Priorités des tests

La force majeure se produit sur tous les projets, il est donc utile d'avoir une feuille de triche avec un plan bien pensé dans ce cas, plutôt que de saisir des boutons aléatoires.



En mode normal, des priorités significatives sont également importantes. Par exemple, le développement des autotests doit être planifié en tenant compte des priorités: tout d'abord, les scénarios les plus critiques sont automatisés (test de fumée).

Étant donné	Solution
Notre programme est utilisé dans les aéroports pour vendre des services aux passagers lors de l'embarquement dans un avion. Et si à ce moment une sorte d'erreur se produit, nous n'aurons pas le temps pour une correction à chaud. Par conséquent, il ne devrait y avoir aucune erreur!	Nous vérifions en premier lieu le scénario d'utilisation à l'aéroport.

3. Environnement de travail

Il est nécessaire de réfléchir et de coordonner avec l'équipe les environnements requis pour le travail et qui les utiliseront. En règle générale, 2-3 environnements et ventes suffisent.

Étant donné	Solution
Sur le projet CD / CI, des tests de fumée ont été écrits pour un test initial de fonctionnalité.	Nous avons besoin d'un environnement pour l'assemblage principal du code dans une branche, la course des tests de fumée, où les systèmes externes sont fermés par des talons. Vous avez également besoin d'un environnement pour les tests manuels et d'intégration avec les services clients (QA).
Des sessions de test bêta ont lieu régulièrement.	Nous avons besoin d'un environnement qui sera visible "à l'extérieur", plus stable que l'environnement QA.

4. Travail du testeur sur le projet

Il est logique de discuter à l'avance de toutes les activités que nous attendons du testeur sur le projet, car elles ne sont pas nécessairement les mêmes sur tous les projets. Cela pourrait surprendre un membre de l'équipe que le testeur fasse ou ne fasse pas quelque chose.

Cet élément aidera les gestionnaires à comprendre le degré de compétence requis du testeur et la charge de temps attendue. Pour les projets existants, il est également important d'indiquer que nous (AQ) sommes en mesure de faire en sorte que le manager comprenne de quels moyens il dispose.

Par exemple, cela pourrait être:

• évaluation des objectifs de sprint pour l'exhaustivité et la cohérence,
• évaluation des coûts de main-d'œuvre pour les tests,
• préparation de listes de contrôle pour les tests (ou cas de test),
• examen du script d'autotest
• écriture d'autotests fonctionnels,
• tests manuels directs,
• déploiement de modifications de l'environnement,
• mise à jour des stratégies de test, etc.

5. Documentation de test sur le projet

Il est nécessaire de se mettre d'accord sur le rivage, et éventuellement de revoir régulièrement et régulièrement le format de la documentation de test:

• quelle documentation de test nous allons mener sur le projet,
• allons-nous écrire des cas de test
• faire des listes de contrôle
• et à quelle fréquence mettre à jour cette documentation.

Étant donné	Solution
Environ 300 cas de test ont déjà été écrits pour environ un tiers des fonctionnalités du système. Ils doivent non seulement être révisés périodiquement, mais également mis à jour de temps à autre.	Dans des conditions de ressources limitées, nous avons décidé de ne pas travailler avec des cas de test, mais de nous limiter à des listes de contrôle pour chaque tâche spécifique. Et en conséquence, nous gagnons du temps sur la documentation de support sans perdre la qualité des tests.

6. Comment les cas de test sont générés

Les conditions de fonctionnement et les scénarios dépendent de la solution spécifique, alors assurez-vous de discuter:

• quelles techniques de conception de test il est logique d'utiliser. Dans le cadre de ce paragraphe, il est utile de dresser une liste des objets avec lesquels l'application fonctionne et leurs classes d'équivalence.
• quelle heuristique et expérience de vie banale aident à trouver des scripts de test pour un projet spécifique. Pour les applications mobiles, il est pratique d'utiliser des heuristiques standard, par exemple, «I SLICED UP FUN».

Étant donné	Solution
Sur le projet d'assurance, l'utilisateur (agent) doit inspecter la machine, au cours de laquelle il est nécessaire de prendre des photos et de les télécharger sur le serveur. Le bon sens veut qu'il n'y ait pratiquement pas de wifi dans les garages. Et parfois, il n'y a pas de connexion mobile.	Vous devez donc vérifier l'application non seulement lorsque vous travaillez avec la 3G, mais également en l'absence de communication en tant que telle.
Toute action de l'utilisateur dans l'application mobile de la compagnie aérienne fait partie d'un scénario. Par exemple, vous ne pouvez pas émettre de ticket sans avoir préalablement créé une réservation.	Par conséquent, il est logique d'utiliser la technique du «cas d'utilisation».

7. La procédure de travail avec le tracker

Dans différents trackers, les possibilités et les types de tâches diffèrent. Sur la base des capacités du tracker, nous vous conseillons de vous mettre d'accord sur qui et selon quel principe détermine la priorité des tâches, dans quel type de tâches pour organiser les bugs et les tâches.

Parlez des points clés avec l'équipe:

• Comment allons-nous faire la distinction entre les erreurs trouvées par nous et les erreurs trouvées par les clients (et si nous devons les distinguer),
• Comment apporter des améliorations
• Faut-il distinguer les améliorations que nous avons nous-mêmes inventées de celles que le client a demandées. Comment?
• Quel statut faut-il faire si une erreur ne se reproduit pas,
• Quel statut est considéré comme définitif.

Étant donné	Solution
Le testeur crée un bug. Le développeur ne peut pas le reproduire, le traduit en statut rejeté.	Le testeur revérifie la tâche et définit le statut sur Fermé (final), si l'erreur disparaît vraiment, ou affine la description et revient à Nouveau.
Le client définit la tâche de révision. Le développeur comprend qu'il n'a pas suffisamment de données à mettre en œuvre.	Le développeur place la tâche dans l'état Feedback.

(Nous avons écrit plus sur les façons de décrire les bogues et l'histoire utilisateur dans cet article ).

8. Critères de démarrage et de fin des tests

Si le testeur prend n'importe quelle tâche à tout moment, ce n'est pas de l'ordre, mais du chaos. Parce que la tâche n'est peut-être pas prête. Ou prêt, mais pas gratuit. Ou prêt, déployé, mais dépend d'autres tâches qui ne sont pas encore prêtes. En conséquence, le testeur passe du temps et des nerfs à rechercher et à corriger les erreurs, mais en fait, il vous suffit d'attendre. Par conséquent, nous convenons à quel moment le domaine de responsabilité de l'AQ sur la tâche commence et se termine.

Aux premiers stades du développement du projet, l'état de préparation de la tâche / version est déterminé par l'œil.
Avec la croissance de la conscience de soi, nous comprenons que nous avons besoin de critères clairs pour que la tâche / version soit prête. Pour que cette décision soit transparente pour tout le monde, et non «le testeur sent le butin que tout est normal». Par exemple, dans le contexte d'un CD réglé, nous pensons que la tâche est prête à être testée dès qu'elle est déployée dans l'environnement QA et a le statut Résolu.

Étant donné	Solution
Un processus a été mis en place sur le projet selon lequel une liste de contrôle pour les tests est compilée pour chaque révision.	Nous considérons la tâche vérifiée si nous avons réussi tous les points de la liste de contrôle.
Le projet travaille sur les sprints.	Le sprint est considéré comme prêt si toutes les améliorations sont à l'état Fermé et qu'il n'y a aucune erreur avec la priorité Normale et supérieure.
Le projet a compilé une liste de fonctionnalités par priorité.	Nous pensons que la version est prête à être publiée si la fonctionnalité des premiers points de la liste fonctionne correctement.
Le projet a rédigé des cas de test et effectué des tests de régression avant sa publication.	Une version est considérée comme prête à être publiée si, sur la base des résultats des tests de régression, aucune erreur de priorité Normale ou supérieure n'a été trouvée (ou le pourcentage de scénarios infructueux n'était pas supérieur à 5).

9. Outils de travail

La section est alors utile pour confier les tâches (à l'administrateur et au manager) déjà au stade de la planification des tests et obtenir tous les outils nécessaires au début du travail.

Il vaut la peine de discuter de ces questions:

• De quels outils avons-nous besoin pour réaliser la documentation de test,
• Quels outils peuvent préparer les données de test,
• Quels outils sont nécessaires pour l'automatisation.

Étant donné	Solution
Pour décrire la fonctionnalité implémentée, nous avons décidé d'utiliser des cartes mentales.	Les gars de l'équipe travaillent sur différentes plateformes, vous devez donc choisir un format de fichier de carte mentale avec lequel vous pouvez travailler sous Windows, Linux et Mac.
Nous avons convenu que nous avions besoin d'une automatisation du projet.	Donc, nous avons besoin d'outils qui nous permettront de préparer des données de test (par exemple, pour rouler des scripts dans la base de données), nous permettre de lancer dans le pipeline (par exemple, newman), et nous permettre de créer des talons (par exemple, WireMock).

10. Outils d'évaluation et de suivi de la qualité des projets

Dans cette section, nous proposons de convenir des KPI pour évaluer la santé de l'application (en plus du calcul évident de la couverture du test). Cet indicateur doit être mesurable et réalisable. En particulier, comprenez et répondez aux questions suivantes:

• Comment nous suivrons les erreurs dans le prod
• Comment collecterons-nous les commentaires des utilisateurs,
• Comment collecterons-nous des statistiques sur l'utilisation de nos fonctionnalités.

Étant donné	Solution
Après la publication d'une nouvelle fonctionnalité du système, la surveillance de l'utilisation est configurée (par exemple, le nombre de ventes de services).	Cette baisse est un déclencheur de l'enquête. Peut-être que la fonctionnalité ne fonctionne pas comme prévu, ou nous n'avons pas implémenté une partie du script.
Nous avons configuré le programme pour surveiller la vitesse d'exécution des opérations de base.	Le critère de qualité du travail sera qu'avec un afflux d'utilisateurs, la vitesse d'exécution ne baisse pas.

Conclusion

Il n'existe pas de stratégie de test unique et universelle adaptée à tous. Il est conçu individuellement pour chaque projet.

• Il est important de comprendre que la stratégie ne doit pas être une fin en soi - c'est seulement un outil qui nous permet d'atteindre nos objectifs.
• Il est tout à fait normal qu'il ne soit pas toujours possible de répondre immédiatement à toutes les questions posées. C'est l'occasion de reparler avec le client ou les utilisateurs du produit.
• Le projet prend de l'ampleur et si hier il était trop tôt pour se soucier de la productivité, alors demain ce sera probablement le moment. Par conséquent, après avoir élaboré une stratégie, il est important de la mettre à jour et de la réapprovisionner régulièrement et d'apporter des changements à l'équipe.
• Après avoir écrit une stratégie, il devient généralement clair où se trouvent les échecs dans les tests et ce qui doit être fait. C'est l'occasion de fixer des objectifs, d'observer la dynamique et ... de mettre à jour la stratégie après un certain temps.