Discussion :

[keiserjo]

Bonjour,
Je voudrais lancer le débat sur les tests logiciels:
- automatisation
- outils (open source de préférence)
- gestion
- analyse

Pour avoir un retour d'experience sur ce domaine.
Tous les avis sont les bienvenus
Merci

[Franckintosh]

Mais des avis sur quoi ?

[keiserjo]

surtout sur les outils
mais également sur les méthodes d'automatisation

[Alec6]

Voici un débat interressant; il faudrait peut etre le déplacer dans la section débats.

Vous connaissez les statistiques sur les tests:
- Revue de code --> 50 % de bugs corrigés
- Test utilisateur en plus on arrive à --> 75%
- Test unitaire --> 80% seulement

L'automatisation de test c'est bien mais ça pose le problème qu'il faut un testeur pour réfléchire à tous les tests possibles, et rectifier le jeu de test avec les changements de spécifications.

Il en ressot un nouveau problème: comment sait-on que notre jeu de test est exhaustif, c'est à dire que tout les chemins utilisateurs possible sont parcourus; lorsque vous fermez une boite de dialogue, pensez vous à cliquer aussi bien sur le bouton cancel que sur la petite croix de la fenetre (ce qui oblige à refaire deux fois le jeu de test).

Est ce que je le jeux de test utilisateur ne peut pas etre analysé et extrait du code par un autre programme ?

Comment communiqué avec les fonctionnels (ces personnes qui connaissent le domaine métier et test le logiciel, mais ne connaissent pas l'informatique), qui n'ont pas une vision informaticien pour tester les vices de la programmation (plantage système, memory etc...).

Je pense qu'il est possible à partir du code de générer un graphe des chemins utilisateur; une sorte de diagramme d'activité, mais qui ne représente pas une vision pour le développeur, mais une vision pour l'utilisateur (testeur).

Qu'en pensez vous.

[tipiak]

L'automatisation de test c'est bien mais ça pose le problème qu'il faut un testeur pour réfléchire à tous les tests possibles, et rectifier le jeu de test avec les changements de spécifications.
.

pour moi l'automatisation c'est un must, qui vient une fois qu'on maitrise correctement l'activité des tests

cette maitrise passe par :
- la capitalisation des tests : pouvoir les rejouer (donc mise en place d'une gestion de config des environnement de tests, des jeux d'essai et des plans de tests) (ce qui est déja assez conséquent à mettre ne place)

identifier hiérarchiser les tests (avec des priorités selon la criticité, fréquence d'utilisation du module testé, gravité de l'impact en cas de bug etc etc) pour ainsi identifier les "Chemins" (tests) a faire en premier (pertinence du test)
car j'ai connu des cas ou les gens faisaient pleins de tests (mais non pertinants, du coup l'utilisateur plantaient tout sur des cas "De Base")

Il en ressot un nouveau problème: comment sait-on que notre jeu de test est exhaustif, c'est à dire que tout les chemins utilisateurs possible sont parcourus; lorsque vous fermez une boite de dialogue, pensez vous à cliquer aussi bien sur le bouton cancel que sur la petite croix de la fenetre (ce qui oblige à refaire deux fois le jeu de test).

.

tout à fait d'accord, d'ou mon petit paragraphe sur la pertinence des tests
et leur criticité pour les prioriser

