Discussion :

[Maitre B]

Salut à tous,

Je dois pour mon entreprise, créer une méthode de test.
Cela consiste à décrire toutes une liste de procédure à faire pour développer une application type client serveur (pas de web).
Sachant que ce sont surtout des extensions de l'appli de départ que nous développons.

Je souhaiterais avoir votre avis sur 2 points
1.Avez vous des exemples de méthodologie de test?

2. Que pensez vous de faire tester une application par le dev et un autre dev?

Donc perso, j'étais parti sur :

1.
- Proposez différents scénarios pour tester l'applications ( 1classique, 1 complexe).
- Faire une fiche décrivant les effets de bords.
Exemple : l'utilisateur qui saisit des noms super longs dans sa combo box.
- Vérifier si on réponds bien à l'objectif préciser dans les spec.

2. Je ne pense pas qu'il soit bien qu''un autre développeur teste l'appli de peur de création de tension dans le service développement. Les informaticiens sont des gens tres suceptibles. Comment faire alors ?
demander à un utilisateur de tester l'appli en version Beta? pourquoi pas?

J'attends vos conseils et remarques avec impatience sur ces 2 points

Merci d'avance
Chris

[ego]

regardes ce qui est dit dans le Rational Unified Process

[alex00]

Salut

Il me semble que tu mélanges plusieurs niveaux :
- commence par identifier les critères d'acceptation de l'application (fonctionnels - cas nominal et cas exotiques, couverture des fonctions- et non fonctionnels - charge, perf, couverture du code)
- identifie aussi ce qui est de la responsabilité des développeurs (tests unitaires et d'intégration : même critères + non régression automatisée).
Acceptation : équipe de test, TU et intégration : développeurs.

Enfin, tu as tout intérêt à définir des "règles de tests", par exemple "chaque champ de saisie textuel doit avoir un nombre de caractère limite", que les testeurs pourront valider systématiquement (évite de longue descriptions de tests sans contenu pertinent).

Dans XP, les test sont écrits (au moins textuellement) avant le code, ce qui évite que le développeur se sente blessé lorsqu'un test échoue (il était prévenu sur le niveau d'acceptation de son code).

Alexandre

[Invité]

Bonjour,

Une chose fondamentale au niveau des tests :
C'est un métier à part entière qui nécéssite :
-Des analystes / Testeurs;
-Des plans de tests, cas de tests, etc..
-Un environnement séparé des études (le plus proche de la prod)...

De plus il y a effectivement plusieurs niveaux de tests - ceux de la responsabilité des études (de type unitaire).
L'intégration (oui je diverge de Alex00 ) et les recettes fonctionnelles ( n personnes avec de préférence des utilisateurs en plus), les tests de performances -robustesses, etc...
Une forme supplémentaire de validation peu usitée est celle des revues documentaires : valider les documents écrits par les études (spéc, déploiement, plan de test unitaire, doc utilisateurs, doc prod, etc...)
Et puis il y a la charte graphique....

Evidemment de mettre en place une cellule de test demande du temps et de l'argent, mais sur le moyen et long terme, le gain est réel.

Une autre chose importante, c'est que les tests doivent être pensés très tôt. Ce n'est pas à la livraison d'une appli que l'on test si cela est bon...
Et il n'y a pas que Xp qui préconise les tests très tôt.
je ne vais pas me faire des amis mais :
SI TOUS LES DEVELOPPEURS FAISAIENT DES PLANS DE TESTS UNITAIRES(même légers) ET LES TESTER, LES ERREURS DE CODAGE SERAIENT MOINS NOMBREUSES....
Et que personne ne viennent me dire le contraire, c'est mon premier métier (6 ans en MVS et NTIC).
L'exemple bête est que dans un champ numérique tu puisses taper d'autres caratères non numériques.... Et le delta entre le Cahier des charges et les spécifications détaillées ...

Donc, pour simplifier :
Faires des plans de test unitaire pour les études (comme le dis Alex00)
Faire des plans de test détaillés Fonctionnel pour toute l'application/module, + charte graphique si existante
Pensez au tests techniques...
ET FAITES ENTRER LES UTILISATEURS FINAUX (clients) DANS LA BOUCLE à chaque jalon de votre process de Dév...
je dois encore avoir des docs qui peuvent éventuellement t'aider, alors n'hésites pas.

[Nip]

