Nous passons plus de temps à implémenter un test fonctionnel qu'à implémenter le système lui-même, est-ce normal?

Fondamentalement, nous avons trois projets principaux, deux d'entre eux sont des services Web et l'autre est une application Web. Bien que je sois satisfait de couvrir autant que possible nos services Web avec des tests fonctionnels (les trois projets ont leurs propres tests unitaires), les tests fonctionnels de l'application Web prennent beaucoup de temps aux développeurs pour être mis en œuvre. Par beaucoup, je veux dire deux fois, ou parfois plus, le temps nécessaire pour implémenter la fonctionnalité testée avec le test unitaire inclus.

La politique du gestionnaire consiste à tester chaque fonctionnalité que nous ajoutons, même si elle n'est pas critique pour l'entreprise (c'est-à-dire un nouveau CRUD).

Je suis d'accord pour tester toutes les fonctionnalités des services Web, car il est difficile de les tester manuellement, et ces tests s'exécutent rapidement et ne prennent pas beaucoup de temps à mettre en œuvre.

Alors, quelle est la valeur de passer plus de temps à écrire un test fonctionnel qu'à écrire du code système, un test unitaire et à réparer les tikets QA? Est-ce normal? Ne devrions-nous pas écrire des tests fonctionnels uniquement pour des fonctionnalités critiques et laisser QA effectuer des tests de régression sur aucune fonctionnalité critique?

Remarque: nous ne développons pas de logiciel médical ou de logiciel de la NASA ou rien de critique.

Les tests fonctionnels sont très importants. Oui, ils prennent du temps à écrire mais si vous écrivez les bons tests fonctionnels, ils en valent largement la peine.

Il y a quelques bonnes raisons de faire des tests fonctionnels automatisés sur une application.

• Lorsqu'une nouvelle fonctionnalité est ajoutée à votre site Web, elle vous permet de savoir immédiatement si les modifications apportées à cette nouvelle fonctionnalité interrompent toute autre fonctionnalité de votre site.
• Il s'agit d'une connaissance documentée du fonctionnement et de la collaboration de l'application pour répondre aux besoins de l'entreprise.
• Lorsqu'il est temps de mettre à jour une bibliothèque tierce, vous pouvez la mettre à jour et exécuter votre suite de tests fonctionnels pour voir si quelque chose se casse. Au lieu d'avoir à parcourir chaque page vous-même, vous pouvez demander à un ordinateur de le faire pour vous et vous donner une liste de tous les tests qui ont échoué.
• Test de charge! Vous pouvez simuler des milliers d'utilisateurs simultanés frappant tous votre site en même temps et vous pouvez voir où votre site ralentit et se déforme sous la pression. Vous pouvez voir comment votre site Web se comporte bien avant de recevoir un appel de fin de soirée indiquant que le site est tombé en panne.
• Les tests fonctionnels prennent du temps à faire manuellement. Oui, il faut du temps pour écrire les cas, mais si vous deviez vous asseoir avec un classeur avec 500 pages de tests que vous deviez compléter avant de pouvoir expédier le produit, vous souhaiteriez avoir les tests automatisés!
• Les documents de test deviennent rapidement obsolètes. Lorsqu'une nouvelle fonctionnalité est ajoutée, vous devez vous assurer de mettre à jour le document de test principal. Si quelqu'un saute certains tests, vous obtenez tout à coup des bogues qui se glissent dans les pages qui sont "faites et testées". Je travaille actuellement dans un environnement comme ça, et je peux vous assurer que c'est un cauchemar.

En fin de compte, oui, il faut du temps pour écrire ces cas, mais vous devriez être fier de les écrire. C'est votre façon de prouver, sans l'ombre d'un doute, que votre code fonctionne et qu'il fonctionne avec toutes les autres fonctionnalités. Lorsque le contrôle qualité vient à vous et dit qu'il y a un bogue, vous le corrigez, puis l'ajoutez à votre suite de tests pour montrer qu'il est corrigé et assurez-vous qu'il ne se reproduise plus.

C'est votre filet de sécurité. Quand quelqu'un entre et détourne un proc stocké et fait un petit changement pour qu'il fonctionne avec son code, vous remarquerez qu'il a cassé 3 autres fonctionnalités dans le processus. Vous l'attraperez cette nuit-là et pas la veille de la date limite!

Quant à l'écriture de tests fonctionnels pour les fonctions critiques du système uniquement. Cela ne vous donnera pas l'image complète et cela permettra aux bogues de se faufiler. Il suffit d'ajouter une petite fonctionnalité qui n'est pas critique pour le système, mais qui interagit indirectement avec une fonction critique du système et vous avez le potentiel d'avoir un bug introduit.

Plus de 2 fois ... me semble un peu trop. Vous voudrez peut-être analyser les raisons de cela, elles pourraient inclure:

• mauvais support d'outil pour la création et la maintenance des tests

• les contrats des services Web ne sont pas suffisamment décrits dans la conception. Les développeurs doivent élaborer les contrats pendant les tests, ce qui est généralement un processus d'alignement long.

Parlez à vos développeurs.

En supposant que vous développez dans les sprints, ces tests fonctionnels ne sont qu'une partie du sprint. Cela ne se fait pas sans ces tests. Si vous ne l'avez pas, votre temps pour les tests d'intégration après la phase de développement pourrait doubler.

Est-il normal de passer plus de temps à implémenter un test fonctionnel qu'à implémenter le système lui-même?

Absolument. Écrire de très bons tests est susceptible de prendre la majorité du temps dans de nombreux (bons) magasins.
Un ratio 2-1 est donc très bien. Les développeurs moins expérimentés eux-mêmes ne prennent souvent pas tout le temps en compte les tests.

Il y a la loi des rendements décroissants. En supposant que vous écrivez d'abord des tests pour le code le plus risqué, la valeur générée par d'autres tests diminue avec le temps.

Les tests unitaires sont du code, ils contiendront donc des bogues (comme tous les autres codes). La correction de ces bogues prend du temps.

D'après mon expérience, les tests unitaires contiennent beaucoup plus de bogues que le système qu'ils testent, et les corriger est un fardeau continu.

C'est une question de qualité.

Si vous avez besoin d'accéder au marché, vous développerez votre application le plus rapidement possible. Vous ne pouvez même pas avoir de tests automatiques du tout =) mais vous donnerez votre application à votre audition avant vos concurrents.

Mais si vous savez que votre auditif ne disparaîtra pas, vous ferez tout ce que vous ne pouvez pas pour les décevoir. Chaque ticket de bug fera baisser votre réputation. Imaginez qu'un bug supprimera 50% de votre réputation, le suivant - 25% et ainsi de suite. Peut-il donc y avoir trop de tests?

Si par "est-ce normal" vous demandez si c'est courant, non, ce n'est certainement pas le cas. Beaucoup d'équipes de développement ont de mauvaises pratiques de test (j'en fais partie) et même des livres de qualité, j'ai lu des conseils pour passer à peu près autant de temps à coder la fonctionnalité que les tests. Si, normalement, vous demandez si elle est saine, cela dépend, mais deux fois plus de tests que nécessaire, c'est mieux qu'aucun test.

Cela n'a pas besoin d'être critique . Lorsque vous testez une fonctionnalité, vous testez quelque chose d' utile pour les utilisateurs finaux et il est de votre responsabilité de savoir (et non de deviner) qu'elle fonctionne tout le temps correctement. Si vous avez besoin de deux fois plus pour cet objectif, alors cela devrait être fait de cette façon - si possible.

Il est également possible que votre politique soit visiblement trop stricte en ce qui concerne les tests automatisés, mais il est difficile de dire sans savoir la qualité qu'ils visent, leurs ressources et à quoi d'autre ils pourraient l'affecter.