Mon projet concernant le Test Agile
Auteur : Brain Marick
Source : My Agile testing project
Date : 21/08/2003
Traducteur : Fabrice Aimetti
Date : 07/07/2019
Traduction :
Chez XP Agile Universe, deux personnes - peut-être plus - m'ont dit que je ne faisais pas assez pour aider au développement du test Agile en tant que discipline, comme un ensemble stable et largement compris de compétences. Je passe trop de temps à dire que je ne sais pas où en seront les tests Agiles dans cinq ans, pas assez à pointer dans une direction et à dire "Mais voyons si on ne peut pas le trouver là-bas". Ils ont probablement raison. C'est donc le début d'une série de notes dans lesquelles je vais faire exactement cela.
Je vais commencer par réitérer deux distinctions qui, à mon avis, sont de plus en plus courantes.
Si vous entendez quelqu'un parler de tests dans les projets Agiles, il est utile de demander si ces tests sont orientés métier ou technologie. Un test d'affaires est un test que vous pourriez décrire à un expert en affaires en des termes qui pourraient (ou devraient) l'intéresser. Si vous parliez au téléphone et que vous vouliez décrire les questions auxquelles le test répond, vous utiliseriez des mots tirés du domaine professionnel : "Si vous retirez plus d'argent que ce que vous avez sur votre compte, le système vous accorde-t-il automatiquement un prêt pour la différence ?"
Un test technologique est un test que vous décrivez avec des mots tirés du domaine des programmeurs : "Différents navigateurs implémentent Javascript différemment, donc nous testons si notre produit fonctionne avec les plus importants." Ou : "PersistentUser#delete ne devrait pas se plaindre si l'enregistrement utilisateur n'existe pas."
(Ces catégories ont des limites floues, comme tant d'autres. Par exemple, le choix des configurations de navigateur à tester est en partie une décision d'affaires.)
Il est également utile de demander aux personnes qui parlent de tests si elles veulent que les tests soutiennent la programmation ou critiquent le produit. Par "programmation de soutien", j'entends que les programmeurs les utilisent comme partie intégrante de l'acte de programmation. Par exemple, certains programmeurs écrivent un test pour leur dire quel code écrire ensuite. En écrivant ce code, ils changent une partie du comportement du programme. L'exécution du test après le changement les rassure sur le fait qu'ils ont changé ce qu'ils voulaient. L'exécution de tous les autres tests les rassure sur le fait qu'ils n'ont pas changé le comportement qu'ils avaient l'intention de laisser seul.
Les tests qui critiquent le produit ne sont pas centrés sur l'acte de programmation. Ils examinent plutôt un produit fini dans l'intention de découvrir les insuffisances.
Mettez ces deux distinctions ensemble et vous obtenez cette matrice :
Dans les prochaines billets, je parlerai de chaque quadrant de la matrice. Quelle est ma meilleure hypothèse sur la façon dont elle devrait évoluer ?