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

Publicités




Bonnes pratiques des référentiels de test

15 10 2008

Dis tonton, tu peux me donner quelques best practices steuplé ?
Les premières bonnes pratiques sont :

  • Bon sens,
  • Organisation,
  • Réflexions.

Rien de magiques mais qui, bien appliquées, seront les garants de la bonne utilisation d’un référentiel de test. Je vais les exposer sous forme de question à se poser aux bons moments :
Gestion des exigences ou requirements :

Unicité ?

  • Cette exigence est-elle la seule concernant ce point à tester ?

Clarté ?

  • Mener une réflexion sur l’arborescence à mettre en place,
  • Le besoin est-il exprimé suffisamment clairement et n’y a-t-il pas de zone d’ombre ou d’ambiguïtés sur la compréhension ?
  • Quelles sont les exigences implicites et non listé dans l’expression des besoins, (par exemple), mais dont on doit tout de même tenir compte ?

Précision ?

  • L’exigence est-elle suffisamment explicite pour être mesurable et quantifiable via des objectifs de test précis ?

Validité ?

  • Le document à l’origine de l’exigence est-il à jour et validé par le client ?

– Testabilité ?

  • Est-il possible de créer un ou des cas pertinents pour tester efficacement l’ensemble des aspects de cette exigence ?

Gestion du catalogue des fiches de test ou Test Plan :
Fondamentaux :

  • Chaque fiche de test doit-être reliée à une ou plusieurs exigences sinon vous pouvez dire adieu à la couverture de test
  • Une fois la fiche de tests rédigée une astuce est de vérifier si toutes les fiches sont reliées au moins une fois à une exigence, sinon vous avez des trous dans votre raquette !
  • En fonction de la stratégie définie, le Test Plan doit-être hiérarchisé selon les critères fonctionnels, métiers ou organisationnels du client

