La taverne du testeur

La conception des tests

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.

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Agilité

SAFe, le framework d’un testeur refoulé ?

Intro SAFe, est le Framework d’agile à l’échelle le plus populaire… et qui continue à gagner en popularité d’après l’enquête State of Agile. Au delà de cet aspect populaire, SAFe est également le framework d’Agile à l’échelle le plus riche et complet. Il propose 4 valeurs et 10 principes qui

Lire la suite »
Automatisation

Outil de test: automatisation IHM avec Cypress

Cet article est le premier d’une nouvelle série dans la taverne qui tend à présenter succinctement différents outils de test. Cypress en bref Cypress est un outil d’automatisation de test IHM (Interface graphique) open source concurrent à Selenium qui dispose d’une communauté active et réactive. Cypress propose d’automatiser ses tests

Lire la suite »
Agilité

Écrire des bons BDD

Je travaille sur différents projets dans lesquels les personnes utilisent des outils BDD (Business Driven Developement) comme cucumber ou JBehave. C’est une très bonne idée cela permet, par exemple, d’avoir des spécifications par l’exemple. Néanmoins, ce n’est pas simple d’écrire du BDD ! Dans cet article je vais tenter d’expliquer ce

Lire la suite »