En lisant des articles sur le thème des tests Web, deux sujets apparaissent sous condition: 1) les tests manuels sont en voie de disparition, les autotests (ci-après dénommés autotests sont les tests Selenium UI et REST) sont notre tout; 2) les tests automatiques ne sont pas une panacée; les tests manuels sont indispensables. Dans le même temps, les articles tendent à augmenter les exigences de qualité logicielle et de vitesse de développement des produits. Wrike est juste le cas lorsque ces exigences sont essentielles.
Le produit a déjà 12 ans, mais il est toujours en pleine croissance. Les déploiements ont lieu une fois par jour, et parfois deux. Par conséquent, il est extrêmement important pour nous que la régression soit effectuée exclusivement sur les autotests. Cependant, à Wrike (dans l'entreprise), il y a plus de 30 équipes de mêlée, et le personnel de l'équipe d'automatisation n'est pas en caoutchouc. Dans de telles circonstances, pour attendre au mieux l'automatisation des scénarios manuels, un ou deux sprints ne sont pas une option. L'expérience de notre entreprise indique qu'un testeur manuel peut écrire des autotests indépendamment, sous réserve de certaines nuances. Dans l'article, je vais en parler et pourquoi, à mon avis, cette capacité aide non seulement à suivre les tendances, mais sera également utile pour le testeur lui-même.
Processus standard
À quel processus de nombreuses équipes sont-elles habituées? Cela varie d'un cas à l'autre, mais les caractéristiques communes sont à peu près les mêmes. Il existe des départements de tests automatiques et manuels. Les testeurs manuels peuvent être répartis entre les commandes Scrum. Dans ce cas, l'automatisation, en règle générale, n'a aucun rapport avec une équipe spécifique.
Lorsqu'il travaille avec de nouvelles fonctionnalités, le testeur crée des scripts de test, dont certains il marque d'une manière prédéterminée pour les automates. En outre, s'il existe déjà des cas dans lesquels des ajustements sont effectués, ils sont également notés afin de mettre à jour le code. Les tests marqués sont ensuite transférés au service d'automatisation. Une équipe d'ingénieurs en automatisation se charge de corriger les problèmes actuels et d'écrire de nouveaux autotests dans l'un des sprints suivants. En plus de la programmation des scénarios de test, les tâches de l'automate comprennent l'exécution d'autotests, l'analyse des résultats, ainsi que le support et le développement du projet de test. Il s'avère que le département d'automatisation agit comme un exécuteur externe, et les testeurs manuels sont une sorte de clients.
Le client passe également du temps à compiler un mandat détaillé et précis, à discuter périodiquement des méthodes de mise en œuvre et à sélectionner les tests nécessaires. Il existe également des risques que, en l'absence d'autotests, les bogues soient ignorés. N'oubliez pas qu'il existe une couche de problèmes techniques qui ne peuvent être cumulés que sur des tests automatiques, ce qui permettrait de gagner beaucoup de temps. Ces tâches devront être vérifiées à la main dans la partie où l'automatisation manque encore.
L'entrepreneur, peu plongé dans les fonctionnalités de l'équipe, prendra le temps de s'immerger superficiellement dans la tâche et dans la connaissance du mandat. Dans le même temps, il est probable que le test ne soit pas correctement traduit dans le code, car il ne vérifiera pas ce que nous souhaiterions. En conséquence, l'efficacité de la base de test est réduite.
L'équipe d'automatisation, étant le seul contributeur au projet de test, a un contrôle total sur sa base de code, ce qui lui permet d'être facilement développé dans toutes les directions. Cependant, le temps pour cela devient insuffisant en raison de la charge croissante des autres équipes. Le problème peut être résolu en augmentant le personnel, mais le coût de l'automatisation dépassera alors son efficacité. Même si vous supprimez une partie de la charge, donnant aux testeurs manuels la possibilité d'exécuter des tests et d'analyser ceux qui sont tombés, cela n'apportera pas le bon résultat. Comme ils ne disposent pas d'outils pour déboguer les tests, ils peuvent ne pas comprendre que le test a planté en raison d'un changement de xpath et ainsi de suite.
En conséquence, à la sortie, nous obtenons que les autotests avec ce schéma ne suivent pas la croissance du produit, ce qui conduit à une mauvaise couverture du code. En raison d'une interprétation inexacte des savoirs traditionnels, les tests peuvent ignorer les bogues. Lorsqu'ils sont obsolètes depuis longtemps, ceux qui sont tombés ne sont pas réparés immédiatement, et il est difficile pour les testeurs manuels de déterminer immédiatement quelle partie du système est bien couverte par l'automatisation. Les autotests deviennent une sorte de boîte noire, à laquelle les testeurs se méfient. Par conséquent, le nombre de vérifications manuelles inutiles augmente, les termes des tâches sont allongés et la qualité diminue à long terme.
Vous pouvez travailler avec ces lacunes, mais plus le produit et l'entreprise sont grands, plus les participants au processus sont pénibles et, surtout, il est difficile de suivre la tendance à l'augmentation de la vitesse et à l'amélioration de la qualité. Le testeur lui-même devient otage de la routine et ne reste pratiquement pas sur le développement du temps.
Wrike way
Alors, comment ça marche sur l'exemple de l'équipe dans laquelle je travaille. Il existe des équipes de tests automatiques et manuels. Les données initiales sont toujours similaires, mais les différences commencent alors. Les testeurs manuels sont répartis entre leurs équipes de mêlée. Chaque équipe Scrum a son propre autotesteur. Parfois, il peut être attribué non pas à une mais à deux équipes, si la charge le permet.
Lorsqu'il travaille avec de nouvelles fonctionnalités, le testeur rédige des listes de contrôle, selon lesquelles il effectue ensuite des contrôles manuels. La partie minimale requise des tests de cette liste de contrôle est automatisée. Le testeur écrit lui-même ces autotests au moment où la fonctionnalité est en cours de développement ou de test. De plus, le code écrit est remis au réviseur pour révision. À de rares exceptions près, une tâche sans autotests ne peut pas être émise.
Bien sûr, Wrike n'est pas obligé d'écrire des autotests par des testeurs manuels. Cela reste à la discrétion de l'équipe. Vous pouvez tout donner à l'automatisation. Vous pouvez vous limiter à réparer les tests interrompus et / ou à écrire de nouveaux tests par analogie, et déléguer des tâches plus complexes (création de nouveaux tests ou extension d'anciennes poignées principales, objet de page ou étapes et classes de test) à un outil d'automatisation dédié. Tout dépend de vous, mais il est stupide de passer à côté des avantages qu'offre l'écriture indépendante de tests automatiques.
Toute notre régression est basée sur des autotests, et les responsabilités des testeurs manuels incluent l'exécution et l'analyse des échecs d'autotest. Pour chaque branche sur laquelle l'équipe travaille, ils effectuent des auto-tests en tant que garant initial et final de la qualité. Par conséquent, il est beaucoup plus facile pour ceux qui écrivent eux-mêmes les autotests de comprendre pourquoi un test exécuté sur leur branche s'est écrasé. Parfois, des outils tels que la réexécution et un rapport dans
Allure sont vraiment suffisants, où vous pouvez comprendre la raison de l'échec du test à partir de la capture d'écran et des étapes. Cependant, le meilleur assistant est souvent la possibilité d'exécuter des tests localement, de jouer avec les étapes ou de les exécuter en mode débogage, voir le xpath attendu et réel. Sans expérience de travail avec un projet de test, cela prendra beaucoup de temps ou il faudra distraire l'outil d'automatisation dédié.
De plus, l'écriture indépendante des autotests permet de les exécuter avant même la sortie de la fonctionnalité. Le testeur connaît toujours le degré de couverture de sa partie du système, et les tâches techniques se déroulent uniquement lors des tests automatiques, ce qui économise considérablement du temps et des ressources pour l'équipe. Les tests eux-mêmes sont toujours pertinents, car les plantages sont ajustés avant la publication. Les tests cassés sont corrigés immédiatement dans la même branche où de nouveaux sont écrits.
Le testeur manuel est immergé au maximum dans la tâche de l'équipe, par conséquent, le minimum nécessaire de tests automatiques est sélectionné, couvrant la plupart des cas. L'échantillon est révisé plusieurs fois pendant le test, car lors des vérifications manuelles, la fonctionnalité est étudiée plus en détail avec toutes les nuances. En conséquence, l'efficacité de ces tests augmente. L'écriture d'autotests vous permet de mieux comprendre l'architecture de l'application, les composants utilisés et l'interaction front-end avec le back-end. En fin de compte, ces connaissances aident à une approche plus consciente et plus efficace des tests de produits. Par exemple, si une commande apporte des modifications au composant général, il est plus probable que vous sachiez à l'avance si votre portée sera ou non affectée, car lorsque vous travaillez avec xpath, vous comprenez quels composants sont utilisés dans votre partie de l'application.
On peut soutenir que l'écriture des autotests prend du temps. Oui, les tâches seront publiées un à trois jours plus tard que d'habitude, mais à long terme, cela rapporte. De plus, il existe des méthodes d'optimisation. Par exemple, pendant qu'une fonctionnalité est en cours de développement, vous pouvez établir les listes de contrôle nécessaires et faire un blanc pour les tests, ce qui permet de gagner du temps. Si vous disposez d'une infrastructure de fonctionnalités prête à l'emploi, il est possible d'ajouter ou de corriger des xpath existants, si nécessaire, de créer un nouvel objet Page ou d'ajuster les étapes. Ensuite, au stade de l'écriture des autotests, après des vérifications manuelles, il vous suffit d'ajouter les blocs de code dans le bon ordre.
Grâce au framework développé par notre équipe d'automatisation, l'écriture d'autotests représente pour la plupart la compilation de code à partir de blocs - comme Lego. Cette simplicité vous permet de vous adapter rapidement aux testeurs manuels et de commencer à écrire des autotests par analogie avec ceux existants. D'après ma propre expérience, je dirai qu'il a fallu environ deux semaines entre le moment où je suis allé travailler chez Wrike et les premiers autotests que j'ai écrits, ainsi que d'autres tâches.
Le contrôle de la qualité des tests automatisés écrits est effectué par la révision du code. Pas une seule branche de test n'entre dans la version sans examen. C'est un bon moment de formation, car le testeur tire des informations utiles des commentaires sur son code et construit l'expérience de bonnes solutions: par exemple, il gère plus efficacement la bibliothèque Java standard ou définit xpath plus précisément. La prochaine fois, il sera clair comment travailler au mieux avec une situation particulière.
Bien sûr, le développement d'un projet de test, d'un framework, et la formation de testeurs manuels prennent les moyens de l'automatisation, surtout au stade initial, mais il me semble que ces efforts sont pleinement récompensés. Nous avons de nombreuses améliorations dans l'environnement de test automatisé qui facilitent notre travail. Le produit lui-même a une bonne couverture, vous pouvez donc compter sur la régression. Cela permet d'accélérer le processus de déploiement des fonctionnalités dans l'environnement utilisateur et protège considérablement les nerfs des testeurs.
Selon l'expérience de notre équipe, c'est l'un des meilleurs processus pour travailler avec un produit volumineux et en développement rapide dans une grande entreprise. De plus, il est conforme aux tendances actuelles en matière d'amélioration de la qualité des logiciels et de la rapidité de leur livraison aux utilisateurs. Le testeur lui-même se débarrasse pratiquement de la routine, se développe dans plusieurs directions et regarde l'application sous plusieurs angles.
En bref sur l'essentiel
Pour plus de commodité, je vais souligner les avantages d'un testeur manuel en un seul endroit, afin qu'il soit plus facile de réaliser leur signification individuellement ou tous ensemble:
- Une image plus complète se forme sur le niveau et la qualité de l'automatisation de vos oscilloscopes;
- Les autotests sont disponibles avant la sortie de la fonctionnalité, ce qui permet de vérifier rapidement sa qualité à tout moment;
- L'efficacité des autotests augmente, tout comme l'efficacité des tests en général;
- Une approche plus éclairée et plus efficace des tests est en cours d'élaboration;
- Se débarrasser des régressions manuelles monotones et des longs tests d'évaluation;
- Croissance personnelle et développement des compétences.
Pour résumer
Bien sûr, il n'y a pas de solution miracle. Ce qui convient à une entreprise peut être fortement rejeté par une autre. Dans le cas de Wrike, le produit se développe extrêmement rapidement et il n'y a pas de temps pour de longues régressions manuelles et des tests d'évaluation. Nous avons ce rôle joué par les autotests, qui couvrent presque tous les composants d'un énorme produit. Cela permet de maintenir la qualité, d'optimiser les ressources et de fournir plus rapidement de nouvelles fonctionnalités aux utilisateurs.
La mauvaise nouvelle est qu'elle ne peut pas se passer de bugs, mais dans notre cas, le plus souvent, ce sont des cas extrêmes. La bonne nouvelle est que les bogues lors des corrections sont également envahis par les autotests.
Pour une raison quelconque, il est devenu si courant dans la communauté que l'idée d'écrire des autotests par des testeurs manuels est rejetée. Il y a deux arguments les plus populaires de la part des testeurs: "Ils ne paient pas de supplément pour cela" et "Nous avons déjà assez de travail." Pour moi personnellement, les deux arguments s'effondrent lorsque je me rends compte que je peux exécuter des auto-tests au moment où une fonctionnalité est développée et en peu de temps comprendre comment cela fonctionne correctement. Ça vaut beaucoup. Notre travail consiste à améliorer et à maintenir la qualité du produit, afin que chaque opportunité soit utilisée pour le faciliter. À partir du moment où j'ai commencé à écrire des autotests, la routine de mon travail est devenue de moins en moins consciente.
PS Cet article ne reflète que l'expérience de notre équipe et peut ne pas correspondre à vos convictions. Par conséquent, je serai heureux de connaître les approches qui vous guident dans votre travail. Je serai également satisfait de critiques saines et de la possibilité de discuter de l'article dans les commentaires.