Question aux pros de l'informatique.

[Gilou]

Bon je développe un peu, dans le cadre de ma fonction il m'arrive de devoir tester des "release" avant mise en production, mais comme on est bien organisé dans les grandes administration supra nationale, tout est fait au feeling usuel Bien entendu comme on récupère pleins de projets, il arrive que le temps manque et donc qu'il faille déléger, mais voilà les autres collègues ne connaissent pas les applications à cent pourcent et donc je perds mon temps à superviser, répondre au question etc...
Donc on va mettre en place des outils d'automation de tests mais il faut les scénari pour que l'on puisse développer les script, d'ou ma question a ce propos.

Dans votre boulot vous arrive-t-il de devoir faire des tests sur des softwares développés en interne, si oui, avez vous une methodologie précise ?
utilisez-vous des scénarios de test sur document Word, avant la mise en place de script.


Sinon plus généralement, comme je viens de chopper deux ordinateurs de plus, je les ai mis en "Lan" chez moi pour pas qu'il s'ennuient . Mais voilà, l'un d'eux servira de connexion Citrix pour l'usage des applications de mon taf, (Check connexion, maintenance, support utilisateurs, etc..), dans ce cadre il tournera vingt quatre heures sur vingt quatres, et bien entendu échangera des données.
Un second me servira à me connecter sur le serveur oracle pour la maintenance des tables.
Le troisième servira pour la mise à jour de documents divers dans "Documentum" (outil d'archivage), et tournera aussi vingt quatre heures sur vingt quatre
Et le dernier me servira pour usage perso (Privé-professionnel).
Touutes ses bêtes risqueront de faire exploser mon volume de débit de ma connexion internet, donc je devrai re-facturer le débit supplémentaire au client alors:
Connaissez-vous un outils gratuit qui mesure le volume de débit échangé par une connexion Internet ? (A télécharger bien sûr)

Merci pour tout

[palantix]

Salut Gilou,

Vaste sujet. Voici des éléments de réponse que je peux apporter.

A) A partir des spécifications des besoins utilisateurs, il faut concevoir des cas de test. Un cas de test peut être "passant" ou "non passant".

Exemple : si x = a alors affiche b => cela te fait 2 cas de test :
1) si x prends la valeur a, ton application affiche b ("passant")
2) si x prends une autre valeur, alors afficher un message d'erreur par exemple ("non passant")

Un cas de test peut se formaliser sous ton tableur préféré de la manière suivante :
* Un contexte de données
* Les évènements en entrée
* La description du cas de test
* Le résultat attendu

B) Associé à ces cas de test, il te faudra donc des jeux d’essais (c'est-à-dire des données qui te permettront de dérouler tes cas de test). Il est important pour la qualité de test que les jeux d’essais soient le plus proche possible des données réelles.


C) Tes cas de tests vont être organisés en scénarios (enchaînement de cas de test). En terme de présentation, on reprends les infos des cas de test (copie coller avec liaison dans une autre feuille de ton tableur) avec en plus à côté de la colonne résultat attendu, une colonne résultat obtenu : cette colonne te permettra de formaliser le résultat de ton test.

Voici un rapide résumé de la méthode.

Se pose ensuite la question des tests de non régression. La manière la plus efficace (mais aussi la plus lourde) est de repasser une seconde fois tes scénarios de test pour voir s’ils sont toujours bons.

Enfin, pour tester des grosses applications, il est possible d’utiliser des progiciels de testing : il faut les paramétrer avec tes cas de test, tes jeux d’essais, tes scénarios pour qu’ils puissent faire les tests. C’est particulièrement pratique pour la non régression. Par contre, il faut vraiment que cela en vaille le coût car c’est cher à l’achat et long à paramétrer.

Si tu veux plus d’infos, à ta disposition

Palantix

[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 ...