TESTING IT

Vidéo : Liste de liens à visionner en mangeant des chips

2008-09-24T20:36:00.004+02:00

Software Testing How To Enter Defect in Defect Tracking tool

Regression Testing in Software Testing Projects

Unit Testing in Software Testing Projects

System Testing in Software Testing Projects

User Acceptance Testing in Software Testing Projects

Integration Testing in Software Testing Projects

Usability Testing in Software Testing Projects

GTAC 2007: Huggins & Stewart - Selenium-RC Vs WebDriver

GTAC 2007: Simon Stewart - Web Driver

GTAC 07: Chow & Etchebehere: Bldg Framework Around Selenium

Phillip Bice, Red Stone Software

Site sur lequel il y a de nombreuses vidéos

Vidéo : Software Testing - Career Training, Portnov School - 1

2008-09-24T20:33:00.001+02:00

Introduction to the Portnov School founder's background in Software QA and the school being formed

Vidéo : Test Automation Conference - Selenium / Google

2008-09-24T20:26:00.005+02:00

23 et 24 aout 2007 : "The 2nd Annual Google Test Automation Conference (GTAC) in our New York office. Huggins & Stewart - Selenium-RC Vs WebDriver"

Sexe et tests !

2008-09-24T19:55:00.002+02:00

Emma Berger, directrice marketing de SSL Healthcare (DUREX) :
"Il est difficile d'obtenir de vraies informations sur le sujet. Parler en détails de ses relations sexuelles n'est pas toujours socialement valorisant, et les gens sont souvent gênés. Mais Internet casse cette barrière car personne n'est en face de pour vous juger, c'est pour cela que nous avons eu l'idée de recruter des testeurs sur le Web pour réaliser une enquête 100 % en ligne".

Durex a en fin de compte recruté plus de 20 000 testeurs et teuses !

Les bilans des tests sont en cours d'analyse...

Site Web de recrutement

Anomalies, bugs et catastrophes !

2008-09-24T19:37:00.005+02:00

FRANCE :
2007 / 2008 :
Affaire à Epinal : pas un bug mais un mauvais paramétrage dû à une documentation en anglais mal comprise (cm/mm)

2006 :
2 grandes banques françaises exécutent un double débit pour plus de 400000 transactions

2004 :
Novembre - Le réseau téléphonique national de l'opérateur mobile Bouygues Telecom a été victime d'une panne informatique qui a bloqué l'émission et la réception des appels. Deux serveurs centraux fonctionnant en relais sont tombés en panne simultanément.
Cette panne s'est située au niveau de «deux serveurs centraux jumeaux, au même moment, dans deux endroits différents». Normalement, «ils se secourent en prenant le relais l'un de l'autre». Ici cela n'a manifestement pas été le cas...

Novembre - Le réseau de France Telecom saturé à cause de "zéros parasites" dans sa passerelle VoIP. Le bug provient d'«une anomalie logicielle localisée dans un équipement de traitement de la voix sur IP», a indiqué FT mardi soir dans un communiqué. En fait, a précisé l'un de ses porte-parole à ZDNet, cette passerelle, qui fait transiter les appels en VoIP vers le réseau commuté classique, a «mal interprété» certains numéros composés par des utilisateurs. Explication plus poussée: un simple zéro a été ajouté par erreur, sans que l'utilisateur le sache. Résultat, les numéros composés ont été considérés à tort comme provenant d'un opérateur tiers international.

1996 :
Ariane 5 explose en 1996 (erreur de réutilisation)

USA :
1999 :
Perte de Mars Climate Orbiter lors de son insertion dans l’orbite de Mars (problème de traduction entre systèmes métriques, des pounds anglais vers les newtons).

1991 :
Un missile patriote américain n’intercepte pas un missile Squd irakien qui tue 28 soldats. En cause, une dérive de l’horloge du missile anti-missile (*1/10 au lieu de
/10 et erreurs d’arrondis cumulées).

1990 :
Le réseau électrique de ATT tombe (1990) : une instruction break mal placée dans du code C

1985 / 1987 :
Le Therac-25 : machine de radio-thérapie qui a administrée des doses aberrantes de radiations entre 1985 et 1987, au moins 6 overdoses de radiations répertoriées.

1962 :
Perte de la sonde américaine Mariner 1 à destination de Vénus est probablement due à une erreur dans un programme en Fortran. Un point avait été codé à la place d'une virgule... Ce seul caractère changeait la sémantique même du programme et provoqua la disparition de la sonde.

Une des plus belles collections de bugs et ici !

La certification ITIL V3 de l'intérieur...

2008-09-24T11:52:00.005+02:00

La semaine dernière j'ai passé trois jours en région parisienne pour être certifié ITIL V3 Foundation. C'est surtout car c'est un sujet qui me titille intellectuellement depuis de nombreuses années et qu'avec cette certification je pourrais parler pilotage par les processus et best practices de manières plus confortable avec mes clients.