ainsi que d'avoir des métriques pour évaluer l'avancement des tests (couvertures des exigences fonctionnelles par des tests, couvertures des tests par des tests joués, tx d'anomalies etc etc ...)


Jusqu'à maintenant tout ce que j'ai dit passe par la gestion des tests (donc à la rigueur nul besoins d'outils : deux trois modes opératoires et modèles de documents Word et Excel passeraient bien)
mais bon certains outils aident pas mal pour cela (Exemple Rationnal Test Manager ou Mercury QC8)

Est ce que je le jeux de test utilisateur ne peut pas etre analysé et extrait du code par un autre programme ?
.

Par contre je ne suis pas d'accord, ton test il sert à vérifier que ton application (et donc ton code) réponde correctement à ta conception Détaillée pour les TU, conception globale pour les tests d'intégration, spécification pour les tests de qualif et Cahier des charges pour les tests de recette interne ou externe

donc extraire le jeu de test du code revient à prendre le Problème à l'envers.

Pondre un jeu de tests à partir de la spec pour avoir le plan de tests de recette serait bcp plus utile
mais je ne connais pas d'outils qui permettent cela
Sauf dans le Cas de Spécification FORMELLE (ce qui n'est pas souvent le cas à part en aeronautique ou dans certains trucs embarqués...)

idem pour les autres cas (intégration ou TU) mais bon quand un doc de spec ou de conception est en Word, difficile de transcrire cela à travers une moulinette pour avoir un joli plan de test...

Enfin par exemple en UML : logigement un Use Case correspond à un scénario (au niveau des tests utilisateur (tests métier)) donc a partir de la modélisation on pourait en extraire les tests

Comment communiqué avec les fonctionnels (ces personnes qui connaissent le domaine métier et test le logiciel, mais ne connaissent pas l'informatique), qui n'ont pas une vision informaticien pour tester les vices de la programmation (plantage système, memory etc...).

.

selon moi, c'est les différents niveau de tests qui assurent cela
TU : pour les informaticiens pures (tests très techniques)

Recette : très orientés métiers
(et si par exemple un bug liés au technique (Tests Unitaires) est identifiés en recette ou intégration, Bah c'est à faire remonter jusqu'au développeur et on relance dès les tests unitaires...)


Après pour les tests fonctionnels (orientés utilisateurs) effectivement ils doivent être réalisés par des personnes qui maitrisent le domaine métier
(dans la gestion des tests, pourquoi ne pas associé un test avec le domaine de compétence fonctionnel que doit avoir le testeur ??)

et le plus souvent ces tests (fonctionnelles) sont rédigés à partir des specs (donc pourkoi ne pas les faire valider par le client en meme temps que la specs ??? (client qui justement est un parfait expert fonctionnel ???))

Après justement c'est la ou pour l'automatisation (Cf un autre topik, il faut clairement faire la différence entre automatisation ORIENTE informaticien tel JUNIT et automatisation ORIENTE Fonctionnelle)

pour moi l'une intervient tot (TU, Intégration, Tests techniques) et l'autre plus tard (intégration et recette)

Je pense qu'il est possible à partir du code de générer un graphe des chemins utilisateur; une sorte de diagramme d'activité, mais qui ne représente pas une vision pour le développeur, mais une vision pour l'utilisateur (testeur).

Je suis d'accord ca rejoint l'idée d'identifier la pertinance et la criticité d'un test.
après tout les moyens sont bon pour nourir cette base de connaissance
- Soit en intérogeant l'utilisateur

- Soit comme tu le propose avec une étude statistique de l'utilisation faite par l'utilisateur

l'idée principale étant de couvrir au plus vite les chemins les plus critiques (dans le sens utilisateurs)



et quoi qu'il en soit sur les outils il faut les aborder avec bcp de recul

un outil ne doit pas imposer une méthode (un outil n'est pas non plus la providence qui va faire tout tout seul...)
il faut se dire qu'un outil DOIT être au service d'une méthode

donc selon moi avant de se lancer dans de l'automatisation il faut
Avoir une méthode claire et efficace
Puis avoir un outil pour s'assurer du respect de cette méthode
Avoir une approche qualitative avec des métriques pour EVALUER ce processus
Et seulement après avoir maitrisé tout ca songer à l'automatisation
(Enfin c'est l'approche CMM)

voila c'était mon point de vu sur la chose mais bon c'est un domaine très très vaste sur lequel on peut s'étendre des heures et des heures et sur lesquels il y a plein de méthodes ou d'aproches différentes