Clause de non-responsabilité: je m'appelle Eric Burygin, je travaille depuis longtemps comme testeur, j'enseigne aux étudiants sur le cours "Test Engineer" , il peut donc sembler que le testeur veuille juste transférer un travail aux développeurs. En fait, l'approche décrite a à la fois des avantages et des inconvénients, de sorte que l'article est, entre autres, discutable. Je serais heureux de voir les opinions des développeurs et des testeurs dans les commentaires.
Si le développement écrit des tests, vous pouvez résoudre plusieurs problèmes à la fois, par exemple:
- Accélérez sensiblement le cycle de libération.
- Déchargez les tests.
Dans la plupart des commandes, le processus ressemble à ceci:
- Le développeur crée de nouvelles fonctionnalités et complète celles existantes.
- Le testeur teste tout cela et écrit divers cas de test.
- L'automate, justifiant le titre du poste, automatise tout selon les cas de test écrits de l'article 2.
Tout semble simple.
Mais il y a des faiblesses dans ce paradigme.
Disons qu'un développeur a terminé sa fonctionnalité et l'a passé en toute sécurité pour le test. Mais la fonctionnalité s'est avérée être assez rare, mais franchement brute. Cela conduira à une redécouverte du problème et à des correctifs supplémentaires, et il peut y avoir de une à N itérations, selon la taille de cette fonctionnalité, sa complexité, son impact sur les processus associés et la conscience du développeur lui-même. Et aussi sur la façon dont vos processus sont en principe organisés dans le développement, à quel point les demandes d'extraction sont soignées, si l'application est lancée avant d'être envoyée pour test.
En général, il y a suffisamment de variables.
Une fois la tâche testée et prête à être publiée, des tests doivent être écrits pour l'ensemble des fonctionnalités des cas de test. Puis régresser / fumer et enfin relâcher.
Après avoir reçu les cas de test écrits, l'automate couvre la fonctionnalité avec des tests. Il y a une probabilité assez élevée que la tâche se retrouve dans une file d'attente existante, donc les tests seront écrits avec un retard.
- Juste besoin de plus de développeurs
Hélas, pas une panacée. Plutôt l'inverse. Plus vous avez de développeurs dans ce schéma, plus la charge de test sera forte. En conséquence, soit le cycle de publication, soit l'équipe de test elle-même augmentera.
Et cela, selon le principe du domino, augmentera la charge sur les automates, qui devront traiter de plus en plus de cas de test tombant sur eux à partir des tests. Il y aura une situation miroir: soit le temps de couverture du test augmentera, soit l'équipe d'automatisation augmentera.
Il y a généralement deux testeurs et un ingénieur en automatisation pour huit développeurs. Dans le même temps, l'automatisation n'est pas directement impliquée dans le cycle de lancement - elle est plutôt proche. Et la question se pose: comment rendre les processus décrits plus efficaces, et même ne pas perdre en qualité?
Essayons de faire passer la phase d'automatisation de la troisième place à la première, à la phase de développement.
Ce qui se produit
Vous obtiendrez immédiatement un bon ensemble d'avantages, voir:
- les développeurs écrivent des tests simultanément à l'écriture de la fonctionnalité elle-même, ce qui améliore considérablement sa qualité;
- la charge de test diminue: les testeurs doivent maintenant examiner les résultats des tests et évaluer si la tâche est suffisamment couverte par les tests;
- la régression manuelle dans le schéma n'est plus nécessaire.
Et les testeurs?
Le testeur, même dans le paradigme mis à jour, reste un expert en tests - c'est lui qui examine à la fois la qualité et l'exhaustivité de la couverture de l'autotest d'une caractéristique particulière, ainsi que l'analyse des problèmes complexes et inhabituels. Mais maintenant, grâce à la charge réduite, le testeur libère une partie de son temps, il peut gérer les processus.
Dans le même temps, vous devez comprendre que les tests manuels n'iront toujours nulle part - vous aurez toujours quelque chose qui, pour une raison quelconque, est impossible à automatiser ou n'a aucun sens.
Donc, à un nouveau paradigme. Frais? Oui, au moins implémentez-le maintenant. Si vous pouvez faire deux choses.
- Vendez cette idée au développement. Parce que tous les développeurs ne voudront pas immédiatement écrire des tests, parce que cela peut être ennuyeux, ou il ne veut tout simplement pas: avez-vous, en fait, des testeurs là pour quoi?
- Vendez cette idée aux gestionnaires. Car, avec d'autres avantages, vous augmentez le temps de développement de chaque fonctionnalité.
Quels sont les inconvénients ici peuvent vous attendre.
- La plupart des développeurs ne savent tout simplement pas comment tester, car ce sont des développeurs et non des testeurs. Et ça va. Ici, vous pouvez soit leur apprendre à tester, ce qui ne sera pas la tâche la plus triviale, soit simplement écrire des cas de test pour eux. Ce qui rompt de facto le processus lui-même.
- Au début, l'automatisation prendra plus de temps, car il n'y aura pas de base de code de test, d'infrastructure et d'approches habituelles - la tâche est nouvelle.
- Des rapports clairs seront nécessaires pour les tests. Mais gardez à l'esprit que même le rapport le plus compréhensible ne peut pas toujours être lu correctement tout de suite.
- Vous ne pouvez pas facilement et rapidement couvrir tous les problèmes avec des tests. Dans certains cas, vous devrez passer plus de temps sur les tests que sur la mise en œuvre réelle de la fonctionnalité.
- Il sera difficile de livrer des tâches à grande échelle en même temps que des tests, cela prend beaucoup de temps.
- Pour ces mêmes tâches complexes et à grande échelle, vous devrez tout de même prévoir du temps pour simplement vous y plonger, car il n'y a pas d'autre moyen de vérifier l'exactitude des tests que les développeurs ont écrits.
Que faire?
Fondamentalement, chaque problème a une solution.
- Les développeurs ne savent pas comment tester. →
Vous pouvez les consulter dès le début pour vous aider à comprendre. - , . →
. . - . →
, , . - . →
: . - , . →
, — . . - . →
. .
Une approche avec tous ses avantages et ses inconvénients a droit à la vie. Et si vous configurez également correctement les processus, cela vous aidera à accélérer le cycle de publication et à ne pas gonfler l'état (: