Dis tonton… comment on script avec un automate de tests et si tu pouvais aussi me donner quelques bonnes pratiques steuplé ?

1 12 2008

Hum… et tu ne veux pas non plus 100 euros et un Mars ? Bref, je te sens piaffer d’impatience alors écoute donc…

Je vais tenter de vous exposer comment les automates de tests fonctionnent. Je vais parler des QuickTests Pro (QTP) et autre Sélénium. Des automates utilisés pour les tests fonctionnels, les scénarios de tests utilisateurs, etc.

Il y a deux façons de scripter dans QTP, il y a la bonne et… la bonne !

Je m’explique car vous pourriez penser que je ne veuille faire qu’un rapide et stérile clin d’œil au sketch des Inconnus (à l’attention de nos amis anglophone : Inconnus = groupe de comique français des années 90).

Mais avant de passer en revue les façons de scripter demandons nous à quoi peuvent servir ces fameux automates qui pourraient être la solution miracle aux tests (ou pas…).

Théorie des automates de tests :

Sur un site Web (par exemple) QTP enregistre vos actions (enregistrement du mouvement de la souris, des clics de souris, etc.) et les rejoue à volonté. Vous pourrez ainsi exécuter à l’infini les scénarios de tests tout les soirs et, au matin, après votre café, compulser dans la tranquillité les rapports d’exécution.

Cette définition est un mythe urbain répandu par les éditeurs il y a quelques années lorsque les automates de tests étaient peu connus des clients. Depuis et jusqu’à ce jour, hélas, c’est toujours ce que pensent la plupart des clients…

Autres grands principes des automates de tests :

  • Les automates de tests fonctionnent par reconnaissance des objets des IHM (boutons, listes déroulantes, etc.) qu’il stocke dans un répertoire nommé parfois « repository »
  • En mode enregistrement, ils capturent les interactions réalisées sur des objets nécessaires lors du déroulement du scénario de test. Il génère un script en VB (pour QTP)
  • En mode exécution, ils rejouent le scénario de test à partir du script


Les automates de tests dans la vraie vie :

La seule partie vraie dans la définition théorique est « QTP enregistre vos actions et les rejoue à volonté » !

Le reste n’est possible que chez très peu de client ayant un niveau de maturité important dans l’automatisation des tests. Bref, il y a deux manières de scripter :

Le scripting par enregistrement et reworking :
– Le testeur dispose des IHM et scripte directement
– Il lance le script, relève les erreurs et les corrige
– Une fois son script terminée il doit le faire valider par un autre testeur et ainsi procéder à un cross-checking (notion très importante pour finaliser les scripts)

Le scripting en mode « programmation descriptive » et reworking :
– Le testeur ne dispose pas des IHM et doit donc travailler à partir de spécifications techniques et fonctionnelles. Mais cela est très rare chez les clients. De plus cela impliquerai que les spécifications sont déjà exhaustives, validées et stables… (il est bon de rire parfois ;- )
– Il lance le script, relève les erreurs et les corrige
– Cross-checking

Points importants à prendre en compte :
Principe : On automatise que sur une application STABLE et MATURE ! Sinon, c’est de la perte de temps et de l’onanisme pour Mammouth !
– Principe : 100% des tests manuels ne pas automatisable :

  • Il faut savoir prioriser, faire des choix intelligents, utilisation de la loi de Paretto
  • Étudier l’intérêt d’automatiser, etc.

– Principe : mener une étude de faisabilité pour déterminer l’intérêt d’automatiser les tests et la faisabilité technique (voir article sur le sujet)
– Retour sur investissement : des campagnes de tests automatisées ne sont rentables qu’à partir de trois, voir quatre itérations de campagne de tests automatiques (à partir d’une courbe de ROI sur trois ans)
– Création des scripts :

  • la charge de création des scripts est plus importante que la création des tests manuels
  • la difficulté n’est pas dans la capture du script mais dans le choix du critère et du moyen de contrôle du résultat attendu
  • il faut mettre des points de synchronisation ou d’attente entre deux actions pour éviter les times out sur l’apparition de résultat attendu
  • bonne pratique pour un scénario isolé (meilleure robustesse du scénario = se remettre dans les mêmes conditions que lors de l’enregistrement du script) :

