Ai-je besoin d'un auto-test? Quand est-il nécessaire? Quelle valeur cela apporte-t-il?
L'article explique quand et pourquoi le test est nécessaire en tant que tel et dans quels cas son automatisation est nécessaire.
Au cours de la discussion sur cette question tenue dans le club pour eux. Francis Bacon («KifB Web-Meetings» en téléram), des collègues ont échangé leurs expériences et écrit leurs réflexions.
L'automatisation des tests est nécessaire si elle apporte de la valeur. Quand le test lui-même apporte-t-il de la valeur? Deux cas ont été identifiés.
Si le processus détecte des erreurs dans le logiciel avant de partir au combat
Si le test de la nouvelle version a révélé des erreurs qui ont ensuite été corrigées, ce test n'a pas été vain.
Mais que faire si la situation s'inverse? Si les tests n'ont pas trouvé d'erreur, mais qu'ils sont apparus au combat? Si des erreurs ont été détectées sur le banc d'essai (y compris le banc d'essai configuré le plus près de la bataille).
Il est allégué que, dans ce cas, les tests ont été mal effectués.
Comment mesurer la qualité des tests? Dans ce cas, la métrique convient = le nombre d'erreurs sur l'environnement de test / (le nombre d'erreurs sur l'environnement de test + combat). Dans ce cas, le nombre d'erreurs est pris pondéré par le niveau de criticité.
Mais que faire si les tests n'ont pas trouvé d'erreurs et n'ont pas été trouvés sur le serveur de combat?
Il est allégué que dans ce cas, les tests, en tant que tels, n'ont pas apporté de valeur et ces travaux ont été effectués en vain (à l'exception du cas suivant, dont nous parlerons plus loin). Du point de vue de Lean, c'est une perte.
Quand est-ce possible? Lorsque le module testé n'a pas changé. Qu'est-ce qui peut changer un module?
- Modification du code du module.
- Modification de la version des bibliothèques utilisées (y compris OS, base de données, etc.). Le changement peut être dû aux exigences des régulateurs, c'est pourquoi la bibliothèque doit être mise à jour dans un délai fixe.
- Modifier les paramètres ou les données qui affectent sérieusement le comportement d'une fonctionnalité universelle, dont les tests complets sont inutilement difficiles à réaliser et, par conséquent, les tests ont été abandonnés. Exemples:
- La définition de promotions dans des solutions telles que Siebel CRM ou Oracle ATG peut entraîner une dégradation des performances des fonctions de calcul de la promo, et la possibilité d'une vérification complète est impossible dans un délai raisonnable en raison de la flexibilité et de la polyvalence excessives de ces solutions.
- La description html de la fiche produit peut contenir une structure de document cassée ou des erreurs dans la description du code js écrites à l'intérieur, ce qui brise la page de la fiche produit
- L'utilisation de fonctionnalités n'est pas prévue à cet effet (clous marteaux avec un microscope). Par exemple, une modification du type de charge qui n'est pas inhérente aux exigences et, par conséquent, n'est pas prise en compte lors des tests. Par exemple, avant le Black Friday, il vaut la peine d'effectuer un test de charge distinct pour la page de destination, où ira le trafic s'il n'y avait pas de telles exigences de charge pour ce type de page.
- Modification du comportement de l'API des autres modules utilisés par le module en cours de développement. Surtout si la fonctionnalité de l'API n'est pas couverte par les tests de régression.
Étant donné que les options de changement peuvent être différentes et que la réalisation d'un test de régression complet coûte de l'argent, cela ne vaut pas tous les tests. Une option de contrôle consiste à baliser les tests avec des balises et avant les tests. Le gestionnaire de tests détermine quelle suite de tests doit être envoyée pour exécution pour une partie donnée des modifications.
Quand dois-je écrire des autotests dans ce cas?
Pour commencer, les tests automatisés n'annulent pas les tests de paramétrage, les tests de conception et l'écriture de cas de paramétrage de test! Et ne les remplace pas. Si ce n'est pas le cas, l'automatisation ne doit pas être traitée. Dans le même temps, les autotests doivent être compris non seulement comme le script lui-même, mais aussi comme la préparation de leur exécution et de l'utilisation des résultats.
Si vous écrivez des autotests après avoir créé le code, cela entraînera une augmentation de time2market (ce qui entraînera automatiquement une augmentation du capital connecté). Par conséquent, s'il est décidé de couvrir le code avec des autotests, vous devez alors écrire ces autotests parallèlement au code principal, dans le paradigme de développement de «TestFirst» ou «TDD».
La principale valeur créée par l'automatisation des tests est la réduction de time2market en raison du téléchargement plus rapide de la nouvelle version.
Des tests sont nécessaires pour garantir la performance des processus critiques.
Malgré le fait que la voiture n'a jamais pris feu, la présence d'un extincteur n'est pas inutile.
Une erreur sur un site à fort trafic qui ne permet pas d'ajouter un article au panier peut entraîner des pertes plus importantes que le coût de développement et de test de cette fonctionnalité sur l'année.
Par conséquent, il est nécessaire de mettre en évidence les processus critiques qui feront l'objet de contrôles réguliers (qui valent la peine d'être effectués en cas de changement). Comparez:
- perte de temps d'arrêt de la fonction depuis le moment de la détection jusqu'à sa correction,
- dépenses tests manuels réguliers ou son automatisation et sa mise en œuvre ultérieure pendant la période de récupération.
Mais que se passe-t-il si les tests réguliers ne détectent pas les erreurs pendant une longue période et qu'elles ne se produisent pas au combat? Ensuite, les tests n'apportent pas de valeur et ne sont donc pas nécessaires. Quand est-ce possible?
- Le module en cours de développement n'est pas très volumineux.
- Équipe stable et hautement compétente.
- Les intégrations sont fermées par des tests ou de l'autre côté il n'y a aucun changement.
Est-il possible de ne pas faire de tests du tout?
Cela est possible grâce au lancement de plusieurs installations de la solution et au test de nouvelles versions bêta sur les chats, si cela est techniquement possible et si de tels volontaires sont trouvés. Après la mise en place de la nouvelle version, la télémétrie est surveillée et un rollback est effectué en cas de dégradation des indicateurs. (Rappelons que la télémétrie au combat doit être indépendante de la disponibilité des tests).
Un autre cas de l'utilité de l'auto-test de régression est le test d'API (test de contrat d'API), si cette API est requise pour prendre en charge un processus critique. Ceci est particulièrement important si les développeurs d'un autre module changent quelque chose et ne font pas de test de qualité des changements de leur côté.
Lorsque l'automatisation des tests n'est pas nécessaire
Si vous avez une grande quantité de code hérité de très mauvaise qualité. Couvrir les autotests avec un tel chaos augmente le chaos.
Dans ce cas, il convient de souligner le module logique de cette solution. Après avoir sélectionné la couche d'interaction de ce module avec le reste du code, vous devez couvrir l'interaction avec les autotests. Cela fournira des garanties de l'intégrité du comportement et de l'intégrité du module après son recodage.
Les autotests ne remplacent pas les tests manuels. Les tests manuels sont le plus souvent effectués plus rapidement et à moindre coût que l'écriture et, par la suite, les autotests associés. En particulier, si le test est effectué après le développement du code, à partir de ce test, seule la partie qui entrera dans le test régulier des fonctionnalités critiques devrait être automatisée.
Et enfin - une liste de contrôle de la préparation de l'entreprise pour les autotests
Faisons une réservation tout de suite, cette liste de contrôle n'est pas pour tout le monde, elle est écrite pour les testeurs des entreprises pour lesquelles le développement de logiciels est la principale source de revenus.
Liste de contrôle
- L'entreprise dessine le principal processus de livraison et comprend où vous vous trouvez.
- L'entreprise a élaboré le processus de création de valeur pour les clients.
- La gestion des tâches a été mise en place, ce qui signifie que toutes les personnes impliquées prennent les tâches à l'état souhaité. Et les tâches sont caractérisées.
- L'entreprise a formulé des objectifs de test.
- Les titres des tâches dans le tracker sont «peignés», en d'autres termes, par le titre, vous pouvez comprendre de quel type de tâche il s'agit.
- Le registre des tâches est gérable, à tout moment il reflète l'état actuel et la politique du projet / produit.
- Il existe un registre des exigences et il est gérable.
- Il existe une traçabilité des exigences des tâches.
- Il existe une traçabilité des exigences de test. On sait quelles exigences sont couvertes par quels tests.
- Il existe une traçabilité des tests de tâches. On sait qu'il a déjà été testé où et comment.
- Il existe une matrice de l'influence des composants les uns sur les autres.
- Les tâches sont attribuées aux composants.
- Tout est sur le contrôle de version.
- Il existe une politique versionnée de qui, comment et pourquoi. On comprend pourquoi git flow est un mauvais modèle.
- Normes existantes: codage et autres
- Il y a un ci
- Il existe une politique de publication, où en particulier des méthodes de versioning sont prescrites, tout ce qui est nécessaire.
- Il existe un référentiel pour les artefacts à partir duquel vous pouvez retirer uniquement un produit prêt pour l'installation.
- Il existe une politique de marquage des artefacts selon différents critères. L'analyse de code statique n'est pas oubliée.
- Le milieu de balayage du produit monte d'un simple clic. L'environnement est également sous contrôle de version.
- L'environnement est entièrement automatisé et son exactitude est vérifiée. Ports, version Java, ...
- Le produit se déplie en un clic avec un chèque
- Le produit est configuré de manière entièrement automatique pour la tâche requise. Soit dit en passant, cela s'applique également aux configurations d'entreprise. Et cela est également enregistré automatiquement.
- Vous avez un moyen de générer de manière répétée et automatique toutes les données de test nécessaires. Les scripts de génération sont également sous contrôle de version et sont associés à des artefacts de produit.
- Tout ce qui précède fonctionne pour n'importe quelle version du produit.
- Vous avez un pipeline de livraison enregistré dans la politique de publication.
Enfin, merci aux membres du groupe pour la discussion et l'aide à la préparation de l'article.