Les tests de bout en bout et d'intégration en valent-ils la peine pour des éléments non critiques pour la mission?
Il est bien connu que les tests de bout en bout et d'intégration sont coûteux. Bien sûr, si nous développons des applications où des gens pourraient mourir en cas de problème, c'est un investissement intéressant. Cependant, dans les applications où les erreurs ne sont pas la fin du monde, ne serait-il pas moins cher d'ignorer complètement les tests E2E et les tests d'intégration et de créer un plan de sauvegarde en cas de problème? Comme un test manuel des user stories + tests unitaires + l'utilisation d'un langage typé est-elle suffisante?
Comme par exemple, si une boutique en ligne a perdu une commande, elle pourrait envoyer l'article gratuitement + un autre article comme excuse. L'utilisateur final pourrait se retrouver encore plus heureux de cette façon et, dans l'ensemble, l'entreprise économise de l'argent.
Je suppose que ma question est, en général, combien coûte un test d'intégration et un test E2E et combien d'argent cela permet-il d'économiser? Existe-t-il un moyen de faire un calcul risque/coût pour cela?
Peu importe que vous implémentiez E2E et des tests d'intégration ou non, vous avez besoin d'un plan de sauvegarde dans les deux cas. Ne vous attendez jamais à ce qu'un système soit exempt de bogues simplement parce qu'il a été testé.
Ainsi, dans votre estimation de coût, vous ne comparez pas le coût d'implémentation des tests E2E avec les coûts estimés par votre plan de sauvegarde en cas de panne, vous comparez:
- Coûts de réalisation manuelle des tests E2E (plusieurs fois, avant chaque nouvelle version)
vs.
- Coûts de construction (et de maintenance) des tests E2E automatisés
Si vous pouvez utiliser ces tests E2E plusieurs fois, il y aura généralement un certain nombre de tests où les coûts atteindront le seuil de rentabilité. Cela devrait être la mesure que vous appliquez pour planifier à l'avance les tests E2E que vous effectuerez manuellement et ceux que vous automatiserez.
Notez qu'il peut y avoir certains types de tests E2E qui peuvent être mis en œuvre facilement, où le retour sur investissement est immédiatement clair, mais il existe également des types de tests E2E où le développement et la maintenance peuvent être plus coûteux que de les faire manuellement sur une période de plusieurs années.
Peut-être contre-intuitivement, les tests automatisés peuvent réellement réduire le temps de développement par rapport à l'absence de tests. C'est donc un gagnant-gagnant.
L'idée est que les tests contribuent à plusieurs niveaux
Forcer la collecte et la spécification d'exigences strictes
Cela a un impact énorme sur la vitesse de développement. Pas de retour en arrière pour demander plus de détails, pas de malentendus, pas de fonctionnalités inutiles, etc.
Les développeurs savent quand une fonctionnalité est terminée
La plupart des tests sont effectués par des développeurs lors de l'écriture du code plutôt que par des testeurs vérifiant un produit fini. L'automatisation de ces tests réduit cette charge de travail
Bugs introduits par de nouvelles fonctionnalités détectés instantanément.
Celles-ci peuvent facilement vous coûter un sprint et nécessiter la réécriture d'une fonctionnalité entière si elles ne sont pas détectées.
Cycle de libération plus rapide
Cela signifie moins de code en vol, ce qui signifie moins de fusion, ce qui signifie moins de travail et moins de complexité pour les développeurs
Surtout si vous avez une configuration de framework de test, l'écriture de ces tests prend moins de temps que vous ne gagnez en efficacité.
De plus, vous économisez du temps de test manuel et vous obtenez un meilleur produit à la fin.
Ma réponse? Peut-être, probablement pas .
Les tests EOE sont bons lorsqu'ils sont très simples. Si vous prévoyez de couvrir des scénarios de base, vous pouvez réussir à obtenir un certain avantage avec les tests EOE. Mais si vous avez une application vraiment complexe et volumineuse (mission critique ou non), ces tests EOE seront coûteux à maintenir et vous devez connaître votre scénario pour évaluer s'il en vaut la peine.
Il y a quelques années le blog de test Google discute de ce sujet. Je ne peux qu'être d'accord avec l'auteur. Un bon test doit être rapide , fiable et isoler les échecs , fonctionnalités que les tests EOE ne sont pas capables de vous fournir.
J'ai travaillé sur une application qui a plus de 12 heures de tests de bout en bout couvrant de nombreux scénarios. Finalement, nous avons réussi à distribuer ces tests sur différentes machines, en contrôlant le début, l'exécution et la fin des tests, en collectant et en fusionnant les résultats. L'application testée était une application monolithique (ce qui est plus facile à installer et à exécuter pour tester) et était un cauchemar pour maintenir les tests.
La plupart du temps, nous maintenions les tests au lieu d'attraper des bogues à partir de leurs résultats. Découvrir l'origine d'un bug lors d'un test de bout en bout prend beaucoup de temps. Nous avons également traité de nombreux tests "faux négatifs" et peu de temps pour comprendre le problème et le corriger: Java Problèmes de chargement de l'applet, élément attendu introuvable sur la page (ainsi que d'autres problèmes concernant la vitesse d'automatisation), conserver le code de requête qui vient d'être utilisé lors du test de mémoire de la base de données (car la requête d'origine utilise un code spécifique à la base de données), etc.
Tout cela a besoin de personnel pour rester opérationnel. À la fin, nous commençons à supprimer certains tests EOE et à les remplacer par de nombreux tests unitaires/d'intégration.
Donc, mon conseil prudent est d'utiliser la pyramide de test de Google:
Comme bonne première supposition, Google suggère souvent une répartition 70/20/10: 70% de tests unitaires, 20% de tests d'intégration et 10% de tests de bout en bout. Le mélange exact sera différent pour chaque équipe, mais en général, il devrait conserver cette forme de pyramide.
Vous ne pouvez pas vraiment comparer le coût des tests d'intégration au coût d'un scénario dans le meilleur des cas où un bogue n'affecte qu'une seule commande. Un bug logique serait tout aussi susceptible d'affecter un grand nombre de commandes. Dire qu'un bug signifie qu'aucun paiement n'est capturé - cela pourrait avoir des effets désastreux pour toute entreprise.
Vous devriez vous demander quel est le bogue pire des cas qui, de façon réaliste, pourrait se retrouver en production en raison du manque de tests E2E. Et souvenez-vous de la loi Murphys.
Je suppose que cette question concerne les applications Web d'entreprise.
Ma recommandation pour les choses moyennement critiques:
- Effectuez des tests automatisés pour vos API backend, en vous assurant que le backend fonctionne comme prévu. Ces tests doivent être écrits par les développeurs lors de l'implémentation d'une API.
- Ne vous souciez pas des tests d'interface utilisateur automatisés, c'est-à-dire effectuez les tests frontaux manuellement.
Je pense que la plupart des tests devraient être au niveau de l'API ou au niveau des composants. Je ne me soucie pas des tests unitaires qui exécutent uniquement certaines fonctions internes.
D'après mon expérience, les tests E2E, quelle que soit la criticité de l'application, sont toujours prudents. Je pense toujours en termes de pire scénario, si les choses vont en forme de poire, êtes-vous à l'aise de vous tenir devant la direction et de justifier votre approche? Sinon, vous devez changer votre approche. De nombreuses organisations minimisent l'importance et les ressources allouées aux tests, mais soyez assurés que lorsque les choses tournent mal, tout le monde cherche quelqu'un à blâmer et si vous avez pris la décision de limiter les tests ou donné ces conseils, vous êtes le seul à licencier ligne.
Le développement de logiciels nécessite trop souvent un œil sur la politique organisationnelle.
"Il est bien connu que les tests de bout en bout et d'intégration sont coûteux."
Je pense que je ne suis pas d'accord avec cette affirmation.
Premièrement, les tests E2E sont ce qui compte pour les utilisateurs finaux et peuvent être les options les plus rentables et les plus économiques pour tester des systèmes complexes. Par exemple, lorsque quelqu'un achète une voiture, la plupart des gens ne la démontent pas et ne commencent pas à tester le carb, la boîte de vitesses et les roues isolément. Au lieu de cela, ils le prennent pour un essai routier.
Deuxièmement, en termes d'outillage, E2E n'a pas tendance à ralentir l'évolution interne du produit et dure plus longtemps. Si vous y réfléchissez, la surface fonctionnelle réelle de la plupart des produits change rarement autant, tandis qu'en interne, elle peut être soumise à toutes sortes de développements. Par conséquent, une fois que l'outillage de test est opérationnel, il dure généralement extrêmement bien. À titre d'exemple, si nous revenons à l'analogie avec la voiture. Le même cas de test "à prendre pour un lecteur" fonctionnerait à peu près sur Ford Model T comme sur Tesla. Tout comme les investissements dans les routes roulantes, les souffleries, les configurations de tests d'étanchéité, etc. Combien de tests de composants internes auraient eu un si bon retour sur investissement sur leur durée de vie?
Là où les tests E2E ont tendance à être plus chers/inappropriés, c'est dans la configuration initiale et s'ils sont utilisés pour tout tester. De façon pragmatique, je pense que la meilleure façon d'éviter ce piège est de prioriser l'automatisation des tests de choses qui:
- Sont faciles à automatiser et ne nécessitent probablement pas beaucoup de maintenance pour continuer à fonctionner.
- Consommez le plus de temps pour appliquer des processus de test manuels cohérents et adéquats.
- Risque de faire ressembler vous ou votre patron à des idiots si le produit est sorti avec il cassé.
Utilisez n'importe quelle forme de test, y compris E2E, qui vous semble appropriée. Concentrez-vous sur ceux-ci.