Le cycle de vie d’un test commence toujours par la conception (design) :
Cette phase est différente de l’écriture et son but est tout autre.
Le but de l’écriture c’est de mettre sur papier ce que l’on va tester et de s’assurer que cette exécution sera toujours la même. Mais d’écrire ce que l’on va tester il faut savoir exactement ce que l’on veut tester.
Le but de la conception des tests c’est justement de choisir ce que l’on va tester. Choisir ce que l’on va tester, choisir comment on va le tester, choisir quels seront les tests à automatiser, les tests de régressions et les tests vitaux (car oui, de mon point de vue ces choix doivent être fait à ce moment-là).
De quoi a-t-on besoin pour faire ces choix ?
En dehors des tests exploratoires, où la conception a lieu en même temps que l’exécution, les choix sont faits à l’avance et ne reposent pas uniquement sur l’expérience du testeur.
Pour avoir une bonne conception des tests il faut :
· Comprendre le produit
· Comprendre les besoins des futurs utilisateurs
· Comprendre la future utilisation du produit
Cela revient donc à dire qu’il faut avoir des spécifications (User Stories en Scrum) bien écrites et pouvoir facilement communiquer avec les équipes métier (le PO en Scrum). La phase de conception des tests est une phase très axée sur l’aspect métier du produit. Je la considère comme la passerelle entre le métier de l’ingénierie des exigences (avec la certification REQB) et celle du test (avec les certifications ISTQB).
L’exhaustivité des tests étant impossible (ou beaucoup trop coûteuse), il faut savoir concentrer ses efforts sur les utilisations prévues du produit.
Les spécifications et le métier ont justement pour but de nous faire comprendre tout cela, leur utilisation dans la conception des tests est donc primordiale.
Pour choisir ce que l’on va tester, comment on va le tester et quels seront les tests qui seront exécutés après la validation du produit ou de la fonctionnalité on part des spécifications. Plus exactement, on part des fonctionnalités et scénarii décrits dans ces dernières. En lisant les lignes précédentes, vous avez surement fait le lien avec les plans de test. En effet ces plans sont bien utiles pour cette phase de conception des tests.
Attention: les spécifications sont un livrable comme un autre, ils peuvent contenir des défauts ou des oublis (la majorité des bugs ne proviennent pas du code mais des spécifications). Il ne faut alors pas hésiter à contacter le métier (ou PO) afin d’avoir des précisions sur ces dernières. Cela est d’ailleurs préconisé en Scrum lors de la cérémonie du poker planning.
Comment faire ces choix ?
Lorsque tout est clair on peut définir quels seront les tests qui devront être effectués pour valider le produit (ou la User Story, ou la fonctionnalité).
Le plan de test peut alors être complété ainsi qu’une matrice de couverture pour s’assurer que l’ensemble des fonctionnalités sont bien testées et par quels cas de test elles le sont. Avec le plan de test les cas de tests sont également définis ainsi que les conditions de test.
L’écriture des cas de test peut alors commencer. On arrive alors à une nouvelle étape du cycle de vie des tests.
Et après ?
Pour finir, je tiens à préciser que tout ce travail fait en amont de l’écriture des tests est un travail essentiel dont on récolte les fruits à court terme (avec une détection de bugs plus en amont) mais aussi à long terme (avec une maintenabilité des tests plus aisée). Il fait donc toujours conserver les plans de test et la matrice de traçabilité qui s’étoffera et s’affinera au cours de la vie du projet et permettra d’avoir des campagnes de test toujours plus efficaces.
Matrice de couverture (traçabilité) : https://aurga.wordpress.com/2013/03/08/la-matrice-de-tracabilite/
N’hésitez pas à rejoindre le groupe Le métier du test
N’hésitez pas à me suivre et lire mes autres articles si vous voulez en apprendre plus sur le test ou venir partager vos connaissances
Merci à tous ceux qui mettent « j’aime », partagent ou commentent mes articles.
