Citation:
|
Envoyé par palantix
Salut Gilou,
Vaste sujet. Voici des éléments de réponse que je peux apporter.
|
Avec beaucoup de retard, je viens de me rendre compte de l'existence du topic.
Je souscris totalement au message de Palantix. La partie Test est, normalement, la partie la plus longue d'un projet. Malheureusement elle est bien souvent abandonné.
Pour être utile, il faudrait que l'on en sache plus sur le(s) produit(s) que tu testes. Applications Microsoft en interactif, batch de nuit, application interne ou au contraire à la disposition du grand public (application web) ... ?
Mais de façon générale, j'essaie d'avoir systématiquement dans mes tests, des essai appartenant aux catégories suivantes.
1) Cas standard : les données saisies sont des données usuelles. On attend un résultat bien donnée (l'exemple de Palantix : "
si x = a alors affiche b ") Bref les tests les plus évidents
2) Erreur standard : On saisie des données inexactes. Par exemple, "-3" au lieu de "3". ou "0" au lieu de "3"
3) "Crash test". Comment réagit l'application à des saisies ubuesques. Saisir des lettres quand la saisie est numérique, saisir "ENTREE", faire annuler au milieu du processus (puis vérifier l'état de la base). C'est souvent cette partie qui est la plus instructive.
Sinon, je liste mes règles de gestion dans le cahier des spécifications et je génère pour chacun d'entre elle une batterie de test comme décrit ci-dessus.
Pour des exemples de document, j'apprécie beaucoup le site suivant :
GPI, le site de la gestion de projets informatiques. Concernant les documents dont le cahier de suivi de recette, voir ici :
http://300gp.ovh.net/~sitecoll/gpi2/site.php?rubrique=232 n'attend pas de miracle. En effet il s'agit de cas standard et la partie recette n'est pas détaillé.
Pour la deuxième partie de ton message, je reviendrais plus tard avec un autre message.
A+