L’arborescence du plan de test doit :

  • Être facile à appréhender par des fonctionnels
  • Dans l’ordre des processus métier / applicatif du client (utiliser des codes numériques afin de gérer l’ordre des répertoires par exemple
  • Être déterminée au départ entre tous les acteurs
  • 4 à 5 niveaux MAXIMUM de répertoires sinon la folie vous guettera

Apporter un soin particulier aux onglets « Details » et « Design steps » :

  • Saisir une description claire par le commun des mortels pour le but de la fiche de test

Apporter un soin particulier à l’onglet « Design steps » :

  • Être suffisamment précis et détaillée, pour éviter toute ambiguité et autres interprétation au moment de l’exécution
  • Indiquer les données à utiliser ainsi que leurs provenances
  • Un STEP = UNE SEULE ACTION
  • Renseigner le résultat attendu (RA) de manière précise et clair car le résultat sera comparé au résultat obtenu (RO) lors de l’exécution

Les bonnes questions :
– Unicité ?
o Un objectif = une fiche de test
– Clarté ?
o Les différentes étapes du mode opératoire sont-elles clairement identifiées, n’y a-til pas de zone d’ombre ou d’ambigüités sur la marche à suivre ?
– Données ?
o Toutes les données représentatives nécessaires aux tests sont-elles identifiées ?

o Avoir des données qui soient :

– Cohérentes
– Précise
– Représentatives
– Préparées
– Couverture ?
o Le mode opératoire de la fiche de test est-il pertinent et complet pour l’objectif identifié ?
– Généricité ?
o Pas de fiche de test valorisée sauf si une valeur est en dur dans l’application à tester

Conception et exécutions des campagnes de test ou Test Lab :
– Disponibilités ?
o L’environnement permettant d’effectuer les tests est-il disponible ?
o L’application à tester est-elle installée avec la bonne version (politique de versionning du client) ?
o Les comptes d’accès (login / mots de passes) aux applications et autres serveurs sont-ils valides ?
– Préparation ?
o Les fiches de test sont-elles à jour ou datent-elles d’il y a un an ?
o Les scripts des tests automatisés sont-ils identifiées et dans les bons répertoires ?
– Clarté ?
o Les noms des campagnes et fiches de tests sont-ils assez explicites pour votre voisine de palier comprenne ?
– Données ?
o A-t’on toutes les données nécessaires pour exécuter les fiches ?
– Couverture ?
o L’ensemble de la campagne couvre-t’il l’objectif identifié ?

Bonnes pratiques pendant l’exécution des fiches de test :
– Avoir les environnements, plateformes et réseaux disponible
– Disponibilité de la machine à café effective
– Pendant l’exécution des steps :
o Suivre le mode opératoire contenu dans le champ « Description » à la LETTRE !
o Les tests hors des chemins balisés sont INTERDITS !
o Comparer le résultat obtenu (RO) avec celui du champ « Expected Result » (ou résultat attendu (RA)).

Gestion des anomalies ou Defects :
Fondamentaux :
– Avoir défini un workflow des anomalies qui soit connu, validé, partagé et clair. Ceci pour tous les acteurs
– Si oui, est-ce que tout les acteurs sont au courant de leurs rôles et responsabilités ?
– Si l’exécution produit un échec :
o Vérifier que le résultat attendu spécifié est exact
o Saisir le résultat obtenu le plus clairement possible
o Vérifier que l’anomalie est reproductible sinon l’intégrateur vous ridiculisera et ne prendra pas en compte l’anomalie
o Ouvrir une anomalie
o Décrire l’anomalie le plus CLAIREMENT possible sinon votre travail ne servira à rien et vous allez perdre beaucoup de temps en explication
o TOUJOURS associer à une fiche de test

– Reproductibilité ?
o L’anomalie constatée est-elle reproductible dans les mêmes conditions ?
– Conformité ?
o L’anomalie a-t-elle été détectée en suivant le mode opératoire inscrit dans la fiche de test ?
o Les résultats attendus inscrits dans la fiche sont-ils à jour ?
– Unicité ?
o L’anomalie détectée n’est-elle pas déjà ouverte ?
– Pour cela, questionner vos collègues et votre responsable est un bon début
– Utiliser les filtres et champs de recherche
o N’y a-t-il pas déjà un ticket ouvert sur un sujet quasi identique ?

– Gravité ?
o Quel est le niveau de gravité de l’anomalie ?
– Critique
– Majeure
– Mineure

Une dernière bonne pratique pour la route ? Faite un copier / coller des pratiques ci-dessus dans un fichier Excel, nommé ce fichier « Checklist garante de la qualité du référentiel de test. ». Il ne vous restera plus :

  • qu’à aller demander une augmentation à votre manager ;-)
  • qu’à la présenter à votre client qui aura enfin un réel exemple d’industrialisation des outils de test

Et pour la petite histoire, sachez que mettre en pratique tout les jours ces préconisations fera de le mise en oeuvre de cet outil un niveau CMMI 3 (voir article complémentaire sur CMMI3 et QC).





Manuel de survie sur Quality Center !

15 10 2008

Dans le monde du test tout le monde parle de Quality Center (QC pour son petit nom) de l’éditeur HP Mercury. Tout le monde en parle, du client à la société de service, en passant par les ingénieurs qui ne jurent que par ce fabuleux QC… Quel monde merveilleux que le notre dans lequel tout les acteurs d’un même projet partagent, échangent et utilisent le même référentiel de test et font en sorte que les exigences métier soient au cœur des priorités de chacun… Mais… La réalité est moins glamour !
En effet, parmi ces milliers d’ingénieurs seuls une petite poignée connaissent réellement QC et l’utilisent correctement.
Ainsi j’écris cet article afin de vous présenter les fondamentaux de l’outil et apporter quelques bonnes pratiques à mettre en œuvre lors de l’utilisation d’un référentiel de test (je ne m’étendrai pas sur la partie administration de cet outil).