– Préparation des environnements et application
– Génération des JDDT
– Tests de l’application
– Nettoyage des environnements et application

– Jeux De Données de Tests (JDDT) :

  • penser à générer les JDDT par l’automate avant l’exécution des scénarios

– Exécution des scripts : la charge d’exécution automatique est moins importante qu’une exécution manuelle
– Maintenance des scripts: la bonne méthodologie et les bonnes pratiques sont à appliquer avant le début de l’automatisation afin de minimiser les charges de maintenance des scripts (normes pour l’organisation, le nommage, la gestion des versions des scripts, etc.).
– Maintenance des scripts: il faut maintenir une compétence d’automatisation pour réaliser les adaptations, évolution des scripts en cas d’évolution de l’application

Je finirai en vous demandant de coupler TOUJOURS et autant que possible votre automate avec votre référentiel de tests ! Ce qui permettra, entre autre, de :
– Stocker la description des scénarios à automatiser
– Stocker les scripts QTP dans QC et les repository associés
– Planifier l’exécution des campagnes de tests automatiques
– Stocker les résultats des campagnes de tests

Publicités




Dis tonton… comment faire une étude de faisabilité avant d’automatiser mes tests ?

1 12 2008

Principe : mener une étude de faisabilité pour déterminer l’intérêt d’automatiser les tests et la faisabilité technique. Ci-dessous le sommaire type d’une étude, avec quelques indications pour vous aider à remplir ce document.

