Question aux pros de l'informatique.

[Manu Militari]

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+

[Gilou]

Pour répondre aux questions diverses:


Les applications testées sont des applications de divers types:

1) Logistique (Gestion des approvisionnement, gestion d'inventaire immobilier, gestion d'inventaire mobilier, gestion d'inventaire informatique, gestion d'inventaire automobile, gestion d'inventaire consomable, déménagements, redéploiement.
Elles sont faites soit en Powerbuilder (client serveur), soit en Coldfusion (ancienne version web), soit en Java (nouvelles version pour 2007)

2) Comptable (Paiement factures) et financière (Gestion des assets). Pour les factures, elle sont en JAVA (Web), et pour les assets en Coldfusion (Web).

3) Documentaire sous Documentum, au travers d'un interface UML (si je me souviens bien)

Toute ses applications tourne avec une interactivité en SAP (partie financière) et en Oracle (partie logistique).

Tout est développés en interne, et l'on ne recours que rarement à des produits "clés en main" car le business et propore au client (Institutions européenne).

Au total nous avons donc seizes application différentes

Mon problème principal est que nous n'avons quasi aucuns tests scénari fiable, car l'analyste (parti depuis) était un verritable brouillon

Pour tester on a des produits dédiés à cela (Winrunner, Quick test professionnal, etc...)

Le problème avec ces outils, c'est que pour tester les appli JAVA il nous faudrait une instance directe avec la base de données sur les serveurs applicatifs, mais comme c'est un autre département qui gère l'infrastructure, on ne l'a pas. En plus le site des serveurs n'est pas en Belgique donc impossible de travailler en direct sur les dit serveurs.

En plus je n'ai pas de ressource en personnel très important, il faut donc que mes troupes, trois personnes (moi compris), se partage entre les tests, et le support troisième niveau (9200 utilisateurs).

Voilà

[palantix]

Belle architecture de SI .

Au vue de ce que tu décrits, il faut de toute façon faire des tests appli par appli puis leur intégration avec les autres.

Et au vue de ma pratique sur le sujet (plusieurs années sur ce type d'experience + encadrement équipe dédiée sur les tests et recette d'applications spécifiques ou progiciels), sans spécifications détaillées fonctionnelles et techniques, tu ne pourras pas faire grand chose . A la limite dans un premier temps, si elles sont manquantes, il faut commencer par mener un premier chantier de Reverse Ingénierie pour constituer cette documentation.

Sur la partie progiciel (type SAP ou autre), il faut voir ce qui relève du standard, de ce qui a été développé en spécifique. Cela a son importance, car le standard relève de l'éditeur, le spécifique de la SSII qui a fait les développements.

Et les outils ne serviront pas à grand chose. Sur un de mes projets (avec une équipe de 5 personnes à plein temps dédiée à 100% aux tests et à la recette fonctionnelle et technique - ce qui laisse imaginer la taille de l'équipe projet derrière ) nous avons abandonné les outils après avoir essayé de les mettre en oeuvre : trop lourd, trop couteux.

Il fallait bien mieux faire la non régression en repassant tout ou partie des cas de tests manuellement que d'essayer de paramétrer ces bousins ...

Au vue de l'ampleur de l'architecture, il peut aussi être intéressant de trouver une société de services info uniquement pour les aspects tests, recette et qualification des applications.

Bon courage ...