Discussion :

[kisitomomotene]

Salut à tous.

J'ai terminer le developpment d'une application pour un client. Alors comment est ce que doit livrer? qu'est ce qui doit obligatoirement apparaître dans ce que je doit livrer?
Merci

[souviron34]

1) le logiciel
2) une documentation de configuration
3) une documentation utilisateur complète
4) une documentation de dépannage

au minimum....

[kisitomomotene]

1) le logiciel
2) une documentation de configuration
3) une documentation utilisateur complète
4) une documentation de dépannage

au minimum....

Merci. J'aimerais savoir si les "user acceptance test" doivent faire partir des documents à fournir par le developpeur.

[souviron34]

bah ça dépend... Moi je dirais non..

Sauf si tu as fais ces tests avec des utilisateurs qui ne sont pas ceux de ton client, et pas sous son contrôle...

[kisitomomotene]

bah ça dépend... Moi je dirais non..

Sauf si tu as fais ces tests avec des utilisateurs qui ne sont pas ceux de ton client, et pas sous son contrôle...

En fait je parlais du document qui décrit des scénarios (avec capture ecran) pour effectuer des tests, et non d'un document qui présenterais le resultats des tests effectués. Donc je me demande si je dois fournir un tel document

[souviron34]

bah tu peux toujours...

mais le propre d'un vrai test "utilisateur" est qu'il n'y a pas de guide....

C'est lui qui dit "ouais c'est super comme ça..." ou "berkkk pourquoi t'as mis ce truc-là là..."...

Donc à mon avis, inclure une série d'écran comme "guide de test" n'est pas bon.

Que cette série soit dans la partie documentation utilisateur, par exemple en appendice "exemple d'utilisation : cas 1 cas 2, etc.."

Mais tu ne peux pas DU TOUT te servir de ça pour effectuer des tests (c'est TOI qui fais le soft, et c'est EUX qui l'utilisent...). C'est donc à EUX de créer des scénarios de tests et voir si ils peuvent les exécuter comme ils le pensent..

[kisitomomotene]

Ok merci

A++

[spampete]

pour les scénarios de test, je ne suis pas d'accord avec l'idée que c'est au client d'ecrire les scénarios. Au contraire, je dirais plutôt que du cahier des charges, ou dossier de spécifications, découle en principe un plan de test, et c'est bien à la société qui développe son produit d'effectuer son plan de test.

et les résultat du plan de test peuvent éventuellement être livré au client.

plus généralement, on fait un plan de recette, plus ou moins équivalent au plan de test, mais peut être en plus simple, plus haut niveau dans les fonctions testées. Et pour le coup, les tests de recette se font en général par la société qui développe, mais EN PRESENCE du client.

Eventuellement, le plan de recette peut être soumis au client pour approbation, qui peut même participer à la création/finalisation dudit document

[souviron34]

pour les scénarios de test, je ne suis pas d'accord avec l'idée que c'est au client d'ecrire les scénarios. Au contraire, je dirais plutôt que du cahier des charges, ou dossier de spécifications, découle en principe un plan de test, et c'est bien à la société qui développe son produit d'effectuer son plan de test.

et les résultat du plan de test peuvent éventuellement être livré au client.

plus généralement, on fait un plan de recette, plus ou moins équivalent au plan de test, mais peut être en plus simple, plus haut niveau dans les fonctions testées. Et pour le coup, les tests de recette se font en général par la société qui développe, mais EN PRESENCE du client.

Eventuellement, le plan de recette peut être soumis au client pour approbation, qui peut même participer à la création/finalisation dudit document

je sais bien, ton opinion est extrêmement répandue dans les départements/équipes d'informatique....

Mais l'ergonomie (autant ses grandes réussites que ses grands échecs) des logiciels a démontré le contraire...

Et tout gros projet (et dans toute boîte consciente de ce problème) (je peux citer entre autre EDF, IBM, Bell Labs, AT&T, Philips dans une certaine mesure), a (ont) une équipe d'ergonomie EN TETE du projet, et dont la manière de tester suit ce que j'ai dit au dessus....

Et c'est d'ailleurs le cas pour tous les logiciels "sensibles" (médicaux, contrôleurs aériens, pilotes d'avions, ..) :

Pour les utilisateurs de ce genre de logiciel, l'utilisation doit être INSTINCTIVE...

Toute dérogation à cette règle peut entraîner des erreurs, dans le pire cas des morts...

C'est donc EUX qui détermineront les tests (dits "d'utilisabilité") en fonction de leur métier..

Il y aura bien sûr des tests informatiques (sur la conformité et le bon comportement des fonctions et composantes).

Mais l'essentiel (ce qui était le sujet du PO) pour les tests utilisateurs devrait se faire PAR les utilisateurs.

[spampete]

"l'essentiel pour les tests utilisateurs"... ça n'était pas exactement le sujet du post initial, mais bon

pour ce qui est des tests d'ergonomie, mais oui bien sûr que c'est surtout au client de les valider, on est d'accord là dessus. En fait, l'ergonomie en question fait aussi et surtout partie de la spec sur l'interface graphique, au moins, pour laquelle il est bien évident que le client participe plus qu'activement.. ou du moins il le devrait !

Je ne parlais que de ce qui devait être fait par les concepteurs pour la livraison, ce qui était le réel sujet initial ;-)

[souviron34]

@spampete :

Je ne parlais que de ce qui devait être fait par les concepteurs pour la livraison, ce qui était le réel sujet initial ;-)