1- En tout premier lieu il faut valider les aspects techniques de l’automatisation : vérifier que l’automate peut se prêter d’un point de vue technique à l’automatisation de l’application (sur un échantillon de scénarios du lot à automatiser)

  • Utiliser les documents de pré-requis des automates

    2- Prononcer le GO / NOGO

    3- Procéder au Prototypage :

    – Identifier des scénarios représentatifs en utilisant des scénarios existant manuels :

    • Scénario de complexité « Simple
    • Scénario de complexité « Moyenne »
    • Scénario de complexité « Complexe »

    – Mise en place des scénarios dans Quality_Center_TESTLINK_Salome et QuickTests Pro_SELENIUM :

    • Automatisation des scénarios (exemple de critères de sélections des scénarios) :
    • Périmètre : automatiser sur des fonctions stables (test de non-régression et pas de tests automatique sur les évolutions)
    • Fréquence : automatiser les tests sur des fonctions à tester régulièrement
    • Criticité : automatiser les fonctions critiques
    • Estimer la durée de l’automatisation pour chaque scénario
    • Estimer l’exécution manuelle des scénarios (pour comparer les charges)
    • Estimer le coût de maintenance des scénarios en cas de montée de version

    – Dresser les prémices du ROI :

    – Identifier les « Best Practices » à implémenter

    • Librairie de fonctions de l’application, fonctions VB réutilisables, gestion des objets, etc.
    • Se reporter à l’article sur comment automatiser et les bonnes pratiques

    – Identifier le mode de gestion des jeux de données

    – Faire des préconisations sur la gestion des versions de scripts.

    Ci-dessous un petit exemple d’un rapport de faisabilité.

    Sommaire du document :

    • Objectifs de l’étude

    Client_xxx et votre_société on convenu de mener une étude de faisabilité afin de déterminer si une automatisation des campagnes de tests est possible.

    Ce qui pourrait permettre d’obtenir des gains de temps conséquent. Ainsi qu’une réutilisabilité par des tiers autre que les équipes votre_société.

    L’objectif de cette étude est donc de savoir :

    Quels sont les différents modules / parties automatisables ?

    Avec quels moyens (logiciels, outils) automatiser ces tests ?

    Les gains obtenus sont-ils significatifs ?

    • Comment avons-nous procédé ?

    Un premier choix a tout d’abord porté sur l’automate (QuickTests Pro_SELENIUM) au vue des contraintes et besoins de Client_xxx.

    Ensuite, à partir des scénarios présents dans (Quality_Center_TESTLINK_Salome) nous avons sélectionné quelques tests semblant significatifs.

    Puis nous les avons « Enregistré et scripté » à l’aide de l’automate.

    Pour illustrer le plus clairement possible les explications : la vidéo ci après montre un exemple concret d’automatisation de test pour l’application AAA, avec l’automate yyyy (nom de la fonctionnalité).

    L’automate teste automatiquement :

      1. Pas 1
      2. Pas n

    Joindre la vidéo de l’action de l’automate (outils existant sur Internet et gratuit).

    Il est important de prendre un exemple concret sinon l’impact auprès du client en sera amoindri et moins percutant.

    • Résultats de l’étude

    L’étude de faisabilité a montrée que :

    La plupart des applications sont compatibles avec l’outil d’automatisation xxx. Cette compatibilité a été vérifiée grâce au document « ddd », fourni en annexe.

    Une grande partie des scénarios sont automatisables par Selenium :

    · Le module « mmm1 », qui consiste à vérifier le bon fonctionnement de xxx

    · Le module « mmm2 »

    Les parties non automatisables concernent les échanges de flux entre les différents modules :

    · Batchs

    · Echange (problème de détection des objets par xxx), etc.





    …Quels sont ces fameux critères d’arrêts des tests ?

    20 10 2008

    C’est une question souvent abordée lors des formations aux tests, parfois posée par les clients et jamais abordée par les équipes de testeurs lors des projets ! Étrange n’est-ce pas ?

    Les critères d’arrêt des tests ne sont surtout pas à confondre avec la question « A-t-on assez testé ? ».  Car ceci est un autre sujet concernant la couverture des tests et leurs exhaustivité (entre autre).

    Définition des critères d’arrêt des tests pour ISTQB :
    « Critère de sortie : l’ensemble des conditions génériques et spécifiques, convenues avec les responsables, pour permettre de terminer officiellement un processus. L’objectif d’un critère de sortie est d’éviter qu’une tâche ne soit considérée comme achevée alors qu’il y a encore des parties de cette tâche qui n’ont pas été terminées. Les critères de sortie sont utilisés dans le test pour faire des comptes rendus et pour planifier l’arrêt du test. [D’après Gilb et Graham] ».

    Certes cette définition est peu claire, et c’est pourquoi je tente de lister les critères les plus fréquents :

    Critères d’arrêt commun à tous les types de tests :

    • Tous les scénarios (SCN) ont été exécutés (performance, fonctionnels, etc.)
    • Tous les dossiers, fiches et cas de test ont été joués avec succès
    • Toutes les anomalies critiques ont été résolues et les Tests de Non-Régressions (TNR) déroulés
    • Votre client à signer le PV de recette, le bilan présenté et il vous reste à ranger vos affaires
    • Après 252 livraisons l’intégrateur est incapable de corriger et le client décide d’arrêter le projet
    • Les plateformes, environnements, réseaux, etc. ne sont plus disponible
    • Atteinte du taux d’anomalie maximal découverte pendant les campagnes (définition et atteinte d’un seuil préalablement défini). Ce type de critère est souvent mis en œuvre chez les clients ayant un haut niveau de maturité des activités de test ou imposant des contraintes contractuelles très forte. Cela peut être également réparti par domaine fonctionnels. Exemple :
    • Arrêt des tests si détection de plus de 50 anomalies majeures
    • Épuisement des ressources des tests :
    • Fin du budget
    • Départ des ressources humaines
    • Fin de la durée / charge prévue
    • Véritable épuisement physique des ressources
    • Les SCN de recevabilité / testabilité / Pré-requis sont bloqués ou en NOK

    Critères spécifique à certains types de test :
    Techniques :

    • Tous les connecteurs et « jobs » (cela désigne : les jobs, jobstreams et les batchs) planifiés ont été lancés et tournent

    Lecteurs, si tu en connais d’autre je te propose de nous en faire part afin d’en faire dons à la communauté des testeurs et teuses. Merci.





    La certification ITIL V3 de l’intérieur…

    28 09 2008

    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 !





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

    27 09 2008

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





    … c’est quoi les tests ?

    27 09 2008
    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.