Jour 1 :
9h10 - Ma société possède un centre de formation en propre et je découvre les locaux... somptueux !
En effet, un étage complet est consacré aux formations, avec de grandes salles possédant chacune des PC et des écrans !
Ce qui est presque un miracle pour une SSII. Dans mes autres SSII les formations se déroulaient dans des bureaux vides, sans PC et avec de la chance nous avions des vidéo-projecteurs (qui fonctionnaient souvent...).
Après cette découverte hallucinante je me plante devant le distributeur de café et... Oh My God ! Le café est gratuit ! (ce qui devrait être mis en avant au niveau RH pour le recrutement, car pour un collaborateur le budget café est énorme à la fin de l'année).

9h15 - j'ouvre la porte de la salle de cours et... 15 têtes et 30 yeux (et autant d'oreille mais on s'en fou) me scrutent car je suis en retard (surement une bande de psychopathe car le cours devait commencer à 9h10...) penaud je m'assied dans un coin et ouvre mes oreilles avides de savoir.

J'ai passé la journée à :
- Checker mes mails pro et personnels via mon téléphone (je ne cite pas la référence car je ne voudrais pas de faire de pub pour Apple),
- M'absenter parfois car dirigeant un projet dans le sud de France je dois intervenir auprès du client pour négocier... au téléphone, à 800 kilomètres du client.
- Ecouter le prof me parler du pilotage par les processus, énumérer et passer en revue chacun de ces processus avec les objectifs, les livrables, les actions, le RACI, la roue de DEMING, etc.

Le sujet "ITIL V3" n'étant pas hyper sexy j'avoue que le professeur a été d'une pédagogie très attractive et a su m'interesser au sujet de manière très plaisante. Des prof comme cela sont hélas trop rare... surtout qu'avoir un "vrai professeur" via une formation d'une SSII est TRES RARE.
Très souvent "le professeur" est un consultant en inter-contrat à qui on à dis "toi qui passe dans le coin, tu ne fais rien ? Prends les slides sur mon bureau et...". J'ai eu de la chance sur ce coup j'avoue.

Fin de journée - gavé comme une oie par les 200 pages passées en revue dans la journée et la gestion en parallèle de mes équipes je remonte sur la Défense pour déguster un cheese (pas de réseau en formation et seul M...Do donne l'accès au Wifi gratuitement) et... me connecter enfin et lire mes mails pro car la batterie de mon téléphone a lâchée dans l'après-midi (?!/$*§! de portable).

Jour 2 :
9h10 - Gros plan sur mes yeux qui scrutent les choix du distributeur gratuit... café... thé citron... potage... mes papilles salives à l'idée de savourer un délicieux potage à la tomate avec des croutons... tôt le matin... euh... en fin de compte ok c'est gratuit mais je vais m'en tenir à un café long.

J'ai passé la journée à :
- Encore checker mes mails pro et personnels via mon téléphone,
- M'absenter parfois car un de mes chefs de projets cours autour de son bureau comme un poulet sans tête et m'appel à l'aide,
- Ecouter le prof me parler encore du pilotage par les processus, énumérer et passer en revue chacun de ces processus avec les objectifs, les livrables, les actions, le RACI, la roue de DEMING, etc.

Fin de journée - gavé comme une oie par les 100 autres pages passées en revue dans la journée je vais... encore manger un cheese et lire mes mails...

Jour 3 :
9h10 - Café
9h15 - Je fais désormais partie intégrante des 16 têtes et 32 yeux, ils sont devenues mes nouveaux meilleurs amis car nous devons passer ce jour la certification tant désirée.
Le prof nous fais faire 3 séries de 40 questions pour nous entrainer. Ce qui fais qu'à la fin de la journée j'aurais répondu à 160 questions.

J'ai décidé de ne lire mes mails qu'en fin de journée dans le M...Do, ainsi je peux continuer d'utiliser mon téléphone comme un bête téléphone... Quand j'arrive dans le M...Do les serveuses me souris et je vois dans leurs yeux que je ne suis pour elles que 1m72 de cheese en puissance. Dans l'instant je passe du statut expert testing à celui de montagne de cheese !

Moralité :
Le cheese est l'ami du professionnel communiquant en goguette !

Emplois !

2008-09-24T09:42:00.004+02:00

Je listerai au fur et à mesure les sociétés ayant des activités dans le monde du test. Je tenterai également de vous faire part de mon ressenti...

FRANCE :
SOGETI ==> SSII ayant une offre testing qui s'appuie sur la méthodologie TMAP Next. Méthodologie existante depuis de très nombreuses années. Je rédigerai un prochain article sur ce sujet.
Qualife : SSII œuvrant surtout dans le sud de la France

MONDE :
Adresses en Allemagne et Chine :
http://www.industrystock.com/html/Test%20de%20logiciel/product-result-fr-38083-0.html

Formation et cursus sur les tests

2008-09-24T09:34:00.006+02:00

Dans cet article vous trouverez la liste des cursus et formation disponible en France et à l'étranger. Bien entendu je n'y indique pas les formations délivrées par les SSII :

France :
Bretagne - CNAM
Paris - CNAM - 1
Paris - CNAM - 2
Paris - Learning Tree
France - Formation à distance de l'état

Littérature sur le monde des tests

2008-09-24T09:29:00.006+02:00

Dans cet article je mettrai à jour régulièrement les livres en rapport avec le monde du tests (je ne touche rien même si vous cliquez sur les liens).

Livres :
- John-Watkins-Test-logiciel (Fr.)
- Test de logiciel (Technique et science informatiques RSTI Vol.21 N° 9/2002) (Fr.)
- Tests logiciel par Maurice Rozenberg (Fr.)
- Effective GUI test automation par (Ang.)
- Java testing patterns par Jon Thomas, Matthew Young, Kyle Brown et Andrew Glover - Wiley (Ang.)
- JUnit recipes par J. B. Rainsberger
-

Format PDF :
- Tests des logiciels par Frédéric Juillard de l'université de Brest
- Tests des logiciels par Yves Le Traon

La recette au cœur de la communication projet

2008-09-24T00:19:00.003+02:00

Dans cet article les rôles et responsabilités des différents acteurs intervenants dans le projet de recette sont décrits.

La recette au cœur de la communication projet

« Plus un projet est vaste et complexe, plus la conduite de projet s'éloigne du domaine de la technique pour se rapprocher de celui des relations humaines ».

Une particularité d’un projet recette est liée à la communication envers tous les acteurs du projet global. En effet, il faut que les testeurs communiquent avec les acteurs représentants le client (métiers, MOA, MOE, etc.), les développeurs (intégrateurs, TMA, etc.) et l’équipe de recette en interne.

« Si tu ne connais rien de toi et de tes ennemis alors l’heure de la défaite sonnera certainement. » Sun Tzu

Il faut communiquer afin d’aller recueillir les informations nécessaires à l’organisation et la préparation des recettes. De plus, communiquer permet d’organiser et participer aux réunions d’anomalies permettant de les qualifier, avec l’aide du client et de l’intégrateur. Enfin, cela permet de présenter le suivi des recettes et la remontée des indicateurs aux chefs de projet impliqués.

Mais il faut aussi, souvent communiquer pour éduquer et faire de la pédagogie auprès des clients et des développeurs. Car dans l’esprit de ceux-ci les testeurs sont synonymes de « tester est inné, on ne peut pas systématiser les tests, n’importe qui peut tester, un bon testeur est celui qui trouve le plus de bug, les testeurs ne doivent pas gêner le développement, juste contrôler rapidement, etc. ».

Pour changer les mentalités il faut commencer par comprendre les interlocuteurs.

Mentalité du client :

La mentalité des « clients » (entreprises, DSI Directeur des Systèmes d’Informations, etc.) est très égocentrique et se traduit par des exigences métiers. Les clients, par définition, n’ont que très rarement conscience des problématiques qu’engendrent leurs exigences au niveau des projets. C’est aussi pour cela que les testeurs ont un rôle de « traducteur » entre les métiers, la MOA, la MOE, les développeurs.

Pour assurer au mieux notre rôle de testeur il est important de comprendre les trois grandes logiques clients. La « Logique métier » où l’utilisateur pense que sa logique métier est suffisante et ne se soucie pas des spécificités de l’informatique.
Puis la « Logique liée à la maquette » qui est la présentation d’une IHM « alléchante » mais uqi ne révèle qu’une face mineure de la complexité informatique.

Enfin, la « Logique qui dis que l’informatique suivra ». Dans ce cas les utilisateurs ont tendance à penser que les systèmes d’informations sont capables de résoudre n’importe quel problème.

Mais il faut avoir toujours à l’esprit que le client (MOE, MOA…) est celui qui connaît le mieux son métier, son entreprise, les contraintes et les applications. Nous sommes mandatés par lui pour contrôler le produit qu’il a commandé et c’est l’interlocuteur parfait pour les informations dont vous aurez besoin. Les testeurs ont aussi un devoir de conseil envers lui.

Il achète un logiciel et ses défauts, son intérêt est de détecter les défauts au plus tôt avant la fin de garantie et de sécuriser la mise en production du logiciel.

Ce qui au final se traduit par des cahiers des charges ou des expressions de besoins très légères avec des informations de type « Nous voulons gérer la facturation bien mieux qu’actuellement… ». Charge aux testeurs d’aller creuser et chercher l’information dans les têtes des métiers et des développeurs, souvent sous forme d’atelier organisé avec tous les acteurs partie prenante.

Mentalité des développeurs :

La plupart des équipes de développement ont le « Syndrome du Top gun » qui déclare : « Nos ingénieurs sont très bon, ils maîtrisent nos méthodologies et normes de développement. Il ne peut y avoir de bugs ! ». Au-delà de ce « syndrome » M. Weinberg (The Psychology of Computer Programming) expose les points suivants : les erreurs peuvent être plus facilement repérées par d'autres et programmer / coder s’apparente souvent à une création personnelle, un programmeur ne sait pas ou ne veut pas voir ses erreurs.

Alors que si les programmes sont montrés aux autres ils deviennent moins personnel ("egoless programming") et on admet plus facilement ses erreurs.

Ce qui illustre bien le fait que pour tester il n’est pas recommandé « d’être juge et partie ».

Au même titre que la logique des clients il est important de comprendre celle des développeurs.

La « Logique informatique » où l’ingénieur a tendance à croire que la technologie se justifie par elle-même. Le développeur est très souvent plus sensible à la prouesse technique qu’à la satisfaction du client final. La « Logique de transposition des technologies », car il est toujours très tentant de transposer une technologie qui a fait ses preuves et que l’on maîtrise, dans un certain contexte sur un autre contexte.
Il y a aussi la maturité de l’organisation de développement qui ne dépend que des personnes qui la constituent et de leurs méthodes de travail. Enfin, l’implication du client où le fournisseur aura tendance à « mouiller » son client dans des décisions où il n’a aucune compétence. Il pourra ainsi justifier les éventuels problèmes rencontrés.

Les testeurs ont donc un rôle d’interface très important entre ces acteurs. Car nous devons vérifier et nous assurer que les exigences clients sont bien respectées et de bonne qualité en production.

Il faut donc établir un canal de communication clair avec les autres acteurs :

Figure : Acteurs d’un projet de recette

(Intégrateur est souvent synonyme de développeur)

Concrètement que faire ?

Il existe plusieurs manières d’améliorer la communication et les relations entre les testeurs et leurs interlocuteurs. Il faut commencer par une collaboration plutôt que par des conflits et rappeler à chacun l’objectif commun de systèmes de meilleure qualité. Il faut aussi communiquer les découvertes sur le produit de façon neutre et factuelle sans critiquer la personne responsable, par exemple, écrire des rapports d’incidents (ou des résultats de revues) objectifs et factuels. De plus, il faut également essayer de comprendre ce que ressent une autre personne et pourquoi elle réagit comme elle le fait. Enfin, confirmer que l’autre personne a compris ce que l’on a dit et vice versa.

Enfin, les personnes et les projets sont dirigés par des objectifs. Les personnes ont tendance à aligner leurs plans en fonction des objectifs mis en place par le management et les autres responsables, par exemple, pour trouver des défauts ou confirmer qu’un logiciel fonctionne.
De ce fait, il est important de spécifier clairement les objectifs des tests.

Le chef de projet doit communiquer pour que le client ait en permanence une visibilité sur les activités de l’équipe de tests et ainsi éviter le « fameux effet tunnel ».
Concernant l’estimation des charges, il doit veiller à ne pas décevoir le client et toujours promettre moins et en faire plus.

Composition d’une équipe de recette type

Une fois les acteurs définis passons en revue l’équipe de test, leurs rôles et responsabilités. L’équipe de recette type est la suivante :

Figure : Equipe de recette type

Les trois profils sont les chefs de projet, l’analyste et l’ingénieur de test. Les rôles de chacun sont décrits ci-dessous.

Le chef de Projet test a les responsabilités suivantes :

le pilotage et suivi du projet, animation de l’équipe,
être l’interface privilégiée avec le client pour les aspects organisation et suivi du projet,
organiser et animer les comités de suivi du projet,
planifier les tâches et gestion des ressources,
élaborer avec le client des indicateurs d’avancement et de suivi (tests, anomalies) et les tableaux de bord de suivi du projet,
présenter les tableaux de bord.

L’analyste de test doit effectuer les tâches suivantes :

organiser les tests sur un des domaines du projet en coordination avec le chef de projet, selon projets, encadrement d’une équipe d’ingénieurs de qualification.
spécifier et concevoir les tests,
exécuter les plans de test,
vérifier les résultats,
faire l’édition de synthèse des résultats de test,
rédiger les rapports d’anomalies.

L’ingénieur de test doit procéder aux activités suivantes:

exécuter les plans de test,
vérifier les résultats,
faire l’édition de synthèse des résultats de test de sa partie,
rédiger les rapports d’anomalies.

Il faut noter que les profils de type « Ingénieur de test » se font de plus en plus rare. Ce terme est surtout utilisé pour décrire un collaborateur ayant un tarif plus bas que celui d’un analyste (bac + 2 au lieu de bac + 4 par exemple). Ce profil de simple exécutant de fiches de tests existe aussi en cas d’externalisation des tests en Inde, au Maroc, etc. Et dans ce cas uniquement l’ingénieur de test ne fait qu’exécuter les fiches de tests.

Quels sont les qualités d’un bon recetteur ?
Comme expliqué ci-dessus c’est tout d’abord être un bon communicant mais aussi avoir une bonne synergie entre savoir-être et savoir-faire :

Figure : Synergie entre savoir-être et savoir-faire

Le savoir-faire est composé des formations et expériences acquises lors de la vie professionnelle d’un salarié. Ce peut être des formations suivies en interne ou bien des cursus comme ceux que proposent les organismes comme le FAFIEC, le FITEC ou bien le CNAM.
Le savoir-faire est donc un acquis.
Comme on le constate l’expérience acquise est très importante pour monter en compétence sur les métiers du test.

Le savoir-être est composé des qualités principales comme la rigueur, la souplesse et la faculté de ne laisser passer aucun détail. Lever les ambiguïtés sur une fonctionnalité, prévoir tous les risques potentiels, noter chaque décision et vérifier la bonne prise en compte.
Les autres qualités sont d’identifier toutes les tâches sans en oublier une seule, identifier toutes les questions restées en suspend et n'en laisser aucune sans réponse et enfin garder des traces de chaque décision.
Tous ceci est différent de la raideur, soit l’impossibilité d'accepter de changer d'idée, de s'adapter à une nouvelle situation, à un nouveau contexte.
Il faut être bon communicant et savoir exprimer ces idées à l’oral et par écrit et savoir écouter : être ouvert au dialogue. Soit essayer de comprendre les autres (à l'écrit et à l'oral), avoir une certaine ouverture sur leurs idées.
Il faut aussi être convaincant (≠ « avoir un mauvais caractère »), et prendre en compte les positions de la hiérarchie ou de la maîtrise d'ouvrage qui sont quelque fois à l'opposé des conditions optimales pour la réussite du projet. Il est important de faire entendre sa parole et de convaincre ses interlocuteurs avec des arguments factuels et concrets.

Et surtout il faut construire sa crédibilité auprès des autres acteurs. Cela peut prendre des semaines, voir des mois pour la construire mais quelques minutes suffisent pour la détruire. Ce qui implique d’être aussi factuel que possible dans les documents, comités et autres rapports avec les autres acteurs.

Les différents types de test

2008-09-23T23:47:00.013+02:00

Ci-dessous la liste des types de tests pouvant être mis en œuvre par une équipe de recette. J’aborderai cet article par le biais des fameuses « boites blanches et noires ».

1.1- Boite blanche

Test de type « boîte blanche » ou test structurel : visibilité du composant sous test, les jeux de test sont produits en analysant le code source. Les tests de type « boites blanches » sont qualifiés ainsi car on doit lire / entrer dans le code pour concevoir et exécuter les tests (ou autrement désigné comme « mettre les mains dans le cambouis »).

Quelques exemples de tests « boite blanche » : tous les chemins ont été parcourus au moins une fois, les conditions vrai / faux ont été validées, les boucles sont exécutées correctement. Mais aussi les valeurs limites sont correctement définies, les structures de données internes sont valides et s’il n’y a pas de fuite de mémoire, etc.

1.1.1- Revue de code

La revue de code est un examen systématique du code source d'un logiciel, l’objectif est de trouver des anomalies pour faire corriger les erreurs de conception afin d'améliorer la qualité et la sécurité du logiciel.

Il s’agit donc de relire le code, ce qui implique de passer en revue des milliers de lignes en Java ou en C par exemple. Pour ce faire il existe de nombreux outils permettant de le faire de manière quasi automatisée.

Ainsi, on insère dans l’outil les normes de codages et leurs gestions. Puis, l’outil parse, (langage métiers décrivant l’activité de passer en revue des lignes de code par exemple), les applications pour afficher un rapport mettant en évidence les anomalies.

La revue de code devient de plus en plus une étape à part entière dans tout processus de développement logiciel et y compris dans les méthodes dites agiles comme l'Extreme programming.

Des exemples type d’activités lors d’une revue de code peuvent être la vérification des règles de programmation ou bien la vérification de la conformité du code par rapport au document de conception technique détaillée.

1.1.2- Tests Unitaires

Ils testent indépendamment les différents éléments qui composent le système ou une portion d’un programme.

Ils sont mis en œuvre pour démontrer que chaque module (classe, boucle, etc.) effectue toute la fonction prévue et seulement cette fonction. On peut distinguer dans ces tests unitaires les tests de logique (recherche d'erreur, vérification de l'enchaînement correct des branches parcourues). Ainsi que les tests de calcul (vérification des résultats des calculs, des performances, de l'exactitude des algorithmes).

L’outil le plus répandu pour exécuter les tests unitaires est Junit (en contexte Java).

1.1.3- Tests d’intégration – avec “vision développeur”

Ils testent les différents éléments qui composent le système et leurs interactions entre eux.
Ils sont mis en œuvre pour démontrer que chaque module (classe, boucle, etc.) effectue toute la fonction prévue et seulement cette fonction.

Figure : Tests d'intégration

1.1.4- Tests de charges

Pour commencer il faut savoir qu’il y a toujours plusieurs significations dans « tests de charges » pour les clients ou les consultants. Selon les personnes la définition change. C’est pourquoi ils sont listés afin d’apporter des éclaircissements.

Lors des tests de performance (temps de réponse, durée de traitement) il faut vérifier que les performances du logiciel sont conformes aux exigences dans différentes conditions (mode normal ou dégradé) :
Exemple : s’il est prévu qu’un site Web soit consulté simultanément par 500 utilisateurs, les pages doivent s’afficher en moins de 2 secondes.

Lors des tests de charge il s’agit de mesurer le comportement du système et de ses limites face à un environnement d’exploitation limite en simulant plusieurs sessions simultanées et / ou une volumétrie de données pour contrôler le maintien des performances.

Les tests de surcharge on pour but d’appréhender le fonctionnement et les défaillances du système en cas de surcharge (au-delà des limites de charge).

Les tests avec un système en mode dégradé vérifie la stabilité du système : réaction en dehors des cas normaux d’utilisation (doublons, fichier vide, sélection vide, format de saisie erronée…).

Mes retours d’expériences montrent que 100% du temps les tests de charge sont assimilés à des tests de performances. Ceux-ci sont décrits ci-dessous.

D’une façon générale les tests de performances et de charges permettent de répondre à un certain nombre de questions comme « quels sont les risques de problèmes de performances en production ? », « est-ce que les applications et l’infrastructure supportent le nombre d’utilisateurs attendus ? », « comment mesurer la charge/qualité de service rendu en rapport avec les moyens et les objectifs ? », ou bien « les temps de réponse de l’application pour les n utilisateurs simultanés sont-ils conformes au cahier des charges ? ».

Les tests de charges peuvent s’effectuer à plusieurs moments du cycle de vie des projets comme :
au début du projet pour analyser le comportement d’une solution envisagée : progiciel à intégrer, prototype, afin d’identifier les limites de la solution, les problèmes potentiels de charge et de dimensionner les architectures matérielles en fonction de la charge évaluée dans le temps (capacity planning), en cours de projet pour tester le comportement dynamique de la solution en fabrication sur les problèmes d’inter-blocage, de consommation de ressources et de gestion mémoire, en fin de projet pour valider la solution définitive, pour vérifier ses caractéristiques de performance et identifier la capacité réelle et les comportements face à la montée en charge et aux pics d’utilisation. Ces tests permettent aussi d’optimiser l’architecture finale en ajustant les paramètres systèmes, en enfin en phase de maintenance, pour vérifier la non-régression des caractéristiques de performance de la solution et identifier sa capacité et ses comportements face à l’évolution des montées en charge et des pics d’utilisation.

Un processus typique de tests de charge comporte quatre à cinq phases avec des pré-requis à vérifier.

Les pré-requis à vérifier concerne la campagne de test de charge, qui n’est réalisable que sur la base d’une application stable et validée lors d’une phase de recette fonctionnelle et technique préliminaire.

Avant d’effectuer les tests de performance de l’application, les opérations suivantes doivent être effectuées et validées : la machine doit être disponible avec fourniture d’un accès (utilisateur / mot de passe), générique ou pas, sur l’environnement applicatif et logiciels (NT, Oracle, autorisations réseaux, etc.), l’application installée et disponible (techniquement, fonctionnellement et sur le plan de l’intégration et recette) avec fourniture d’un accès (utilisateur / mot de passe) et de jeu de données. Mais il faut également avoir une application en état de marche et stable, dans une configuration iso-production de préférence et/ou proche de la réalité et les liens avec les autres applications en état de marche et disponibles.

La nature et le volume de données présentes en base doivent être identiques et/ou proche de la production. De plus l’application doit être accessible depuis la plate-forme de test de charge.

Les quatre phases classiques lors des tests sont :

1- Pré-étude et lancement :

La première étape avant toute utilisation d’un outil (LoadRunner de HP Mercury par exemple) consiste à réaliser une phase de préparation. Cette phase est découpée en plusieurs étapes qui sont une réunion d’Initialisation / Cadrage et la livraison du cahier de test de la campagne.

2- Préparation des tests et développement des Scénarios :

Cette étape porte sur les éléments à installer afin de constituer l'environnement de test.

La phase de développement concerne la construction des scripts de tests et des scénarios spécifiés lors de la phase précédente. Cette phase se décompose de la façon suivante :

enregistrement des scripts,
paramétrage des scripts,
validation des scripts par les MOE / MOA (parfois),
rodage des scripts,
étalonnage des scripts.

3- Campagne de tests : Exécution - Analyse, Rapport – Synthèse, Correction, Test de confirmation :

Cette phase est un processus itératif qui permet d’exécuter des scénarios et d’analyser les résultats. Elle se décompose comme suit : Création du scénario de test, Tir et collecte de métriques et analyse des résultats.

4- Bilan :

Au final, les résultats décrivent les tests, l’analyse, les améliorations de l’application et le statut des objectifs. Ce rapport est généré après l’exécution de l’ensemble des tests.

Le cycle de test peut être itéré plusieurs fois pour prendre en compte les évolutions du système.

1.1.5- Tests de sécurité

Avec l’arrivée des applications de type Web se sont développé des tests de sécurité. Il s‘agit de vérifier la sécurité des systèmes : cryptage des données, tests d’authentification, habilitations, intégrité des données, accessibilité, accès concurrents…

1.1.6- Tests d’exploitabilité

Les tests d’exploitabilité ou Vérification A la Bonne Exploitabilité (VABE) sont des tests qui contrôlent les exigences d’architecture technique. Ci-après un exemple avec l’illustration dans le monde des telecom français :

On comprend dans le schéma ci-dessous que les scénarios de test d’exploitabilité débutent au téléphone mobile d’un client pour finir à l’entrée du S.I. du fournisseur d’accès. En passant par toutes les couches réseaux, supervisions, etc.

Il y a également parfois des tests de performance qui sont exécutés.

1- Types de test
Figure : Périmètre des tests d'exploitabilité chez un opérateur telecom français

Figure (illustration à venir) : Activités de test de type exploitabilité chez un opérateur telecom français.

Quelques autres exemples de test faisant partie de ceux d’exploitabilité :

analyse du dossier d’exploitation,
mise en place de la configuration plate forme, configuration ordonnancement JCL,
vérifier le respect des normes d’exploitation,
la mise en place de l'ordonnancement des Job et flux de données,
la supervision (Unix Tivoli, MVS Autosys),
scénario de chronologie,
jeu de donnée batch, cas d'alerte,
simulation des dossiers d'exploitation, message d'alerte, log,
vérification des logs,
tests de sauvegarde, restauration, chaud, froid, incrémentale, hebdo, etc.

Ce type de test aborde de très nombreuses particularités et sera le sujet d’un prochain article.

1.2- Boite noires

Les tests de type « boîte noire » ou test fonctionnel ne demande pas de visibilité du composant. Les entrées et les résultats attendus sont exprimés en termes de comportement du composant logiciel d’un point de vue externe, sans se soucier de la structure interne du composant.

Les tests boîte noire sont liés aux spécifications fonctionnelles. Indépendamment de la structure interne de l’application (contrairement aux tests boîte blanche), ils valident les fonctionnalités de l’application. Comme le fonctionnement interne de l’application n’est pas connu, le concepteur de jeux de test doit définir le comportement attendu (Résultat Attendu - RA) et vérifier si l’application est conforme à ce comportement (Résultat Obtenu - RO).

Les tests de type boîte noire sont des tests fonctionnels mis en œuvre dans la phase de recette, ils ont pour objectifs de rechercher ou de valider le respect des exigences, les fonctions incorrectes ou manquantes. Mais aussi les incohérences au niveau de l’interface, les erreurs d’accès aux données et enfin les conditions initiales ou finales d’une fonction.

1.2.1- Tests fonctionnels

La recette fonctionnelle (plus simplement appelée recette) consiste à réceptionner un logiciel développé et à en vérifier le bon fonctionnement avant sa mise en service ainsi que sa conformité par rapport à ce qui a été demandé dans le cahier des charges.

Les tests de recette fonctionnelle vérifient que le logiciel fonctionne de manière adéquate dans le cadre des activités-métier des utilisateurs pendant la recette fonctionnelle, on n'examine pas la programmation du logiciel, mais son comportement fonctionnel et son ergonomie (IHM et navigation) ainsi que le ou les cahiers des charges (et le cas échéant d'autres supports tels que manuels utilisateur, modélisation des données…).

Les tests conduisent à simuler le fonctionnement du logiciel au travers de cas d’utilisation. Il est nécessaire de disposer de cas concrets du domaine d’application et de données pour simuler un contexte réel d’utilisation (jeux de données, environnement de test).
Les tests vérifient les aspects du métier (fonction métier) avec les fonctionnalités non conformes ou manquantes et le fonctionnement des règles de gestion.

Les tests fonctionnels prennent aussi en compte l'ergonomie. Il s’agit des comportements utilisateurs (valeurs limites, valeurs non autorisées...), de la réalisation et la présentation des écrans ou des règles de navigation, etc.

1.2.2- Tests de non régression

Après une correction ou une évolution, que faut-il re-tester pour s'assurer que la modification n'a pas dégradé (fait régresser) le fonctionnement du logiciel et provoqué des anomalies sur d’autres modules non testé ?
Tout re-tester serait trop coûteux et ne tester que les modifications du composant impliquerai de nombreux risques.

Il faut donc trouver un compromis et définir une stratégie de non régression (ou TNR). Ces tests de non régressions doivent être prévus après toute modification d'un logiciel afin de vérifier que les fonctionnalités existantes n'ont pas été altérées par les modifications apportées. Il est en effet indispensable que l'existant continue à fonctionner avec le même niveau de qualité que sur la version précédente.

Pratiquer un test de non régression signifie que le reste de l’application n’a pas perdu en fonctionnalité ou en fiabilité du fait de l’ajout de nouvelles fonctions ou de modification des fonctions existantes. Ils consistent à déterminer si des défauts ont été introduits dans l’application lors de l’implémentation de la nouvelle fonctionnalité. Ils peuvent également être employés lors de changements survenus dans l’environnement de l’application.

Les tests de non régression sont applicables à toutes les phases de test. En effet, la prédiction des erreurs permet de déterminer la portée et l’étendue des tests et de s’assurer de l’état du système modifié.

Si les tests de non régression accompagnent les différentes étapes du cycle en V, ils conviennent particulièrement aux dernières étapes. Ainsi, ils sont habituellement effectués dans le cadre de tests système de recette ou d’intégration.

Figure : Illustration de ce que sont les Tests de Non Régression

Tout système d’information est en perpétuel évolution. Or si chaque nouvelle modification est validée elle ne l’est pas nécessairement dans l’ensemble de l’application dans laquelle elle intervient. Il en résulte des anomalies, parfois bloquantes (ou effet papillon). Les tests de non régression (souvent outillé) permettent d’augmenter la couverture des tests, d’industrialiser les tests, de diminuer les charges de tests et enfin d’optimiser les temps d’exécution.

Exemple – ARIANE 501

Le 4 juin 1996 lancement d’ARIANE 501 et quelques secondes après le lancement l’auto destruction est prononcée. Fin d’ARIANE 501 (environ 500 M€).

Pourquoi ?
Après analyse il s’avère que des mauvais choix ont été effectués lors de la définition de la stratégie des tests de non régressions. En effet, des composants d’ARIANE 4 ont été réutilisés mais non testés car « Ils fonctionnaient parfaitement avant ! ».

(Source IEEE Computer 01/97)

Exemple – MOE E_F projet xxx

1.2.3- Etude de cas pour illustration :
Enjeux stratégiques : Ouverture du marché en 2007 - assurer la montée en compétence de l’équipe – définir la méthodologie et outil dédié aux activités de recette
Réalisation : Audit des activités de recette de la MOE (fondamentaux projet, processus et moyens de recette sur VABF) > Préconisations > plan d’actions > Formations > Accompagnements chef de projet et analystes.
Gain client : Formation et accompagnement de ses équipes – professionnalisation des activités de recette – maîtrise accrue de la qualité – pilotage dédié à la recette – respect des engagements intégrateurs
Technologies : Portail – Progiciel L_r – Batch – Flux – Business Intelligence (B.O.)

Exposition du cas : Plus près de nous, en 2007, lors d’une mission de conseils chez E_F j’ai mis en place la stratégie de tests de non régression suivante.

Figure : Se situer dans les étapes de tests

Lors de la phase d’audit voici ce que j’ai préconisé : une stratégie en deux phases se situant lors de l’étape de conception des tests. Il s’agissait de former et faire monter en compétence l’équipe en charge des activités de recettes de la MOE sur les tests de non régressions. Pour ce faire il a fallu mettre en place une stratégie en 2 temps (appropriation progressive facilité) : une non régression manuelle et une non régression automatisée.

Non régression manuelle :
Il a fallu recueillir les plans de tests des autres acteurs comme le groupement (intégrateur type TMA) et de la MOA. Puis de rédiger ceux de la MOE collectant les informations :

des tests de non régression du groupement,
des tests de non régression de la MOA.

Il a fallu rédiger la synthèse et l’analyse des informations sur les conceptions des tests de non régressions MOE via des :

tests des fonctionnalités et flux primordiaux,
tests de l’IHM L_R (menu…),
tests des courbes de charge, graphiques, rapports.

Non régression automatisée :

Figure : Automatisation des tests de non régression – « Voie royale »

Une fois les tests de non régression manuelle bien avancés, on peut automatiser ces tests. En passant par une étude de 5 jours sur la faisabilité de cette automatisation.

Ensuite, (après choix des automates et validation du client), un projet dit « pilote » utilisant les plans de tests de non régressions rédigés en amont peuvent être défini et joué.

Puis, après la lecture et l’analyse des rapports de test cette phase d’automatisation a été validée.
Etat des lieux :

cellule MOE : aucun cahier de recette prévu pour les TNR – TNR joué « à la volée »,
cellule MOA : un cahier de recette avec 3 scénarios mais très incomplet,
équipe Métiers : aucun d’existant – TNR joué « à la volée ».

Après l’audit la stratégie de Tests de Non Régression (TNR) retenue a été de mettre en place un atelier. Puis, suite à l’atelier organisé avec les pilotes E_F et la cellule MOE la solution retenue a été d’utiliser les cahiers de recette de la MOA, de les enrichir et d’organiser des ateliers avec l’équipe Métiers pour finaliser les cahiers de recette de TNR.

En collaboration avec la cellule MOE nous avons dressé un tableau listant les avantages à mettre en place cette stratégie de TNR. Avantages pour les 3 équipes. Cette liste nous a aussi servi à communiquer / « vendre » les TNR aux diverses acteurs.

1.2.4- Tests d’intégration avec une logique « recetteurs »

Dans l'hypothèse de modifications apportées à au moins deux applications, il convient non seulement de tester chacune d'entre elles, mais aussi de vérifier que les communications (amont/aval) prévues fonctionnent toujours (ou, s'il s'agit d'une nouvelle relation, que celle-ci est opérationnelle).
Du point de vue de la méthode, la réalisation d'une recette d'intégration appelle des précisions sur chaque application modifiée qui doit faire au préalable l'objet d'une recette fonctionnelle : on parle alors couramment de recette fonctionnelle « unitaire » et les concepts de base exposés dans le guide sont applicables à ce cas particulier.
Puis il faut préciser la relation entre les applications, effectuée dans un second temps, introduit un niveau de complexité supplémentaire qui nécessite une organisation et une stratégie spécifiques (coordination, pilotage le cas échéant, plate-forme adaptée, …), voire la mise en place d'un outil de cadrage dédié, le « dossier de stratégie d'intégration ». Ce dernier permet de partager entre les différents acteurs de la recette les éléments clés du projet : contraintes (planning, ressources, objectifs), description de la plate-forme, cadencement des travaux, etc.
Enfin, le dossier de stratégie d’intégration doit contenir les scénarios et fiches de tests "partagés", nécessaires à la vérification de l'intégration, ainsi que le calendrier précis de leur passage. Les jeux d'essai communs doivent être constitués pour permettre la vérification de la chaîne.

Ils consistent à assembler plusieurs unités et à tester les erreurs liées aux interactions entre ces unités (et éventuellement à détecter les erreurs rémanentes non détectés au niveau unitaire).

1.2.5- Particularité des tests de progiciel

Les tests de progiciel comme les ERP (ou PGI) sont particuliers car faisant partie des tests les plus complexes à mettre en œuvre. Ceci pour les raisons suivantes comme le besoin d’identification des exigences, des objets métier et des règles de gestion. Comme l’analyse d’impact d’une version à l’autre, les tests récurrents, le besoin de tests de non régression ou l’interfaçage avec le SI existant.
Mais complexe également car il y a de nombreux développement spécifique, des migrations / reprise des données du SI historique vers le progiciel, des problématiques de volumétrie, des plates-formes propriétaire plus ou moins ouverte.
La complexité est également due à la richesse fonctionnelle poussée (processus métier prédéfinis et adaptés au métier), un paramétrage spécifique ou bien des développements complémentaires pour chaque société, un processus de développement hors norme.

Parfois même, la complexité provient des différenciations à faire entre le standard et le spécifique. Ceci au niveau des développements et des tests. En effet, les développements standards font souvent partie d’une enveloppe déjà définie avec le client, alors que les développements et tests spécifiques sont sujets à des avenants au contrat.

Enfin, la complexité des tests de progiciel est due aux problématiques de gestion des flux inter-applicatifs, aux problématiques de gestion de configuration et des difficultés de la maîtrise des jeux de données.

Hormis les problèmes évoqués ci-dessus il y a également ceux liés à la conception des scénarios et de leurs exhaustivités. Ci-dessous un exemple de scénario suivant la logique d’un « utilisateur final ».

Figure : Exemple d’un scénario de test d'un module R/3

Les tests de progiciel sont donc complexes et ils demandent aux équipes une première expérience sur un des modules de l’ERP cible.

Prenons pour illustrer un exemple tiré d’une mission aux chez un assureur sur un module SAP Financier. La démarche mise en place pour spécifier et préparer les tests a été la suivante: il a fallu procéder à l’identification des processus principaux (métier et applicatifs) et des scénarios de tests associés, puis identifier les règles de gestion, étudier les messages impactant et identifier les transactions SAP (ou ordre de transport) par flux et processus (étude des processus et prototypes élaborés lors de la conception de l’application).
Ensuite il a fallu spécifier les scénarios de tests et les fiches de tests, rapprocher les scénarios SAP fournis en standard avec la méthodologie ASAP (méthodologie de test light propre à SAP), définir les scénarios retenus et spécifier les cas de test.
Enfin, il a fallu analyser la couverture des tests via la matrice des cas de test et analyser et spécifier les jeux de données nécessaires.

Je développerai dans un prochain article la stratégie à adopter pour mener à bien des tests sur de l'ERP.

Concrètement qu’est-ce que la non-qualité ?

2008-09-23T23:41:00.005+02:00

Qu’est-ce que la Non-qualité ?

L’opposé de la qualité est la non-qualité. Cette « Lapalissade » tente d’expliquer que mesurer le niveau de qualité d’une application passe par renseigner les indicateurs mesurant la non-qualité. Soit par exemple : mesurer le nombre d’anomalies détectées en phase de tests ou en production.

Au-delà d’obtenir des mesures abscondes mais fort pertinentes pour les équipes des acteurs techniques d’un projet (MOE / développeurs / testeurs, etc.) et qui en sont friands, ces mesures permettent surtout de communiquer vers les clients, un département achat ou un DSI avec des chiffres évocateurs. Et autant que possible dans un langage clair et compréhensible.

Cela permet d’adresser ces acteurs avec un langage concret (en espèces sonnantes et trébuchantes) et d’assurer une certaine pédagogie à leurs égards. Comme par exemple leur démontrer ce que coûte réellement un dossier incomplet, un produit défectueux ou mettre en évidence le coût de la perte d’un client. Autant d’arguments forts parlants.

Ces anomalies (indicateurs majeures de mesure) ont toutes un coût.

Coût de la non-qualité

Les coûts de non-qualité correspondent aux frais résultants lorsque le produit ne satisfait pas aux exigences de qualité avant et après avoir quitté l’entreprise. Il y a donc ceux liés au dysfonctionnement interne, comme les rebuts, retouches et multiples essais. Et ceux qui correspondent aux défaillances externes : indemnités, reprise marchandises (voir illustration ci-dessous).

Trois éléments fondamentaux sont à prendre en compte comme les coûts d’obtention de la qualité, les coûts de non qualité directs constituant des charges supplémentaires et enfin les coûts indirects liés à la perte de clientèle donc à la perte de chiffre d’affaire.

Et dans chacun des trois éléments voici les points à passer en revue :

Figure : Coûts selon la norme AFNOR NF X50-126

Coûts des anomalies internes : il s’agit des coûts générés quand le produit ne satisfait pas aux exigences exprimées (oublis dans les spécifications, mauvais processus…).

Coûts des anomalies externes : il s‘agit des coûts générés quand le produit ne répond pas aux exigences de qualité après avoir quitté l’entreprise (garantie, réclamation, pénalités de retard…).

Coûts de détection des anomalies : il s’agit des coûts liés aux équipes de recette, des moyens de tests mis en œuvre (outils & automates), les charges et salaires des équipes, etc.

Coûts de prévention des anomalies : ces coûts concernent les investissements en ressources humaines et techniques engagés pour vérifier, prévenir et réduire les anomalies (audit interne et externe, maintenance préventive…).

Mais aussi des missions de conseils en amont et en aval des projets qui permettent d’optimiser et prévenir les anomalies.

Coûts liés à la perte de crédibilité : si l’image de marque d’une entreprise est entachée auprès de ses clients il y a un impact certain sur le chiffre d’affaires, mais aussi auprès des salariés et des actionnaires.

Quelques exemples de coût dû à la non-qualité dans les secteurs Banques / Assurances

Quelques exemples de non-qualité due à des problèmes lors de la phase de conception.

Origine de la non-qualité 1 : cela concerne un sur ou un sous dimensionnement des ressources technique.
Exemple avec des offres de prêts ne pouvant être envoyées dans des délais raisonnables en raison du sous-dimensionnement de l’outil informatique. En effet, si les plateformes, les bases de données ou même des requêtes SQL ne sont pas optimisées cela peux engendrer des calculs très long et par conséquent entraîner des retards d’envoi d’offre des prêts.

Les conséquences peuvent être des demandes client non satisfaites, le client va à la concurrence. Ce qui impliquera des types de coûts comme la perte de chiffre d’affaire, du temps dépensé en back-office pour traiter un dossier qui n’aboutit pas ou des dédommagements client en cas de retard de versement des fonds.

Origine de la non-qualité 2 : non respect de la réglementation.
Exemple comme le non respect de la Loi Scrivener impliquant la non prise en compte du délai de rétractation légale.

La conséquence possible est le développement d’un produit non autorisé à la vente. Ce qui implique des types de coûts induits comme la documentation erronée à détruire et des pertes de temps.

Exemples de calculs de coûts de non-qualité

Voici un exemple de calcul de coût d’obtention de la qualité. Cela peut se résumer à ce qu’il aurait fallu faire en amont pour éviter (prévention) les coûts de non qualité (sur la base des exemples du chapitre 4.3.2) :
spécification précise des besoins « métier » par la maîtrise d’ouvrage :
= 20 JH = 450€ * 20 = 9 000€
développements informatiques nécessaires :
= 60 JH = 450€ * 60 = 27 000€
audits réguliers de vérification / Tests :
= 20JH = 450€ * 20 = 9 000€
TOTAL = 45 000 €

Coût de la non qualité :
Recherche des causes et identification de la cause (terrain, audits, services techniques, productivité) = 216 JH
Ajustements tarifaires (actuariat, nouvelles instructions et déploiement) = 62 JH
Récupération des départs, campagne de communication, « ristournes » = 5 JH + 20K€ + 20K€
Audits de vérification de bonne application des nouvelles instructions = 20JH

Soit (216 + 62 + 5 + 20) X 450€ + 40 000€

Donc un TOTAL =176 350 €

S’y ajoutent les coûts potentiels tels que la perte de CA, les parts de marché, etc.

Au final on s’aperçoit que le coût de la non-qualité représente trois fois les coûts d’obtention de la qualité (45 000€) !

Sensibilisation à la recette

2008-09-23T23:40:00.004+02:00

Sensibilisation à la recette

Il s’agit ici de présenter de manière synthétique et rapide ce que sont les tests et pourquoi tester. Je commencerai par la définition de « génie logiciel ».

Définitions : Génie logiciel

Le Génie Logiciel ou GL est un domaine relativement récent : la première conférence sur le thème du GL eut lieu en 1969 lors de la conférence de l'OTAN. D’ailleurs la citation suivante en est extraite : « Le génie logiciel est l'élaboration et l'utilisation de principes de génie permettant de produire économiquement des logiciels fiables, et qui fonctionnent de façon efficace sur des machines réelle » : Naur & Randell (eds), Software Engineering : A Report on a Conference sponsored by NATO Science Committee, NATO, 1969.

Donc, le génie logiciel touche au cycle de vie des logiciels. Toutes les phases de la création d'un logiciel y sont enseignées : l'analyse du besoin, l'élaboration des spécifications (fonctionnelle et technique), le développement, la phase de test et finalement la maintenance. La prise en compte des tests suivant une méthodologie (artisanale certes) et la qualité des logiciels ont débuté à cette époque.

Quelques définitions :

" Application pratique de la connaissance scientifique dans la conception et l'élaboration de programmes informatiques et de la documentation associée nécessaire pour les développer, les mettre en œuvre et les maintenir » (B. W. Boehm, 1976),
« Ensemble des activités de conception et de mise en œuvre des produits et des procédures tendant à rationaliser la production du logiciel et son suivi » (Arrêté ministériel du 30-12-83).

Définitions : Qualité / tests

La qualité d'un logiciel est son aptitude à satisfaire les besoins (exprimés ou potentiels) des utilisateurs (Martin, J.P., 1987).

Le développement logiciel est une activité humaine qui introduit des défauts à toutes les étapes du processus et notamment lors des activités de tests et vérification, les défauts se propagent, produisent d'autres défauts et sont livrés aux clients. Le développement logiciel devient aussi une activité massivement collective et implique des problématiques complexes comme le partage de tâches qui nécessite un ajustement entre les différentes personnes et points de vue ou bien la compression des délais et l'imperfection de la communication, l'éloignement géographique ne permettent pas l'ajustement, la probabilité d'introduction des défauts augmente. (Bug Mars explorer : pas le même système de mesure).

L'élaboration du logiciel est une activité itérative et la communication écrite joue un grand rôle, mais la taille et le nombre des documents ne permet pas une maîtrise individuelle. La désynchronisation de la mise à jour des documents de référence par rapports aux décisions peut générer des anomalies, de même que le manque de synchronisation est source de nombreuses erreurs notamment aux niveaux des interfaces. Enfin, les revues et les tests sont des moyens de resynchronisation des références.

Les facteurs aggravants sont la taille et la complexité grandissante des applications, la taille des équipes. Mais aussi, un changement des technologies et la pression des délais ou bien la répartition géographique avec des équipes réparties sur divers continents. Et par conséquent un choc de culture et de langue.

Comme on peut le voir le développement logiciel est complexe et peut générer à toutes les étapes des anomalies.

(illustration à venir)

L’illustration ci-dessus est un exemple de progression du taux d’erreurs (en production) pour 1000 lignes de code développées. Plus le nombre de ligne augmente, plus les erreurs sont nombreuses.

Quelques sources :

un programmeur expérimenté injecte 1 défaut chaque 10 lignes de code soit 100 défauts par KLOC (kilo line of code),
après intégration et validation, il reste 5 à 10 défauts par KLOC (Source : Bugs or defects Watts S. Humphrey SEI interactive, March 1999).

La vérification du logiciel a pour but de démontrer que les produits logiciels issus d'une phase du cycle de développement sont conformes aux spécifications (incluant les exigences légales et réglementaires) établies lors des phases précédentes.
Elle a également pour but de détecter et de rendre compte des fautes qui peuvent avoir été introduites au cours des phases précédant la vérification.

Les tests (ou recette) servent à détecter d’éventuels écarts entre le comportement attendu et le comportement observé au cours des tests, ce qui élimine un grand nombre de fautes présentes dans le logiciel.
Les tests permettent également de s’assurer du niveau de qualité d’une application.
Enfin ils permettent d’obtenir la confiance nécessaire avant l'utilisation opérationnelle (il faut cependant noter que le nombre de fautes détectées ne peut pas être considéré comme un critère de réussite des tests. Le retour d'expérience montre en effet qu'à complexité technique et industrielle constante, un grand nombre d'erreurs détectées par rapport à d’autres projets « de référence » peut seulement être interprété comme l'indicateur d'un logiciel contenant un très grand nombre de fautes et non comme l'atteinte d'un bon taux de détection des fautes présentes).

Il est donc très difficile d'avoir confiance en un logiciel ayant un grand nombre de fautes détectées par le test.
Il existe un risque pour le concepteur de faire définir par une même entité (individu, équipe), la spécification, la conception, la stratégie de tests et les cas de tests. Ce qui implique donc « qu’on ne peut être juge et partie ».
La signification de cette expression dans le milieu des tests exprime le fait qu’une équipe de développeurs n’est pas la plus à même d’assurer les développements d’une application et de la tester. Deux raisons au moins justifient le recours à un tiers pour tester un logiciel. La première raison est que le but des tests est d’exécuter un programme avec l’intention de trouver ses erreurs, ce qui constitue un processus mental non naturel pour son auteur, difficile à mener par une même entité.
La deuxième raison est que le programme peut donc contenir des erreurs dues à la non compréhension de l’implémentation ou des spécifications par le développeur. Dans ce cas, il est probable que celui-ci aura ces mêmes « non compréhensions » quand il testera son propre programme (mode commun de défaillance).

La correction des fautes logicielles peut injecter de nouvelles fautes et perturber des parties correctes déjà testées, mais aussi rendre active une partie du logiciel jusqu'alors inaccessible et donc révéler un grand nombre de nouvelles fautes, qui ne pouvaient être constatées avant cette correction.

Maintenant que disent les livres ?

« Le test n’est pas une science exacte. Il fait appel au bon sens autant qu’à la haute technologie » (Maurice Rozenberg – Tests Logiciel).

« Le test est l’exécution ou l’évaluation d’un système ou d’un composant, par des moyens automatiques ou manuels, pour vérifier qu’il répond à ses spécifications ou identifier les différences entre les résultats attendus et les résultats obtenus » (version de l’IEEE).

« Le test est une technique de contrôle consistant à s’assurer au moyen de son exécution, que le comportement d’un programme est conforme à des données pré-établies » (selon AFCIQ).

Ces définitions officielles de ce que sont les tests sont toutes vraies mais sont également complémentaires. Chacune de ces définitions aborde un point spécifique des activités de qualification prenant place au sein d’un projet de qualification.

Maurice Rozenberg nous explique que le test doit allier savoir-faire et connaissance technologique. L’IEEE et l’AFCIQ abordent le sujet en posant comme fondamental que le test (outillé ou pas) est la mesure de l’écart entre les spécifications des utilisateurs (expressions des besoins ou équivalent) et les résultats obtenus.

En fait, la phase de test / qualification / recette est un projet à part entière au sein d’un projet global lié à une application (création, évolution, correction) qui prends sa place dans l’écosystème informatique d’une ou plusieurs entreprises. Pour ce faire nous devons prendre suffisamment de recul.

« Penser globalement et agir localement !»

Ce credo doit être en tête de tous les chefs de projet de qualification car penser que les tests ne débutent seulement qu’après les développements est déjà une grave erreur et hypothèque fortement la suite du projet de qualification.

Pour finir citons le Génie Logiciel : « Dire d'un logiciel qu'il est de qualité sous-entend qu'on puisse lui appliquer certains critères comme l’adéquation aux besoins, la fiabilité, l'efficacité et l'évolutivité. »

Dans la pratique, il s’agit de tester le logiciel suivant une méthodologie définie avec des outils et automates adéquats.

Le pendant de la qualité est la non-qualité. C’est ce qui sera abordé dans le prochain article.

Awareness to the testing

2008-09-23T23:26:00.004+02:00

DEFINITIONS: ENGINEERING SOFTWARE

The Software Engineering or GL is a relatively recent: the first conference on GL took place in 1969 during the NATO conference. Besides the following quotation is taken: "The software engineering is the development and use of engineering principles to economically produce reliable software, and operate effectively on machines real" Naur & Randell ( eds), Software Engineering: A Report on a Conference sponsored by NATO Science Committee, NATO, 1969.

So, the software engineering touches the life cycle of software. All phases of creating software are taught: analysis of needs / requirements, development of specifications (functional and technical), development, testing phase and finally “production”. The inclusion of tests following a methodology (admittedly craft) and the quality of software began at that time.

Some definitions:
• "Practical application of scientific knowledge in the design and development of software and related documentation required to develop, implement and maintain" (BW Boehm, 1976),
• "All the design and implementation of products and processes to streamline production software and its follow-up" (Order of 30-12-83).

DEFINITIONS: QUALITY TESTS

“The quality of software is its ability to respect the needs / requirements (expressed or potential) users (Martin, JP, 1987). “

Software development is a human activity introduces defects at all stages of the process and especially when the activities of testing and verification, defects propagate, produce and other defects are delivered to customers. Software development is also a massive collective and involves complex issues such as sharing of tasks that requires an adjustment between different people and points of view or the compression of time and the imperfection of communication, geographical distance does not the adjustment, the likelihood of introduction of defects increases. (Bug from “Mars exploration”: not the same system of measurement).

The software development is an iterative and written communication plays a major role, but the size and number of documents does not allow individual ownership. Desynchronization of the updated reference documents in relation to decisions can generate anomalies, as well as the lack of synchronization is the source of many errors especially at interfaces. Finally, journals and tests are ways resynchronization references.

The aggravating factors are the size and complexity of applications and the size of the teams. But also, changing technologies and the pressure of time or geographical distribution with teams spread over various continents. And therefore a clash of culture and language.

As you can see the software is complex and can generate at all stages of anomalies.

Increase the rate of errors in production for 1000 lines of source code

The illustration above is an example of progress in the rate of errors (in production) to 1000 lines of code developed. The more line increases, the mistakes are numerous.

Some sources:
• an experienced programmer injects 1 defect every 10 lines of code or 100 defects per KLOC (kilo line of code)
• after integration and validation, it is 5 to 10 defects per KLOC (Source: Bugs or defects Watts S. Humphrey SEI Interactive, March 1999).

The audit software is designed to demonstrate that software products from a phase of the development cycle conform to specifications and requirements (including legal and regulatory requirements) established in previous phases.
It also aims to detect and report misconduct that may have been introduced in phases before the audit.

The tests are used to detect differences between the expected and observed behavior during testing, which eliminates many errors in the software.
The tests also make sure the quality level of an application.
Finally they can gain the confidence necessary before operational use (it should be noted that the number of detected faults can not be considered as a criterion for success of the tests. The feedback shows that indeed complex technical and industrial constant, a large number of errors compared to other projects "reference" can only be interpreted as an indicator of a software containing a large number of mistakes and not the achievement of a good detection rate of these mistakes).

It is very difficult to have confidence in software with a large number of faults detected by the test.
There is a risk for the designer to be defined by a single entity (individual, team), the specification, design, test strategy and test cases. This implies " we can not be judge and jury".
The meaning of this expression in the middle of testing expresses the fact that a team of developers is not the most likely to provide application development and test. At least two reasons justify the recourse to a third party to test software. The first reason is that the goal of testing is to run a program with the intention of finding mistakes, which is a mental process unnatural for its author, difficult to be carried out by a single entity.
The second reason is that the program may contain errors due to “misunderstanding” of the implementation or specifications by the developer. In this case, it is likely that it will be the same " misunderstanding " when he tested his own program (common mode of failure).

The correction of errors software can inject new mistakes and disturb the correct parties already tested, but also make active part of the software previously inaccessible and therefore reveal a large number of new faults, which could not be found before this correction.

Now that the books say?
"The test is not an exact science. It uses common sense as well as high technology "(Maurice Rozenberg - Tests Software).

"The test is implementation or evaluation of a system or component, through automatic or manual to see if it meets its specifications or identify differences between the outcomes and results" (version of the IEEE).

"The test is a technical inspection to ensure through its execution, that the behavior of a program complies with pre-established" (according AFCIQ).

These official definitions of what testing is all true but are also complementary. Each of these definitions reviews with a specific qualification activities taking place within a qualification project.

Maurice Rozenberg explains that the test must combine know-how and technological knowledge. The IEEE and AFCIQ address the topic by posing as a fundamental test (equipped or not) is the measure of the difference between the specifications of users (expressions of needs or equivalent) and results.

In fact, the test phase / qualifications / recipe (“recette” is the French professional term in testing!) is an integral part in a global project related to an application (creation, evolution, correction) that take place in the ecosystem for one or more . To do this we must take sufficient decline.

“Think globally, act locally!”

This belief must be at the forefront of all project leaders. Because, to believe “testing begins only after the developments “ is already a serious mistake and mortgage sharply the following of the qualification project.

Finally, for quote the Software Engineering: "Say a software package that is high-quality means we can apply certain criteria as to the adequacy at the requirements, reliability, efficiency and scalability."

In practice, it aims to test the software using a methodology with adequate tools and robots.

The other faces of the quality is none-quality. This will be addressed in the next article.