Merci. J'aimerais savoir si les "user acceptance test" doivent faire partir des documents à fournir par le developpeur.

est-ce que ça ça a à voir avec les tests informatiques comme tu les entends ???

Si oui, j'aimerais bien que tu me donnes ta définition de "user acceptance tests"...

[spampete]

eh bien.. en tout état de cause, les "user acceptance test", comme son nom l'indique, ne peut pas être fourni par les développeurs comme le proposait kisitomomotene dans le post du 25/5, puique le terme semble effectivement impliquer que les tests en question sont faits par les "users", donc le client.

ce que je prétends, c'est qu'avant de livrer un soft, une boite a quand même un minimum de plan de test à passer et qu'en général, suit un plan de recette a passer avec le client. Et que les résultat du plan de test peut éventuellement être livré au client.. Le client peut tres bien faire tous les tests d'ergonomie qu'il souhaite, pas de pb. Mais le contenu de ces tests utilisateurs ne peut pas défini par le client à sa guise une fois le soft livré, alors qu'en principe tout ce qui concerne l'ergonomie devrait avoir été défini d'un commun accord au début du projet, ou au moins pendant son cours.

quel problème au juste ?

bon..

[spampete]

au fond, puisque kisitomomotene proposait de livrer les "user acceptance test", il serait peut être bon de lui demander à lui ce qu'il désigne par ce terme, non ?

bon, en relisant le post, je m'aperçois qu'il l'a donnée, sa définition.. donc finalement, je dirais simplement que les tests en question ne peuvent en effet être définis que par le clients, juste le truc, c'est que leur définition fait partie du process de spec initial, c'est tout.

en somme, on est à peu près d'accord, me semble-t-il.. ;-)

bon allez, a ciao

[kisitomomotene]

Peut être que j'ai utiliser abusivement le mot "User" dans ma phrase "user acceptance", si je peux l'exprimer en fançais je parlais des tests d'acceptance effectuer par quelqu'un qui a un rôle d'utilisateur. Les developpeurs doivent en principe à la fin de leur developpement effectuer eux même les tests comme s'ils étaient des utilisateurs et documenter ces tests. Je me demandais si ce document devrait être livré au client, pour qu'il sache ce que nous avons testés pour affirmer avoir terminer le logiciel.

[spampete]

je crois qu'on appelle ça le "monkey test". Pas évident de montrer ça à un client. En revanche, pour trouver des anomalies, c'est une bonne pratique, qui ne doit toutefois pas remplacer le plan de test, juste le compléter.

finalement, ce dont tu parles me fait vraiment penser à une recette fonctionnelle à définir et passer avec ton client... mais bon, peut être que notre expert indépendant me contredira, après tout, je ne prétends pas tout connaîte ;-)

[souviron34]

moi non plus spampete je ne prétend pas tout connaître

je posais juste la question initiale, et suggérait des solutions...

Car, puisque nous sommes en technique, les mots ont un sens et doivent être employés correctement.

Donc, pour revenir à ce que tu dis, spampete, je suis d'accord : cela ressemble à une recette fonctionnelle. Et si c'est le cas, non, cela n'a pas à être livré au client.

C'est comme si tu achètes une voiture : tu te fous pas mal de savoir que le constructeur a fait faire 250 tours de circuit avec 3 pilotes différents et 600 virages à ta voiture avant de te la livrer. Tu t'attends à ce qu'elle soit en état de marche.

Par contre, les vrais "user acceptance tests" ont un intérêt, mais comme je disais au début, si le logiciel est important, doivent être définis par les utilisateurs, AVANT la livraison, réalisés AVANT la livraison, et génèrent en général des modifications (qui la plupart du temps sont GRATUITES, car dans ce genre de cas de figure le développement a été fait au forfait).

D'où l'intérêt d'avoir une approche "ergonomique" dès le départ (inclure les utilisateurs dès le début du cycle, dessiner les écrans et leur arborescence dès le début, et garder un "représentant utilisateur" tout au long du développement....)

Comme dit dans d'autres discussions, j'ai de mes yeux vu des projets échouer ou doubler de prix (et de délais) pour n'avoir pas pris ça en compte (d'où mauvaise architecture, arborescence à revoir, etc..). (pouvant aller jusqu'à la réécriture complète).


En gros : un informaticien, même se mettant dans la peau d'un utilisateur, ne se comportera JAMAIS comme un utilisateur.

[spampete]

oui bon, c'était un peu de taquinerie, c'est bien que tu prennes ça avec calme (ouf !) le moins qu'on puisse dire, mais je l'ai déjà maintes fois observé, c'est que l'ecriture est propice à l'incompréhension, aussi étonnant que ça puisse paraître.

bon, moi je parlais plus de la recette a faire avec le client, mais peu importe.

les tests avec les clients doivent clairement etre définis avant, fait avant la livraison et mener à des corrections gratuites, absolument.

les développeurs ne peuvent clairement pas se mettre dans la peau des utilisateurs réels, ça ne fait pas le moindre doute, sauf s'ils utilisent eux même leurs propres logiciels, ce qui est rare.

Pourtant, c'est une super pratique.. par exemple, l'outil de gestion de conf que je suis en train de développer, je l'utilise moi même pour gérer les sources dudit outil. Et là, je vois vite ce qui me fait perdre du temps, les erreurs, les points à améliorer. C'est super productif, et un gage général de qualité, même si bien sûr, je ne prétends pas représenter tous les comportements utilisateurs face à ce genre d'outil.

donc oui, c'est bien ce que je dis, en gros on est d'accord sur l'ensemble ;-)

les projets qui se plantent comme tu le decris sont effectivement des projets ou la phase de spec/dialogue avec le client a été manifestement négligée. Ca n'est quand même pas normal d'apercevoir des problèmes aussi graves seulement à la livraison. Et plus on les voit tard, plus ça coute cher.

Finalement, on en arrive à des constats que tous connaissent, non ? ou du moins... que tous devraient connaître !!

l'auteur du post souhaite-t-il d'autres opinions ? s'est il forgé la sienne ? car au fond, je ne suis pas sûr que toute cette discussion ait vraiment apporté une réponse à ses question ;-))

[souviron34]

En attendant la réponse du PO, juste un petit commentaire :

...
les projets qui se plantent comme tu le decris sont effectivement des projets ou la phase de spec/dialogue avec le client a été manifestement négligée. Ca n'est quand même pas normal d'apercevoir des problèmes aussi graves seulement à la livraison. Et plus on les voit tard, plus ça coute cher.
...

Au contraire, ils avaient suivi les normes (cycle en V, documentation, etc etc..), mais l'architecture ayant été décidée PAR l'informatique, ainsi que la présentation et l'enchaînement des écrans (ils avaient bien, pour la quasi-totalité, fait des specs, des analyses, des conception préliminaires, détaillées, etc...), quand la sortie finale n'était pas satisfaisante, en général c'était l'ARCHITECTURE qu'il fallait revoir (grosses équipes avec architecte "fonctionnel", architecte "organique", analystes programmeurs, programmeurs...), et la CONCEPTION de l'ARBORESCENCE....

Sauf que ce sont justement les normes de développement prises au pied de la lettre qui amènent ce genre de problème.. En fait ce que j'ai vu marcher était du style "méthodes agiles" (mais là aussi je dis "du style", car toute prise "à la lettre" est vouée à l'échec...).

(voir juste la discussion précédente (et les liens et pièces attachées) sur la conception d'IHM (http://www.developpez.net/forums/sho...d.php?t=297687))...

[spampete]

oui j'avais commencé à lire ce post sur la conception IHM, mais j'avoue que je n'avais pas assez de temps devant moi... ;-)

j'y retournerai surement, la discussion avait l'air intéressante

bon ok pour les méthodes appliquées au pied de la lettre, cela dit, un peu de méthode, ça peut parfois être utile quand même..! Des discussions que j'ai pu avoir, mais je m'écarte vraiment du post initial, certains souhaiteraient n'avoir de comptes à rendre à personne, tout en travaillant en équipe.. pas forcément la meilleure chose non plus.

cf la première discussion du sujet "SCM": http://www.developpez.net/forums/sho...d.php?t=152180

bonne semaine