La certification ITIL V3 de l’intérieur…

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 !

Liens et sites

• ERP : cours de tests sur SAP… (ang.)
• ERP : livre sur les tests SAP (par SAP) (ang.)
• ERP : Tests de charges (fr.)
• ERP : vulgarisation (fr.)
• ERP : étapes clés d’un projet type (fr.)
• Les livrables du tests (ang.)
• Les tests et la Belgique (fr.)
• O&A : Outils et automates (ang.)
• O&A : Un blog autour de QuickTest Pro (ang.)
• O&A : IBM Rational Performance Tester (ang.)
• O&A : ROI des tests automatisés (ang.)
• O&A : tests de SGBD (ang.)
• O&A : Usine de test (Fr.)
• Qualité logicielle (Fr.)
• Une mine d’or d’outre Manche (ang.)
• Wikipedia à propos des tests (fr.)

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

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€) !

Littérature sur le monde des tests

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

Formation et cursus sur les tests

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

FITEC : Organisme de formation professionnel qui propose une formation de 25 à 40 jours sur la qualification / test (processus, projet, méthodes, outils HP Mercury : QC / QTP / DASHBOARD (formateurs de HP Mercury pour cette partie). c’est une formation reconnue dans le test, et soutenue par de nombreuses SSII (Criteres Testing, All4test, Steria, Alten, Dalysis, Systest, etc.) en DIF ou même via les ASSEDIC.

Mon avis : j’ai intégré de nombreux collaborateurs sortant de cette formation et elle est effectivement complète et la plupart des aspects des activités de test sont étudiés.

Sexe et tests !

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…

Liste de sociétés employant des testeurs

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…

Région parisienne :
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.
STERIA : SSII ayant plus de 300 testeurs (DP, CDP, analystes, etc.) et opérant principalement en Ile de France.
Criteres Testing : SSII et éditeur du site testissimo.com

Région française :
Astek
Dalysis
Keepcore
Qualife :  SSII œuvrant surtout dans le sud de la France
All4test

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

Anomalies, bugs et catastrophes !

FRANCE :
2007 / 2008 :

Octobre : Une panne empêche 15 % des abonnés SFR de téléphoner :

Trois installations informatiques d’un équipementier, des HLR (Home Location Ressource), qui sont tombées en panne, avec pour conséquence de bloquer la transmission des appels vers les numéros gérés par ces équipements.

(source : http://fr.news.yahoo.com/grp_test/20081007/ttc-une-panne-empeche-15-des-abonnes-sfr-549fc7d.html)

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 !

… c’est quoi les tests ?

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

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.