Nous analysons en détail comment effectuer des tests manuels quand c'est mieux que des tests automatisés, ce que les testeurs doivent être en mesure de faire et comment ils peuvent construire leur carrière de junior à chef de file. Le guide a été préparé conjointement avec le chef du département des tests d'Agima Darina Gordeeva.
Salut Je m'appelle Darina Gordeeva. Je travaille dans l'entreprise AGIMA en tant que chef de service depuis près de 3 ans. Dans le domaine des tests et de l'assurance qualité depuis plus de 6 ans. Pendant ce temps, elle est passée d'un junior au chef de département, testant le fer, ainsi que les applications mobiles et web, automatisant et configurant les processus d'assurance qualité. Aujourd'hui, je vais vous parler des fonctionnalités, des capacités et des problèmes cachés des tests manuels.
Rappelez-vous que tout lecteur qui a utilisé le mot promo Habr peut obtenir une remise de 10000 roubles pour son cours préféré, tandis que les plus diligents et attentifs peuvent collecter une remise de 25000 roubles en résolvant des énigmes à partir de matériaux préparés conjointement avec l'agence Agima:
Efficacité, flexibilité, possibilité d'improvisation et autres avantages
Aujourd'hui, il existe de nombreux frameworks de test qui prennent en charge presque toutes les langues existantes. Il semblerait - vous pouvez prendre et automatiser. Mais même maintenant, les tests manuels sont importants.
L'une des explications de leur nécessité est qu'avec un test manuel du fonctionnel, nous pouvons obtenir des informations sur l'état du produit que nous analysons beaucoup plus rapidement, sur la qualité du développement. De plus, lors de l'automatisation, les cas prédéfinis doivent souvent être modifiés et mis à jour, et il faut du temps pour écrire des autotests.
Dans le même temps, au cours du processus de développement, le retour d'informations du client peut arriver lorsqu'il voit une fonction dans le produit fini qu'il décide de modifier avant la sortie - et si vous avez déjà préparé des tests logiciels pour cela, vous devrez les réécrire. La mise à jour des cas, les autotests et leur vérification prendront un temps précieux qui pourrait être utilisé pour mettre à jour cette fonctionnalité elle-même.
Tout cela signifie que l'objectif principal des tests manuels est d'abord de s'assurer que la fonctionnalité déclarée est fonctionnelle, sans erreur et donne les résultats attendus et planifiés. Sans eux, vous ne pouvez pas être sûr de pouvoir travailler. Cela est particulièrement vrai pour les fonctions pour la mise en œuvre desquelles le développement ultérieur est lié. Dans ce cas, l'agitation avec la création d'autotests pour ces fonctionnalités devient un facteur de blocage pour le développement complet du produit, décalant les délais et perturbant les délais. Le moment venu d'automatiser les cas viendra tôt ou tard - mais n'essayez pas de l'amener artificiellement à la poursuite de l'exception totale du travail manuel.
De plus, aux premiers stades du développement d'applications, l'automatisation peut être assez coûteuse. Vous aurez besoin d'un spécialiste avec des qualifications spécifiques (et éventuellement plus d'un). La mise à jour constante des tests nécessite des ressources jusqu'à la sortie de la fonctionnalité. Et les mois d'inactivité consacrés à lécher un autotest vont frapper la motivation de l'équipe.
Si vous souhaitez ajouter régulièrement de nouvelles fonctionnalités et suivre les actions des concurrents, avant de créer des tests automatiques, vérifiez toujours les capacités du produit manuellement. Tout simplement parce que les tests manuels accélèrent vos processus.
Cela est particulièrement vrai pour le développement mobile. La plupart de ces projets sont désormais développés en sprints courts, ce qui signifie que les fonctionnalités sont mises en œuvre à un rythme accéléré. Dans de telles conditions, le test manuel vous permet de donner un retour à l'équipe le plus rapidement possible: de signaler la présence de bugs - ou de le faire plaisir avec le fait que tout va bien et que vous pouvez continuer. Vous pouvez effectuer une série d'autotests plus tard, couvrant de grands tableaux de code avec leur aide. Les tests manuels aideront à préparer les cas pour ce test.
Les tests automatiques ne vous permettent pas de vérifier s'il est pratique d'utiliser les nouvelles fonctionnalités de l'application - les tests d'utilisabilité sont toujours effectués manuellement.
Skillbox recommande: Le cours en ligne Fullstack est un développeur mobile .
Dans les tests manuels, vous pouvez improviser, créant des combinaisons folles d'actions qui ne viennent jamais à l'esprit de l'utilisateur, mais qui peuvent être commises par lui accidentellement. Cela vous permet de créer de nouveaux cas.
De nouveaux cas apparaissent également car le testeur se pose constamment la question «et si?». Il trouve donc des façons originales d'interagir avec l'application - même si elles n'étaient pas dans les scénarios de base.
Problèmes de test manuel et leurs solutions
Le plus grand inconvénient des tests manuels est le facteur humain. Bien sûr, cela affecte tout ce qui se passe dans l'équipe - à la fois le travail des participants et les événements qui se produisent du côté client. Dans le cas de l'assurance qualité, la raison pour laquelle le testeur est faiblement immergé dans le processus et manque une erreur potentielle peut être n'importe quoi - un manque d'expérience, des problèmes familiaux ou un mal de tête.
Deux testeurs peuvent tester le même scénario de différentes manières. Que faire à ce sujet? Il est important que chaque résultat inattendu ou différent soit enregistré comme un cas. Pour que tout testeur puisse le tester en effectuant le même ensemble d'actions. Mais cela peut ne pas être suffisant - si le cas n'est pas suffisamment détaillé et que le testeur ne comprend pas la description. Bien sûr, il est impossible de garantir l'exclusion absolue du facteur humain - mais vous pouvez essayer de minimiser la probabilité des problèmes qu'il provoque.
Cela affecte également négativement les conditions de livraison des fonctionnalités dans les coûts de production et de main-d'œuvre: après tout, les cas désormais «délicats» inventés par les testeurs dans le processus sont ajoutés aux cas de base et régressions périodiquement conduits.
La situation est aggravée par la probabilité que certains des bugs rencontrés n'aient pas encore de description stricte car les raisons de leur apparition ne sont pas encore claires. Comment gérer ces nouveaux tests? Soit trouver la source de l'erreur et l'éliminer, soit - toujours automatiser le passage des cas problématiques - dans ce cas, la transition vers les tests logiciels sera justifiée à la fois en termes de temps et d'argent. (Non, cela ne contredit pas ce qui précède - car de telles situations surviennent déjà au cours du développement actif et à ce moment-là, vous déploierez en tout cas des processus de test automatique).
Dans tous les cas, l'apparition des premiers cas nécessitant des tests de régression ou la sortie de la deuxième version de l'application et la mise à l'échelle de l'équipe correspondant à ces événements est le moment où l'automatisation devient pertinente (mais n'exclut pas le test manuel des nouvelles fonctionnalités). À ce stade, l'automatisation commencera déjà à gagner du temps: le développeur lui-même, avant même le transfert au service QA, peut exécuter les tests de régression de la nouvelle fonctionnalité pour s'assurer qu'elle ne casse pas la fonctionnalité existante, et le testeur n'aura pas à parcourir les cas de base qui se sont à nouveau ennuyés. Un autre avantage de l'implémentation des autotests à ce stade est que vous pouvez les exécuter selon un calendrier spécifique - tous les soirs, les jours de fin de sprints, ou lors de la publication de nouvelles versions de l'application.
En même temps, il ne faut pas oublier certaines choses:
- créer des cas et écrire des autotests prendra du temps - posez-les en sprints;
- assurez-vous que le cas de l'autotest est bien écrit et détaillé et décrit un problème possible ou un scénario existant dans son intégralité;
- vérifier si l'autotest fonctionne correctement et s'il vérifie vraiment ce qui est nécessaire et le fait qualitativement.
Nous résumons: les tests manuels offrent un grand avantage en termes de vitesse et de coûts de main-d'œuvre dans les premières étapes, et à mesure que l'application se développe et qu'un grand nombre de tests de régression apparaissent, ils entrent dans la catégorie des «tests opérationnels» de nouvelles fonctionnalités dans un sprint séparé. Il sera pertinent et, si nécessaire, vérifiera d'urgence la manière dont l'application réagira aux changements du système d'exploitation ou à la mise à jour de l'environnement.
Étapes des tests: quoi, quand et comment
Si vous regardez le processus de développement dans son ensemble et les tests comme l'une de ses parties, alors avec une bonne planification, vous comprendrez toujours quoi et quand sera prêt. Cela vous permettra de mieux planifier le temps de certaines actions - puisque certains événements suivent logiquement d'autres et vous avez la possibilité de les organiser en chaînes en fonction de vos attentes.
Le testeur apparaît dans le processus de création de l'application dans les premiers stades. Ici, le client a une certaine idée, les analystes commerciaux collectent de cette exigence - et les testeurs commencent déjà à ce moment à travailler, vérifiant ces exigences.
Comment ça se passe? Ils posent des questions sur la fonctionnalité prévue. Ils essaient d'imaginer à quoi ressemblera l'application lorsqu'elle sera implémentée. Si nous parlons d'une nouvelle fonctionnalité dans un produit existant - ils découvrent comment elle va interagir avec les fonctionnalités existantes. Après que les développeurs aient évalué la complexité des idées du client et déterminé le temps nécessaire à leur mise en œuvre.
Après cela, la phase de conception commence. Ici, il devient nécessaire de comprendre comment les transitions entre les écrans seront effectuées, certains champs à valider, comment l'application ou sa fonction séparée interagira généralement avec l'utilisateur final. Dans le cas des fonctionnalités, il est important de comprendre comment elles seront incluses dans l'architecture d'une application existante.
Au stade de la conception , lorsqu'une carte des transitions entre les écrans est créée, le testeur clarifie le comportement des éléments individuels qui les composent et les effets visuels qui accompagneront certaines actions de l'utilisateur. De plus, le testeur valide l'intégralité des dispositions, confirmant qu'elles affichent tout ce qui est nécessaire pour implémenter la fonctionnalité prévue. Il sera également utile de vérifier indépendamment la disposition des mises en page pour se conformer aux directives.
Skillbox recommande: cours en ligne Conception d'applications mobiles
Avec le début du développement, les spécialistes de l'assurance qualité commencent immédiatement à écrire des cas de test. À différents stades de développement, ils peuvent avoir un niveau de détail différent, mais à la fin, il est souhaitable d'assurer une couverture maximale de l'ensemble des caisses de produits, de sorte que, après avoir reçu l'assemblage, vous puissiez commencer les tests immédiatement.
La première étape du test lui-même est le test de fumée: une évaluation que l'application ou sa nouvelle pièce est généralement prête pour vérification. Un test de fumée est un test pour savoir si une application ou une fonction spécifique est lancée en principe.
Un test de fumée est un moyen rapide de voir si nous pouvons même commencer un test fonctionnel. Le terme est venu des créateurs de circuits imprimés et de microcircuits, qui devaient d'abord s'assurer que le nouveau circuit ne brûlerait pas - d'où le nom: fumé / non fumé.
C'est un moyen rapide de s'assurer que nous avons vraiment réussi la tâche et qu'elle peut être mise en œuvre et non renvoyée aux programmeurs.
En utilisant le formulaire d'autorisation comme exemple, une fumée est une évaluation pour savoir si vous pouvez vous connecter du tout, sans spécifier si les données saisies dans les champs sont valides, si des fonctionnalités supplémentaires comme les rappels de mot de passe et d'autres choses fonctionnent. Si nous avons pu nous connecter en principe, nous pouvons procéder à une vérification approfondie et approfondie de ce module: prendre les cas négatifs, les valeurs limites, évaluer le respect des règles de validation établies.
L'étape suivante consiste à effectuer des tests de régression. En mode manuel ou automatique, le principal ensemble de tests pré-planifiés est effectué.
Les tests de régression sont bons car ils vous permettent de trouver des erreurs même dans les endroits où tout était en ordre auparavant. Cela est dû au fait que la régression est une évaluation de la fonctionnalité sur un ensemble standard de cas lors de la mise en œuvre de chaque nouveau module et de chaque changement d'application. En effet, lorsque les développeurs ajoutent de nouvelles fonctionnalités, la version actuelle peut être endommagée ou une nouvelle fonctionnalité peut entrer en conflit avec celles existantes.
Par exemple, l'ajout de nouveaux écrans, et donc la modification de la navigation, peut perturber le fonctionnement du menu, ou du moins l'afficher. En revanche, le refactoring global du code d'application peut apporter des surprises désagréables - après cela, il est également nécessaire d'effectuer des tests de régression.
Des problèmes peuvent être causés par la mise à jour de la bibliothèque utilisée par l'application et la modification de l'environnement dans lequel elle fonctionne. Plus vous mettez à jour l'application souvent, plus les contrôles de régression sont importants. Ne vous limitez pas à une vérification unique, effectuée lorsque la fonctionnalité est déjà implémentée - vérifiez toutes les modifications. L'automatisation des tests de régression vous aidera ici - tout simplement parce que les tests de régression manuels d'une nouvelle fonctionnalité qui a été créée en seulement une semaine peuvent prendre deux, voire plus, et le service de test restera simplement bloqué.
Une vérification complète, bien sûr, est effectuée lorsque la version candidate avec une ou plusieurs fonctionnalités est prête à être déployée en production, mais il est toujours nécessaire d'appliquer certains cas pertinents à certains stades de développement.
Tout se termine par le test de l'assemblage final - libération du candidat. Cela comprend la vérification de la version bêta par des testeurs internes, des tests commerciaux - évaluer le produit résultant par le client et recevoir des commentaires de sa part, ainsi qu'inviter un certain groupe d'utilisateurs à se familiariser avec la version alpha préliminaire de l'application ou ses nouvelles fonctionnalités. Après cela, l'application est prête à être déployée en production.
Mais le travail du spécialiste QA ne s'arrête pas là : il devra tester les mises à jour des applications et leur compatibilité avec les versions antérieures, compiler des cas pour vérifier les innovations et, si nécessaire, automatiser le passage de ces scénarios.
En parallèle, les testeurs participent à une analyse plus approfondie des statistiques collectées par les analystes, surveillant le comportement de l'application et la façon dont les utilisateurs interagissent avec elle. Cela permet non seulement de voir l'utilisation en direct des résultats de leur travail, mais aussi, parfois, de découvrir de nouveaux scénarios et des bogues inconnus qui provoquent le blocage de l'application.
Temps Rebus: devinez-le et une remise de dix pour cent sur n'importe quel cours Skillbox vous attend en ce moment ou montrez de la persévérance et collectez des réponses à tous les rébus - ces remises s'ajoutent (mais sans autres remises sur les cours Skillbox).
Cependant, ne tardez pas trop - la promotion fonctionne jusqu'au 30 août 2018. Rappelez-vous que le sujet de l'énigme est un mobile et que les mots anglais peuvent interférer avec le russe ici, alors faites attention! Soumettez une candidature pour le cours, et lorsque le manager vous contacte, donnez-lui un message, crypté dans un rébus (ou quelques-uns!).
Formalisation des tests: plan de test, format des rapports de bogues, rapports
Afin de préparer les tests fonctionnels, un ingénieur QA établit un plan de test. Il s'agit de la documentation dont il aura besoin pour tester le produit, une liste d'actions qu'il devra effectuer. Le plan de test indique le calendrier des tests, décrit le produit ou une tâche spécifique - afin de déterminer exactement ce qui doit être vérifié. Tous les principaux cas de test sont décrits en détail. Répertorie les types de tests nécessaires: fonctionnels et, par exemple, stress. La procédure d'automatisation de certains cas et les étapes auxquelles ils seront automatisés sont décrites.
Le plan de test se termine par une description du format du rapport: vous devez expliquer à l'avance sous quelle forme le résultat sera fourni. Le format de rapport le plus courant est une liste de cas de test avec le statut de leur passage. Sachant comment les cas couvrent l'intégralité du volume d'exigences et après avoir lu le rapport, nous pouvons conclure sur l'état actuel du développement de l'application. Pour ce faire, il suffira de voir combien d'entre elles ont été achevées avec succès dans l'un ou l'autre assemblage.
Le feu vert final, indiquant que le produit est prêt, est le statut "toutes les exigences sont couvertes par les cas, tous les cas sont terminés avec succès."
De plus, le plan de test formalise le format du rapport d'erreur. Cela peut être une liste de bogues, une liste de tâches dans le tracker.
La tâche du testeur est de fournir à tous les membres de l'équipe les informations les plus complètes sur la qualité du produit.
Ce que vous devez savoir et devenir testeur
Tout d'abord, le testeur doit être capable de penser et d'être attentif et assidu. L'expérience est importante - elle vous permet d'accumuler certaines réalisations et de consolider les connaissances des processus de test, en les transformant en compétences.
Un spécialiste des tests manuels n'a pas besoin d'être capable d'écrire du code et d'avoir une compréhension approfondie de l'architecture. Cela ne l'empêche pas de vérifier les fonctionnalités et de comprendre les principes d'interaction entre l'application et le serveur au niveau de l'application.
Un spécialiste des tests automatisés est une profession distincte, avec un ensemble de connaissances complètement différent. — , , , , , , . “ ”. , , .
, , . , — -. — , , — , . -. - . , .
( , ) , , . — , -.
- — , , , .
-, , — — . , .
— -. , , — , , .
- — -. , , , , , DevOps, , .
— , “Fullstack- ”. , . !
Skillbox recommande: