Mieux vaut échouer pour de vrai que de ne pas manquer vraiment. Hein?
Nous savons que vous avez fait l'expérience. Disons que vous venez d'ajouter certaines nouvelles fonctionnalités dans votre logiciel, et que vous exécutez une nouvelle génération. Et disons que 50% de vos cas de test échoue. Quelle est la première chose que vous assumez?
Nous avons posé cette même question que notre «pitch teaser" de l'hiver dernier à 100 développeurs et des professionnels AQ qui se promenait à notre kiosque lors d'une récente conférence, et 95 d'entre eux avaient la même réponse! Les essais doivent être brisées!
Cela crée une série en cascade de mauvaises hypothèses qui feront de votre gestionnaire de réciter l'adage sur "ass out of U and Me" sur le tableau blanc à la réunion du prochain projet. Voici pourquoi.
- Vous estimez que le problème n'est pas à votre demande, c'est avec les cas de tests eux-mêmes étant cassé ou n'est plus valide.
- Donc vous passez de temps à comparer les cas de tests avec tout changé dans votre nouvelle construction.
- Ensuite, vous creusez dans les scripts de test pour essayer de comprendre pourquoi le scénario de test n'est pas de passer plus longtemps, et les retravailler jusqu'à ce qu'ils passent.
- Ou vous abandonnent tout simplement et essayer de valider en cliquant dans votre cas vieux document de test Word. Fun de travail chargé.
Comment pouvez-vous appeler éventuellement à cet essai? Plutôt que d'utiliser les tests pour valider la demande, vous utilisez l'application pour tester le scénario de test - qui est un programme que vous avez codés!
Oui, les tests unitaires sont importantes pour trouver des bugs structurel dans votre code. Mais une fois un test unitaire essaie d'aller au-delà de ce niveau granulaire de contrôle, il devient un autre programme fragile dans votre environnement de développement.
Il est scandaleux de penser que s'appuyant sur des cas de test unitaire codé seul vous offre toute valeur dans des tests fonctionnels. En fait, tout le processus est si manuelle et très peu efficaces, que vous vous demandez si vous faites autre chose que de faire du travail chargée pour votre propre équipe.
Les tests unitaires a ses limites. Il ya des gens méthodes ont essayé d'aller au-delà de ces limites, mais c'est comme contestant la théorie de la gravité.
- Tenter de code pour réutiliser - mai semble possible mais ne peut que vous arriviez à la lisière des limites de tests unitaires.
- Essaient de tester l'interface avec votre groupe d'AQ, ne fonctionne pas vraiment si vous ne pouvez voir ces middle et back-couches fin.
Ce qui rend les échecs fausse si dangereux? Outre le fait qu'ils sont un vampire de moral qui va faire l'équipe renoncer à l'essai, les fausses défaillances impact de l'efficacité globale de l'essai. Si vous ne savez pas si un cas de défaut de test est encore valable, ce que vous faites apprendre beaucoup de tests? C'est un peu comme un détective qui recueille jamais eu de preuves.
Le temps de déclarer la guerre sur les défaillances du faux.