Dis tonton, qu’est-ce qu’un référentiel de test ?
Ou « Comment à partir du minimum d’effort faire le maximum ? ». Pour la réponse reportez-vous à l’article sur le sujet.

Dis tonton, il y a quoi dans QC ?
Avant d’expliquer ce qu’il y a dedans précisons juste que c’est un outil partagé de gestion complète des activités de test, que son ancien nom était Test Director (ou TD).L’interface de QC est relativement « user friendly » (adapté aux utilisateurs) et pratique.

Dans cet outil il y a 5 onglets (ou parties). Chacun de ces onglets représente une partie importante pour chaque projet de test. Mais voyons plus en détails chacun de ceux-ci.
– Gestion des exigences ou requirements
– Gestion du catalogue des fiches de test ou Test Plan
– Conception des campagnes de test ou Test Lab
– Gestion des anomalies ou Defects
– Gestion des releases (non expliqué dans cet article car il faut savoir préserver le suspens)

Avec pour chaque onglets les fonctionnalités communes suivantes :
– Rapports & Graphiques
– Bilan
– La possibilité de joindre des captures d’écrans, des documents, etc.
– Impression
– Administration

La logique d’utilisation est la suivante, tout d’abord on élabore la stratégie de test et la matrice de couverture (onglets exigences et Test Plan). Puis, on planifie les exécutions (Test Plan et Test Lab), lors des exécutions on crée les fiches d’anomalies via lesquelles on fait valider les corrections.
Enfin, on met à jour les tests et on réitère le cycle de tests.

Plongeons nous dans QC :
Gestion des exigences ou requirements :
Il s‘agit d’identifier les exigences de test (à partir des exigences métier et autres spécifications), de structurer le plan de test et spécifier les futures fiches de test.
Petit rappel : les exigences peuvent être l’expression des besoins ou la liste des fonctionnalités à tester. Ainsi, l’ensemble des exigences de test définissent le périmètre à couvrir. Ces exigences sont aussi le point commun entre les dossiers de spécification et les tests à exécuter.
Les prendre en compte permet d’assurer la traçabilité entre la phase de conception et celle d’exécution. Enfin, les exigences sont le support aux études d’impact des évolutions des spécifications sur les plans et fiches de test.
Cet onglet permet également de voir tout les détails des exigences et de voir le statut des résultats des fiches de test couvrant une ou ses exigences propres.
Enfin, on peut soit entré manuellement les exigences soit utiliser une macro d’import à utiliser sur des documents aux formats Word ou Excel. Soit sous forme d’addin ou de développement interne au client ou la société de service.

Gestion du catalogue des fiches de test ou Test Plan :
Il s’agit de concevoir les fiches de test, définir les scénarios et préparer le reporting (en collaboration avec le Test Lab). Il s’agit aussi de créer l’arborescence des fiches de test ainsi que les fiches et créer les liaisons entre les exigences et fiches de test.
Le Test Plan correspond à l’ensemble des fiches de test, en cours de constitution ou opérationnelles.

Conception et exécutions des campagnes de test ou Test Lab :
Il s’agit de la création et de la planification des campagnes de test. L’exécution a lieu dans cet onglet, qu’elles soient automatisés ou manuel.

Rappelons que :
– une campagne de test est une combinaison de scénarios (composés de fiches de test)
– une fiche de test peut faire partie de plusieurs campagnes
– a l’issue de l’exécution des différentes épates, une fiche de test est considérée en statut PASSED, si et seulement si TOUTES les étapes la composant on ce même statut
– si au minimum une de ces étapes est en statut FAILED ou NOT COMPLETED la fiche de test aura ce même statut

Gestion des anomalies ou Defects :
Après exécution des scénarios / fiches de test il s’agit de décrire les anomalies et renseigner le reporting de campagne.

La suite de l’article concerne les bonnes pratiques





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