Etape 4 : Documenter les résultats des tests

possible, sous peine de ne
jamais l’utiliser. On peut créer une
table de test dans la base de données
ou, mieux encore, créer une base de
données consacrée au travail de test.
On commencera par attribuer un numéro
unique et immuable à  chaque
test exécuté. Dans le journal de test, il
faut aussi inclure toutes les informations
pertinentes : les conditions du
test, les valeurs du test, les résultats attendus,
la personne qui a conçu le test,
le nom de la procédure testée et l’emplacement
du fichier qui contient le
script du test.
Comme la plupart des tests seront
effectués plusieurs fois, il est bon d’utiliser
une table TestDetail séparée comme un enregistrement permanent
de chaque cycle de test. Outre une clé
étrangère test_id, la table détail devrait
inclure l’état du test (planifié mais pas
encore exécuté ou exécuté mais pas
encore terminé, par exemple), la date
et l’heure d’exécution du test, la personne
qui s’en est chargée, le produit
et le résultat du test et toute éventuelle
action de suivi à  mener. Les actions de
suivi sont multiples : réexécuter le test,
déboguer la procédure, ou analyser les
conditions de test si l’on soupçonne
que celui-ci s’est mal déroulé.

Si le test échoue, ce fait doit figurer
dans le journal de test. Il faut en plus
un second document pour suivre la
manière dont on réagit aux défaillances
du test. Ce document est généralement
appelé SPR (software problem
report) ou « suiveur de bogues ».
Quand on atteint le test au niveau système,
les SPR sont généralement exploités
par des testeurs professionnels
(s’il y en a dans l’entreprise) et entrent
officiellement dans le système de gestion
du changement du projet. Au niveau du test par unités, le but principal
d’un SPR est de vous aider, en tant
que développeur de la procédure, à 
mieux organiser le travail de test et de
débogage.

Là  encore, il est bon de créer une
table de suivi séparée pour stocker les
données qui vont dans le SPR. Les
données doivent inclure le type
d’erreur (coding, conception, matériel,
par exemple), sa gravité (fatale,
grave, bénigne, par exemple) et la nature
de l’erreur ainsi que la façon de la
reproduire. Il faut aussi dater et résumer
le problème dans une colonne séparée
: votre manager sera surtout intéressé
par ce résumé. En outre, le SPR
doit comporter des champs permettant
de superviser l’activité de suivi qui se déroule, l’état du problème (ouvert
ou fermé), qui a résolu le problème,
qui a retesté la procédure stockée et la
date de chacun de ces événements ou
actions.