Juste un petit complément aux réponses très complètes de alex00 et jacktheripper et en réponse à ta question 2.
L'idéal est que ce soit une autre équipe ou un autre dev qui ecrive les tests à passer pour une partie donnée; c'est important dans la mesure où la manière de coder diffère entre 2 développeurs mais que au final le résultat doit être le même : l'appli doit faire ce qu'on attend d'elle.
En cas de manque d'effectif, puisque comme le signale jacktheripper c'est une métier à part entière, tu peux demander aux developpeurs d'ecrire les tests unitaires pour la partie qu'ils ne développent pas.
Et à propos de la susceptibilité du développeur je reprendrais ce qu'a dit alex00 : les tests sont ecrits à l'avance(en XP); le contrat pour le développeur est de passer ces tests. Si les tests sont bien ecrits et passés avec succès alors l'appli (ou le developpeur ) réalise ce qu'on attend d'elle (ou de lui).
Au final, grâce à ces tests on a
-une détection rapide des bugs,
-une mesure de l'avancement du projet (en fonction du nombre de tests passés et réussis),
-et une documentation du code.
Tout benef en fait (même si a imposer cette méthode de travail à des gens qui ne codent pas comme ça c'est pas gagné...)

[alex00]

Bonjour

Je ne voie pas d'incohérence entre Jack et moi, mais beaucoup de facteurs qui entrent en jeu :

- le produit développé : est-il facilement testable ? automatiquement ? avec ou sans l'interface ?
- le processus de dev : est-ce du cycle en V ? de l'itératif et incrémental ?
- le processus de mise en place : diffusion web, avec mise en place pilote, longue intégration ?
- les personnes : sont-elles motivées pour tester, ont-elles des lignes directrices ?

Sur les 3 premiers points, Chris, on pourra t'aiguiller si tu nous donne plus de matière. La méthode que tu cherches doit-être adaptée à ton organisation, à un delta près (l'évolution de l'organisation : relation avec les utilisateurs, nouvelles personnes, nouvelles procédures de développement).

Alexandre

[Maitre B]

Tout d'abord merci à tous pour vos réponses pertinentes

- le produit développé : est-il facilement testable ? automatiquement ? avec ou sans l'interface ?

Oui, nous avons un environnement de test : client et serveur de test.
Oui il y a une interface. En fait, les développeurs réalisent des extensions de l'application de gestion centrale. ( VB 6/Sql Serveur)

- le processus de dev : est-ce du cycle en V ? de l'itératif et incrémental ?

C'est de l'itératif, mais pas de méthode utilisée (spécif centralisée non réalisé par nos soins et souvent incomplète, ensuite on fait le dev et on teste mais absence de docs de tests)

- le processus de mise en place : diffusion web, avec mise en place pilote, longue intégration ?

Pas de diffusion web, c une appli client/serveur (on livre en Béta aux dirigeants qui utilisent le produit, puis on passe en prod.)

- les personnes : sont-elles motivées pour tester, ont-elles des lignes directrices ?

Bah, pas trop en fait, les développeurs n'ont jamais raffolé des tests.
Pas de lignes directrices particulières si ce n'est qu'il n'y ait pas de bugs et le respect des date de livraison

J'espère que ces précisions vous aideront à m'aiguiller.
Chris

[Eowyn]

Salut Maitre B,

La mise en place d'une procédure de tests est longue et difficile, voire épuisante... mais on peut y arriver step by step.
Alex00, jacktheripper et NIP t'ont donné de très bonnes réponses.
Alors j'amène juste quelques points d'expérience avec une petite équipe.

les tests font partie de la Qualité, ça veut dire qu'avant de commencer à coder on doit être d'accord sur ce qui doit être livré. Les développeurs et le testeur (souvent resp. de projet ou analyste) sont OK sur le contenu de la livraison.
les specs doivent être suffisament claires et non-équivoque pour éviter que le développeur fasse un code comme il a pensé "que ce serait bien" (soit parce que c'est plus facile, rapide à faire, soit parce qu'il n'a aucune idée du boulot du user...)
Si on doit modifier les specs au cours du développement pour x raison, le user doit être averti et les documents mis à jour
il faut essayer un maximum de responsabiliser les développeurs quant à la qualité de ce qu'ils livrent. Par exemple, le contrôle fonctionne mais on n'a pas contrôlé le format de date avant de livrer; ou on a bêtement inversé des colonnes sur un écran. ... C'est jamais très grave, ça fait juste perdre 2 ou3 heures à l'équipe...
dans mon équipe on partage les tests en 2 phases. Comme j'ai fait les specs, je teste en 1er niveau (vérification que la mod ou la correction fonctionne et fonctionnalité principale). La 2e phase passe à l'exploit. qui s'occupe aussi de la hot-line, eux font les tests de non-régression, les nouveautés et les principales fonctionnalités.

Pour avoir une vue d'ensemble du comment, quoi des tests essaie de regarder vers Unified Process - Tests Guideline.
(document de base, processus de tests, etc...).

bons tests !