IT & Bank luxembourg

Automatic trading et bugs automatiques.

oliotg — Thu, 28 Jan 2010 21:02:00 +0100

Type d’article bank 50% IT 50%

Pour suivre à la micro seconde les évolutions des marchés, de plus en plus d'organisme laissent à des logiciels la décision de passer des ordres en bourses. C'est ce qu'on appelle l'automatic trading. Si un ordinateur peut être le pilote automatique d'un avion pourquoi ne pourrait-il pas prendre des décisions d'investissement ?

Que ce soit un être humain qui passe un ordre ou une machine, le résultat est le même et l'organisme émetteur est engagé. Un bug qui achèterait n'importe quoi serait une sorte de Kirviel qui pourrait passer des centaines d'ordre par seconde. On imagine les dégâts...

Heureusement, les informaticiens et les banquiers sont des gens sérieux et les logiciels de trading automatique sont conçus, testés et exploités avec la plus grande rigueur. Enfin presque...

Selon un article du Financial Times (http://www.ft.com/cms/s/0/84950872-09e5-11df-8b23-00144feabdc0.html?nclick_check=1), des bugs ont été constatés par différentes bourses. A la manière des pirates informatiques qui font tomber des serveurs en leur envoyant des milliers de requête, ces bugs auraient noyés les bourses sous des montagnes d'ordre erroné. La seule conséquence aurait été de perturber le fonctionement des bourses.

A quand une affaire à la Kirviel avec une baie de serveur informatique dans le box des accusés?

Gwenael Oliot

IT architecture of a fund service provider

oliotg — Mon, 18 Jan 2010 22:49:20 +0100

Type d’article: Bank 50% IT 50%

The main topic of this blog is to link bank and IT. Enterprise architecture is a bridge between IT and Business. I tried to build this bridge in the document bellow:

I hope this document helps IT people and fund people understand each other building the best solution for fund services. Comments are welcome in this blog or by mail at oliotg@yahoo.fr .

Gwenaël Oliot

L’automatisation gagne du terrain dans les fonds luxembourgeois

oliotg — Sat, 12 Dec 2009 23:21:01 +0100

Type d’article : Bank 50% IT 50%

Selon une étude l’EFAMA l’automatisation de la gestion des ordres de souscription et de rachat gagne du terrain chez les agents de transfert des fonds Luxembourgeois. Le pourcentage des ordres traités automatiquement serait de 69% Q2 2009 contre 66% Q4 2008.

Gwenael Oliot

Détail de l’étude EFAMA ici : http://typo3.esolutions.lu/alfi/fileadmin/files/Member%20Services/NEWSFLASH/2009_11_11/EFAMA_SWIFT__Survey_.pdf

Circulaire CSSF 02/77 : les erreurs de VNI et dépassements de limite d’investissement.

oliotg — Sun, 06 Dec 2009 15:42:11 +0100

Type d'article: Bank 100% IT 0%

La circulaire CSSF 02/77 protége les investisseurs OPC des erreurs de calcul de VNI et des dépassements de limite d’investissement.

Les OPC ne sont pas des produits financiers tout à fait comme les autres :

La plupart des produits financiers s’échangent sur le principe du marché, un acheteur et un vendeur se mettent d’accord sur un prix. Pour les OPC, les acheteurs et les vendeurs s’adressent au fond pour obtenir un prix qui résulte d’un calcul comptable (la VNI). Que se passe-t-il si le comptable s’est trompé dans son calcul ?
Les OPC sont des produits diversifiés. Cette diversification est régie par des règles définies par la loi et dans les prospectus. Que se passe-t-il quand un fond ne respecte pas ces limites ?

La CSSF a répondu à ces deux questions dans la circulaire 02/77.

Quand une erreur de calcul de VNI est identifiée, l’administration centrale d’un fond doit se poser la question suivante: Est-ce que cette erreur est significative (seuil de matérialité) ? Si oui il faut :

Informer le promoteur du fond, le dépositaire du fond, et la CSSF.
Déterminer l’impact de l’erreur.
Réparer les préjudices.
Faire intervenir le réviseur du fond pour valider la procédure d’indemnisation.
Communiquer aux investisseurs à indemniser.

Dans tous les cas les frais occasionnés par les opérations de redressement sont à la charge de l’administration centrale ou du promoteur. Plus l’erreur est détectée tardivement, plus le nombre rachat/souscription passé est élevé, et plus le redressement est complexe et coûteux…

Pour un franchissement de limite d’investissement le processus est sensiblement le même sauf que le notion de seuil de matérialité n’est pas applicable et qu’il faut lancer la procédure au moindre dépassement.

Cette procédure n’est pas théorique, elle est appliquée régulièrement au Luxembourg. En 2008, 714 erreurs de VNI et 1519 dépassement de limite d’investissement ont été signalés à la CSSF. Ces chiffres peuvent paraître importants mais cela ne représente environ qu'une erreur pour pour mille calcul de VNI.

Gwenael Oliot

Pour en savoir plus

La circulaire CSSF 02/77: http://www.cssf.lu/uploads/media/cssf02_77.pdf
Les erreurs de VNI en 2008 http://www.cssf.lu/uploads/media/RA2008_chap02.pdf page 94.

Et si des informaticiens OPC étaient certifiés par l'IFBL ?

oliotg — Fri, 27 Nov 2009 20:27:07 +0100

Type d'article: Bank 50% IT 50%

L'Institut de Formation Bancaire Luxembourg (IFBL) propose des programmes de certification professionnelle pour tous les métiers de la banque. L'offre de certification est particulièrement bien fournie pour le secteur des fonds. Il y a une certification pour tous les métiers : Agent de transfert OPC, Comptable OPC, Agent banque dépositaire OPC, juriste OPC. Seuls les informaticiens ont été oubliés...

Aujourd'hui l'informatique est la colonne vertébrale de l'organisation des OPC. De plus en plus de règles métiers sont dans les systèmes IT à tel point que certaines activités traditionnelles sont vidées de leur substance. Combien y a-t-il de comptable fonds qui saisissent des transactions dans le système IT sans savoir vraiment sur quels comptes vont être passées les écritures ?

Pour les informaticiens OPC comprendre une exigence métier OPC et la première étape pour concevoir une solution IT OPC. Pour cela il faut être informaticien ET agent métier OPC. C'est là que l'IFBL pourrait apporter son savoir faire en formant les informaticiens.

Qu'est-ce que pourrait être le parcours de certification « Informaticien OPC » ?

D'abords comme pour toutes les autres certifications métiers OPC on pourrait imaginer devoir subir le parcours de base OPC. Ce parcours de base présente les produits financiers les plus rependus ainsi qu'une vision d'ensemble du métier des fonds.

Ensuite il faudrait ajouter des cours métiers complémentaires qui existent déjà dans l'offre IFBL : Un M1 comptabilité, un M1 agent de transfert, un M1 agent banque dépositaire. Ainsi l'informaticien aurait une vision d'ensemble des opérations d'un fond.

Enfin il faudrait concevoir et mettre en place de nouveaux modules de formation propre aux métiers informatiques. On peut imaginer :

M1 : Connaitre l'urbanisme des systèmes IT OPC. L'objectif serait de connaître les grands blocs applicatifs présent dans un système informatique OPC : le signalétique valeur, le référenciel fonds, les systèmes comptables, TA, Custody ainsi que les flux de données échangés entre ces blocs.
M1 : Connaitre la messagerie SWIFT pour les OPC. L'objectif est de connaitre les infrastructures techniques SWIFT et les principaux messages SWIFT et normes ISO15022, ISO20022.
M1 : Connaitre les solutions d'échanges IT avec les fournisseurs de données de marché. Connaitre les infrastructures techniques et protocole d'échanges avec les principaux market data provider : Bloomberg, Telekurs etc...

Le parcours de certification ne devrait pas contenir de cours trop techniques lié à tel ou tel langage de programmation ou tel ou tel système d'exploitation. Il serait également hors de propos de faire de la publicité pour tel ou tel progiciel bancaire.

Y aurait-t-il des étudiants intéressés par des formations OPC IT de l'IFBL ?

Mon expérience personnelle montre que le marché n'est pas nul. J'ai suivi plusieurs formations IFBL et il m'est arrivé de n'être pas le seul informaticien à venir apprendre le métier de banquier. Il est également possible que l'offre stimule la demande et que la création d'une certification IT draine de nouveaux étudiants. Il serait souhaitable de faire un sondage auprès des membres de l'ABBL pour valider l'opportunité de cours IFBL IT. Je suis convaincu que des informaticiens formés aux métiers des OPC seraient un atout pour la place financière Luxembourgeoise.

Si l'IFBL trouve mon idée intéressante, je suis à sa disposition pour l'aider à la mettre en place.

Gwenael Oliot

Le boom des hedge funds au Luxembourg

oliotg — Mon, 16 Nov 2009 22:19:46 +0100

Type d’article : Bank 100% IT 0%

Un article paru sur Reuters (à lire ici) parle d’un boom des hedge funds au Luxembourg.

Avec la chute de Lehman et de Madoff même les investisseurs les plus ouverts aux risques ont été des échaudés. Le cadre législatif du Luxembourg qui est plus rigoureux que celui des places off shore a de quoi rassurer.

Les gestionnaires de hedge funds sont de plus en plus séduits par le grand duché. Les nouveaux SIF autorisent la souplesse de gestion attendue dans un cadre prudentiel qui rassure. La fermeté de la CSSF vis-à-vis d’UBS la banque dépositaire du fonds Luxalpha (à lire Madoff / Luxalpha: CSSF vs UBS) est une démonstration de la solidité du système. Les suites de cette affaire sont suivies par nombre d’investisseurs comme un test grandeur nature.

Selon l’ALFI, le boom ne se fait pas encore ressentir en terme de volume d’actif sous gestion au Luxembourg, mais le nombre de hedge funds est en nette croissance.

On ne peut que souhaiter que ce mouvement se confirme!

Gwenael Oliot

Top compétence au 10/11/2009

oliotg — Tue, 10 Nov 2009 20:58:51 +0100

type de sujet: 10%IT 90%Banque

Quelles sont les compétences recherchées dans le secteur bancaire au Luxembourg ?

Pour répondre à cette question voici une étude basée sur le site de recrutement jobs.lu.

Le principe est simple :

On se connecte à http://fr.jobs.lu/ version française.
Dans le champ type d’emploi on sélectionne « Banque / Assurances ».
Dans le champ Zone géographique on sélectionne « Luxembourg ».
Dans le champ mots clé on saisie « un mot clé ».
On clique sur rechercher.
On compte le nombre de résultat.

Voici les chiffres obtenus :

Mot clé « domaine métier » :

Accounting :       24 (177) chiffre au 10/11/2009 (chiffre au 25/07/2008)

Risk :                19 (74)

Compliance :      18 (53)

Transfert:           13 (9)

Retail /détail :    15 (5)

Custody :           2 (56)

Mot clé « progiciel bancaire »

Multifonds :        2 (23)

Olympic :           0 (15)

T24 :                 0 (0)

Triple :              0 (0)

Mot clé « fonction »

Manager :          38 (150)

Analyste :          7 (64)

Projet        :       3 (3)

Mot clé « technologie IT »

Oracle :             3 (6)

Java :                1 (4)

Cobol :               0 (0)

.NET :                0 (0)

Mot clé « expérience »

Senior : 27 (106)

Junior : 6 (32)

Je vous laisse tirer vos conclusions.

Gwenael Oliot

Etude au 25/07/2008 http://oliotg.blog.lu/archives/553/20080726

Target2 Securities (T2S) simplifie les réseaux de sous dépositaire.

oliotg — Tue, 03 Nov 2009 21:09:25 +0100

Type d'article: Bank 100% IT 0%

Target2 Securities va offrir une opportunité de simplification du réseau de correspondant des banques dépositaires Luxembourgeoises.

Une banque doit avoir un sous dépositaire dans chaque pays où investi ses clients ou faire appel à un ICSD (Clearstream ou Euroclear) là où elle n’a pas de réseau. Le schéma ci-dessous représente le cas d’école d’une banque dépositaire présente dans le monde entier et qui ne ferait pas appel à un ICSD.

Après T2S cette banque va pouvoir simplifier son réseau en supprimant ses sous dépositaires dans les pays dont les CSD participent à T2S.

Cette banque pourra choisir d’accéder à T2S soit directement soit via Clearstream qui est le CSD Luxembourgeois. Si elle choisit l’accès direct, elle devra adopter le format de message SWIFT ISO20022 qui est le seul supporté par T2S. Si elle choisit l’accès via le CSD elle pourra utiliser tous les formats supportés par Clearstream.

D’autres options non représentés sur le schéma sont également possibles. Par exemple, si cette banque fait partie d’un groupe international, ce groupe peut choisir d’accéder à T2S via un autre CSD que le CSD Luxembourgeois.

On peut également noter que le réseau de correspondant cash sera lui aussi simplifié. Une seule banque centrale nationale pourra jouer le rôle du réseau dans les pays du périmètre de T2S.

Gwenael Oliot

Les restrictions d’investissement des fonds luxembourgeois

oliotg — Sun, 25 Oct 2009 08:36:17 +0100

Type d'article: Bank 100% IT 0%

Un des objectifs du cadre légal des OPC est de protéger les investisseurs par des règles de diversification. Ces règles complexes sont définies dans plusieurs textes de loi et circulaires CSSF.

L’objet de cet article est de donner une vision d’ensemble de ces règles. Il ne s’agit ici pas d’être exhaustif et le lecteur est invité à consulter directement les textes publiés au Journal Officiel du Grand-Duché de Luxembourg qui seuls font foi.

Gwenael Oliot

Le texte des lois et circulaires est disponible ici: http://www.cssf.lu/index.php?id=7

Target2 securities (T2S) au Luxembourg

oliotg — Fri, 09 Oct 2009 21:35:41 +0200

Type d'article: Bank 100% IT 0%

La session d'information T2S du 7 octobre 2009 s'est déroulée en partenariat avec l'ABBL dans les locaux de la BCEE à Luxembourg. Environ 150 personnes sont venues assister à l'événement des quatre coins de l'Europe. Les débats étaient présidés par Marc Bayle directeur du programme T2S de la BCE.

La journée s'est déroulée en quatre temps :

Un point sur l'avancement du projet.
Une discussion sur l'estimation du volume de transaction dans T2S.
Une discussion sur l'opportunité de doter T2S de fonctionnalités complémentaires en termes de gestion de liquidité.
Une discussion sur les apports de T2S pour l'industrie des fonds.

Les parties qui m'ont le plus intéressé ont été les deux dernières.

Un des grands apports de T2S est de pouvoir settler les transactions de titre européen en un lieu unique, en monnaie de banque centrale. Ceci permet de concentrer dans un seul compte cash les liquidités nécessaires aux achats de titres qu'il fallait par le passé éparpiller chez plusieurs correspondants commerciaux. Avec T2S, le montant de liquidité nécessaire sera plus faible et déposé chez un tiers plus fiable.

Une fonctionnalité est nécessaire pour que ces avantages soit réellement exploités : c'est une gestion performante du collatéral. Pour que la liquidation des transactions soit efficace, il est nécessaire de faire des prêts aux acheteurs en manque de liquidité. Il est indispensable que ses prêts soient limités et couverts par du bon collatéral.

Les exigences métiers actuelles (URD) de T2S prévoient déjà une gestion du collatéral. L'objet du débat était l'opportunité d'améliorer cette gestion, en la rendant plus automatique et plus en ligne avec le modèle légal de T2S. La majorité des intervenants étaient favorables à ce perfectionnement. En l'absence de telles fonctionnalités il est possible que de nombreux acteurs ne puissent accéder à T2S qu'à travers un tiers gestionnaire de collatéral.

Le débat sur l'apport de T2S au monde des fonds a également été intéressant. Un fonds a deux faces, Asset side, c'est un investisseur qui gère un portefeuille d'actifs ; Liability side c'est un produit financier dans lequel on peut investir.

Asset side, les fonds bénéficieront des baisses de coût de liquidation promises par T2S comme tous les autres investisseurs. Liability side, la question est plus ouverte. Les fonds sont-ils des actifs liquidables comme les actions classiques ?

Le monde des fonds est différent de celui des actions. Les actions classiques sont essentiellement échangées sur le marché secondaire, les fonds sont échangés principalement sur le marché primaire. Les actions sont tradables aussi longtemps que la bourse est ouverte, les fonds ne sont tradables qu’à des instants particuliers (cut off de VNI). La commercialisation des fonds mobilise un réseau de distributeur qu’il faut rémunérer.

Le monde des fonds n’est pas uniforme. Certains marchés sont basés sur le modèle « agent de transfert » d’autres sur le modèle « CSD ». Certains sont domestiques, d’autres sont internationales.

On le voit, les fonds ne sont pas des actifs comme les obligations ou les actions classiques pour lesquels T2S a été conçu. Modifier T2S pour qu’il s’adapte aux fonds ne serait-il pas trop lourd ? Comment être en ligne avec toutes les spécificités des OPC ?

Marc Bayle a terminé par une note d’optimisme, T2S a déjà su surmonter tant de particularisme...

Pourtant beaucoup de fonds européens sont dénominés en devises étrangères hors du périmètre de T2S. Il est clair qu’il est plus important pour l’industrie des fonds de rester ouverte aux investisseurs non européens que de faire de petites économies sur les coûts de settlement.

A suivre…

Gwenael Oliot

Pour avoir les supports de la présentation, cliquez ici

Les directeurs informatiques du secteur bancaire Luxembourgeois.

oliotg — Fri, 17 Jul 2009 20:06:13 +0200

Type d'article: Bank 50% IT 50%

Acteur clé entre la banque est l'IT: qui suis-je ? Le directeur informatique bien-sûr !

Voici une liste de références spécifiquement Luxembourgeoises dédiées à ce personnage :

Enfin je me permets d'ajouter une référence française vers l'excellent site du CIGREF http://www.cigref.fr/

Bonne lecture,

Gwenaël Oliot

De UCITS III à UCITS IV

oliotg — Wed, 13 May 2009 22:38:51 +0200

Type d'article: Bank 100% IT 0%

La règle du jeu des fonds va changer en Europe et donc au Luxembourg. Voici un article qui présente l’essentiel des évolutions :

http://investments.lawyers.com/blogs/archives/381-Luxembourg-Investment-Funds-From-UCITS-III-to-UCITS-IV.html

Bonne lecture,

Gwenaël Oliot

Pac Man Story

oliotg — Fri, 01 May 2009 15:02:54 +0200

Type d’article: Bank 0% IT:100%

Rond comme un ballon, jaune comme un citron, c’est Pac Man. Gentil petit bonhomme poursuivit par des fantômes, c’est Pac Man. Cela vous dit quelque chose ? Eh bien à moi oui… Il s’agit d’un jeu vidéo des années 1980. Une petite boule jaune pilotée par le joueur est poursuivie par des fantômes dans un labyrinthe et doit manger des pilules sans jamais être rattrapé.

C’est en 1987, quand j’étais en seconde, que j’ai programmé mon premier Pac Man. A cette époque j’avais un ordinateur Amstrad CPC 464. Cette superbe machine était équipée d’un écran 256 couleurs, d’un lecteur de cassette (les disques dures et les cartes flash n’existaient pas, et les lecteurs de disquette étaient trop chers) et de 64 ko de mémoire vive. Pour moi le grand atout de l’Amstrad face à son concurrent le Comodore était la simplicité de son langage de programmation.

J’ai passé plusieurs vacances scolaires à programmer mon Pac Man. Un des plus grand problème auquel j’ai dû faire face était la nécessité de faire bouger le Pac Man en même temps que le fantôme. Je bien dit « Le » fantôme car mon Pac Man n’avait qu’un seul fantôme mais doté du pouvoir de traverser les murs du labyrinthe. Ce pouvoir présente deux avantages. Le premier est que tous les vrais fantômes traversent les murs (c’est bien connu). Le second est que l’algorithme de poursuite du Pac Man est beaucoup plus simple, il suffit de diminuer la distance entre le fantôme et sa proie sans se soucier des murs… Le programme final comptait plusieurs milliers de ligne de Basic.

J’ai codé mon deuxième Pac Man en 1994. Fraîchement diplômé de mon école d’ingénieur j’étais à la recherche d’un premier emploi. Lors d’un entretien d'embauche, Nat Systèmes, l’éditeur du logiciel de développement NSDK m’avait donné pour chalenge de réaliser en une semaine un programme quelconque. Contrairement aux autres candidats qui avaient choisis des programmes très sérieux de gestion, j’ai choisi de coder une nouvelle version de mon Pac Man sur PC avec NSDK. Le contrat a été rempli, je me souviens que le recruteur jouait avec enthousiasme avec mon jeu. C’est donc Pac Man qui m’a permis de décrocher mon premier job. Plus tard j’ai utilisé les possibilités de NSDK pour faire tourner mon Pac Man sur Macintosh.

J’ai codé mon troisième Pac Man en Java en 1999. Il s’agissait d’une applet que j’ai programmé en un week end. Tout cela était orienté objet, quelques classes et quelques centaines de ligne de Java ont suffit.

A quand la quatrième version de Pac Man ? En quelle technologie ? Le dernier langage que j’ai exploré en 2008 est le Flex, mais il est trop proche de Java pour me donner envie de créer un quatrième Pac Man… Je suis cependant certain que cela me reprendra. J’aime trop la programmation pour que cela s’arrête. L’inspiration reviendra tôt ou tard…

Gwenael Oliot,

Les 20 principes de Target2 securities (T2S)

oliotg — Tue, 21 Apr 2009 18:44:35 +0200

Type d’article: Bank 100% IT 0%

Target2 Securities est en cours d’implémentation (Cf T2S pour les nuls). Il est possible de connaître assez précisément ce que va être cette plateforme en lisant le document d’exigence utilisateur qui est téléchargeable gratuitement sur le site de la Banque Centrale Européenne.

Ce document de 863 pages (en anglais) est le cahier des charges que devra remplir T2S. Se lancer dans l’analyse d’un tel pavé n’est pas un petit travail. Prendre connaissance des 20 principes qui gouvernent T2S est un bon point de départ.

Voici ces principes :

L’Eurosysteme sera en charge de développer et d’exploiter T2S en assumant sa propriété pleine et entière.
T2S sera basé sur la plateforme Target2, et fournira le même niveau de disponibilité de résilience et de sécurité que Target2.
T2S ne sera pas impliqué dans le paramétrage et l’exploitation des Dépositaires Titre Centraux (CSD), mais servira uniquement de plateforme technique de settlement pour les CSD.
La gestion des comptes utilisateurs de chaque CSD restera légalement attribuée à chaque CSD.
Le service de settlement T2S permettra aux CSD d’offrir de manière harmonisée à leurs participants un niveau settlement équivalent en terme de fonctionnalité et de couverture.
Les positions titres devront être changées uniquement dans T2S.
Certains CSD participants à T2S devront être désignés sous la directive Settlement Finality (SFD) dans leur juridiction respective.
T2S fera son settlement uniquement sur des positions cash en banque centrale.
L’objectif premier de T2S sera le settlement en Euro
Techniquement, il devra être possible de paramétrer d’autres devises que l’Euro.
T2S devra permettre à certains usagers d’être connecté directement à sa plateforme.
La participation des CSD à T2S ne sera pas obligatoire.
Tout CSD dont le settlement fonctionne en Euro sur des positions cash de banque centrale sera éligible pour participer à T2S.
Tous les CSD connecté à T2S bénéficieront des mêmes conditions.
Les CSD connectés à T2S le seront via des relations contractuelles harmonisées.
Tous les CSD connectés à T2S devront avoir un calendrier des jours ouvrables harmonisé et des horaires d’ouverture et de fermeture harmonisés.
Les règles et procédures de settlement devront être communes à tous les participants
T2S fonctionnera de la manière économe et n’aura pas pour objectif de faire du profit.
Les services T2S devront être compatibles avec les principes du code de conduite Européen pour le Clearing et Settlement
T2S devra offrir aux CSD participants un support qui respecte les cadres légaux et de supervision.

Gwenael Oliot

Pour en savoir plus: http://www.ecb.eu/paym/t2s/pdf/T2S_URD_V4.1_Final_March2009.pdf

Le test fonctionnel pour les nuls.

oliotg — Tue, 31 Mar 2009 19:11:10 +0200

Type d’article : Bank 0% IT 100%

L’activité du test fonctionnel est à la frontière entre le métier et L’IT, incluse entre les tests unitaires du programmeur et les tests métiers de la maîtrise d’ouvrage.

Les tests unitaires sont des tests « boites blanches » d’un module d’application, les tests fonctionnels sont des tests « boites noires » d’une application, les tests métiers sont des tests « boites noires » d’un processus et donc de plusieurs applications.

Le point d’entrée du travail du testeur fonctionnel est la documentation des exigences fonctionnelles. La première tâche consiste à rédiger les cas de test. Il faut recenser les exigences fonctionnelles et pour chacune prévoir le ou les cas de tests qui permettent de garantir la conformité du logiciel. Il s’agit d’être astucieux en créant les cas les plus simples possibles tout en étant exhaustif.

Une fois les cas définis, il s’agit de les enchaîner sous forme de scénario. L’ordre d’exécution ne doit pas être laissé au hasard. Une bonne pratique consiste à estimer le niveau de risque des cas de test et de commencer quand c’est possible par les plus risqués. Ainsi on peut augmenter la probabilité que les bugs les plus graves soient trouvés en début de campagne de test, ce qui laissera plus de temps pour les corriger. Il est également utile d’estimer la complexité des cas de test car cela permet de suivre plus finement l’avancement des campagnes de test.

L’étape suivante est la préparation des tests. Pour chaque cas il s’agit de préparer les données de test. Deux solutions sont possibles, soit identifier des données existantes soit construire des données sur mesure. La première approche qui est la plus simple est conseillée. Malheureusement il arrive que les données n’existent pas, par exemple pour un tout nouveau système ou quand il s’agit de tester un cas très particulier. La préparation des tests inclut la réalisation d’outillage de test. Les tests fonctionnels se limitant à une seule application il est souvent nécessaire de simuler la présence d’application amont ou aval. Pour réaliser ces outils le testeur fonctionnel doit le plus souvent faire appel à un programmeur.

L’étape suivante est l’exécution des tests. Chaque cas est exécuté si possible dans l’ordre défini par les scénarios avec les données et les outils préparés aux étapes précédentes. Quand un résultat n’est pas conforme aux exigences, le testeur en informe l’équipe de développement qui confirme le bug ou remet en cause la pertinence du cas de test. Le testeur doit donner les informations les plus précises possibles au programmeur pour l’aider dans son diagnostique. S’il s’agit d’un bug, une nouvelle version du programme doit être livrée et testée. Un processus clair de suivi des bugs et corrections est indispensable. Régulièrement le testeur fonctionnel rend compte de l’avancement de ses tests. Le nombre de cas de test exécuté pondéré par leur complexité est un bon indicateur d’avancement.

Un bon testeur fonctionnel doit être rigoureux pour ne rien laisser passer, astucieux pour trouver les cas de test les plus simples, patient quand rien ne marche, diplomate pour signaler les bugs sans agresser les programmeurs et disponible quand il s’agit de donner un coup de collier à quelques jours de la mise en production. Une bonne connaissance de l’application à tester est un grand atout et du bon sens est indispensable.

Quelques conseils pour un testeur fonctionnel :

Avant toute chose, il faut réclamer des documents d’exigence fonctionnelle (ou en rédiger).
Ne pas négliger la phase de préparation pour utiliser la phase d’exécution des tests à tester réellement (La phase de préparation n'est pas sur le chemin critique du projet alors que l'exécution oui).
33% de l’effort sur la rédaction des cas de test, 33% sur la préparation, 33% sur l’exécution est un bon ordre de grandeur pour la repartission de la charge.
Lors de la planification d’une campagne il est sage de prévoir une durée et des ressources pour exécuter plusieurs fois tous les cas de test. En effet, certains bugs peuvent bloquer l’exécution des tests pendant de longue période, ou la livraison successive de corrections nécessiter d’exécuter plusieurs fois les même cas.
Soyez courtois avec le programmeur même si rien ne marche.
Soyez inflexible sur le respect des exigences fonctionnelles, c’est votre raison d’être. Si une exigence n’est pas respectable alors il faut négocier son amendement mais ne pas cacher une non-conformité.
Gardez autant que possible des preuves de vos tests (par exemple des print screen), car il se trouvera toujours quelqu’un pour vous reprocher de ne pas les avoir exécuté correctement.

Gwenaël Oliot

Article sur les tests unitaires: http://oliotg.blog.lu/post/553/2619