Tra optimiser preparation_tests_v1

3 365 vues

Publié le

Comment préparer ses tests en s'appuyant sur un référentiel de tests ?

Publié dans : Formation, Technologie
0 commentaire
1 j’aime
Statistiques
Remarques
  • Soyez le premier à commenter

Aucun téléchargement
Vues
Nombre de vues
3 365
Sur SlideShare
0
Issues des intégrations
0
Intégrations
46
Actions
Partages
0
Téléchargements
0
Commentaires
0
J’aime
1
Intégrations 0
Aucune incorporation

Aucune remarque pour cette diapositive
  • Les enjeux d’un référentiel de tests Les étapes de la constitution d’un référentiel Une équipe sensibilisée aux tests et ayant le même ‘langage de tests’ Le référentiel des exigences La cartographie Mise en place des normes de préparation des tests : soit via des templates ‘.doc’ ou ’.xls’ soit via des outils Open source comme TCM Préparation des cas de tests et scenarii Identification des jeux de données La gestion des anomalies Le test avec SQLI Les services Références Conclusion Axes d’amélioration aux Haras Nationaux Tour de table Conclusion
  • Constat 1 : Les utilisateurs : ils considèrent souvent qu’il s’agit d’une responsabilité DSI. Les informaticiens : ils invoquent le manque de temps, d’outils, d’environnements… et l’absence de la Maîtrise d’Ouvrage. Constat 2 : Les tests sont souvent menés de manière intuitive (taux de couverture ? risque ?). Le leurre du « gain de temps » conduit à minimiser les tests en occultant le risque. Le frein majeur à une approche plus industrielle = l’absence de démarche Constat 3 : Affectation de ressources non dédiées : disponibilité, motivation ? Investissement autour des tests (formation / accompagnement) occulté. Vision peu claire des actions de test à mener, approche empirique. Difficulté de gestion des jeux d’essai : échantillonnage, versionning… Outillage peu mis en œuvre (60% des entreprises équipées  18% d’utilisation* !). Sous-utilisation des indicateurs test pour les arbitrages. L’indépendance de l’équipe, ne pas subir les influences des équipes de dev ou de la MOA qui la ferait sortir des objectifs de tests
  • Le Système d’Information du Test est une combinaison de référentiel de données et d’activités. Les Exigences, les Cas de Test et certains Scénarios sont capitalisables alors que les autres ne vivent que le temps du projets. Les activités obéissent à des processus issus d’une méthode ou d’une Stratégie. Les définitions Cas de tests : la séquence des actions et des observations (permettant de consolider le résultat attendu) constitue le cas de tests Scénarios sont des cas d’usage. Ils sont étroitement liés aux processus et visent des tests de bout en bout. Ils sont en général relativement stables. Dans le cas d’une automatisation de ces scénarios, la sélection doit se faire sur des processus stables et vitaux pour l’entreprise afin que l’automatisation soit rentable (car mise en œuvre à chaque livraison) et du coup de leur maintenance soit budgétée Exigences : élément du cahier des charges ou d’un standard qui doit satisfaire le composant ou le système Anomalies : absence de conformité entre un comportement applicatif attendu et le comportement obtenu en phase de test. Les raisons d’une anomalie peuvent provenir de différentes sources (codes, test, modèle, cahier des charges)
  • Une exigence est un élément nécessaire et indispensable pour la mise en production du logiciel, une contrainte imposée par les équipes métiers La mise en place de ce référentiel des exigences peut se faire de manière progressive et selon le niveau de maturité des équipes. Un accompagnement est parfois nécessaire, et il peut être pris en charge par l’équipe de tests. Idéalement les exigences sont définies au démarrage du projet, chez SQLI nous les référençons dès l’avant vente. Définir la traçabilité cible des exigences a pour objectif d'identifier pour chaque exigence quel livrable permettra de la concevoir, la réaliser et la tester. Les exigences sont de nature fonctionnelle ou non fonctionnelle et il existe différents types d’exigences : cas d’utilisation, règle métier, critères de qualité, exigences d’interface. Lors du référencement des exigences : 1 identifiant unique par exigence Toute exigence doit être rattachée au moins à 1 cas de test Le référentiel des exigences permet de collecter et piloter l'ensemble des exigences explicites et implicites du client, tant d'un point de vue fonctionnel que technique et/ou de mise en oeuvre (FURPS+). Au lancement du projet, le chef de projet s'approprie complètement le référentiel d'exigence pour : Comprendre le besoin du client et comprendre la réponse proposée par SQLI en avant-vente Identifier toutes les ambigüités et préparer leur traitement avec le client Définir la traçabilité cible des exigences a pour objectif d'identifier pour chaque exigence quel livrable permettra de la concevoir, la réaliser et la test. Au cours du projet, le référentiel permet également Parcourir avec le client l'ensemble des exigences initiales et s'assurer de la compréhension réciproque des éléments suivants : description, réponse, statut Arbitrer et traiter le cas des exigences au statut "Acceptée partiellement" : selon les limitations indiquées par SQLI en avant-vente, définir avec le client la réponse au besoin Si le projet est itératif ou par lots, planifier l'itération prévisionnelle de chaque exigence D'identifier les changements et les gérer
  • Ce que je vais dire à l’oral : la grille d’effort de tests est un input à la recette C’est un outil systématiquement mis en œuvre sur les projets SQLI (projets au forfait, TMA, TRA) La grille de tests permet un découpage de l’activité en Combien de tests à réaliser  et du coup estimation de la charge Quand faire la recette  les phases de tests d’intégration, la recette MOE et la recette MOA Qui fera les tests  l’équipe DEV, l’équipe recette MOE et l’équipe recette MOA A garder sous le coude : La grille d'effort de test, dans son onglet « Critère », permet : D'identifier les critères de criticité et les définir pour les items de test avec 3 niveaux pour chaque criticité Identifier et définir les techniques de test avec 3 niveaux d'effort associés pour chaque technique
  • A l’oral : C’est un input à la préparation du référentiel de tests tout comme la stratégie de test. Il est nécessaire de disposer d’une cartographie, c’est une activité en amont de la constitution du référentiel. Si elle n’est pas disponible u un accompagnement sur cette activité est proposée dans les offres SQLI. Il est conseillé d'avoir comme granularité le niveau de « fonctionnalité » de l'application (correspondant par exemple à tous les items de menus de l'application), complété par les exigences techniques du projet. En effet, un niveau macroscopique ne permettra pas de cibler un effort de test approprié à la fonctionnalité.
  • A l’oral : Définir les différents termes utilisés au cours de la préparation des tests. Il est indispensable que l’ensemble des acteurs parlent le même langage. Préparer les tests c’est : Définir des cas de test => C’est le « Quoi » tester ? Définir des scénarios de test => C’est le « Comment » tester ? Spécifier les jeux de données d’essai => Avec quelle données faut-il tester ? Ordonnancer les scénarios de test => Dans quel ordre tester ? Sélectionner les scénarios pour tester la non régression => Le mode nominal fonctionne-t-il toujours ?
  • Un test est un ensemble de cas à tester (état de l'objet à tester avant exécution du test, actions ou données en entrée, valeurs ou observations attendues, et état de l'objet après exécution), éventuellement accompagné d'une procédure d'exécution (séquence d'actions à exécuter). Il est lié à un objectif et à une ou plusieurs exigences
  • Un scénario de test est l’ordonnancement de cas de tests en vue d’exécuter des activités se rapprochant de ce que les utilisateurs réaliseront en production. Les scénarios font l’objet de revue interne, et même pour certains projets être soumis à la validation de l’équipe MOA.
  • Une campagne de tests est une sélection de scénarios devant être mis en œuvre pour les tests d’une version donnée de l’application, et devant respecter un ordonnancement : par exemple il faudra d’abord tester les commandes, la gestion des bons de livraison avant la facture. Le référentiel permet de piloter le déclenchement et le suivi des campagnes.
  • A tout moment au cours d’une campagne de tests connaître l’avancement des travaux Nombre de scénarios exécutés/prévus Nombre de correctifs testés/livrés Nombre d’anomalies détectées
  • La traçabilité : c’est l’"Aptitude à retrouver l’historique, l’utilisation ou la localisation d’un produit ou d’un processus de délivrance d’un service au moyen d’identifications enregistrées". Traçabilité aussi avec les anomalies et de là découle les indicateurs de pilotage du projet Pouvoir gouverner les - Indicateurs de la qualité du produit : - Taux de défaut par rapport à la charge - Taux de défaut par rapport aux exigences : nombre de scénarios OK et KO/exigences, nombre d’anomalies/exigences La couverture d’une exigence se juge selon 4 indicateurs : Nombre de test participant à cette couverture (objectif de test) Nombre de test participant à cette couverture non exécuté (reste à faire) Nombre de test participant à cette couverture exécuté sans anomalie (fait) Nombre de test participant à cette couverture exécuté avec anomalie (à refaire)
  • La gestion des anomalies permet De classer les anomalies par fonctionnalités  pouvoir optimiser les correctifs et leurs tests D’identifier les relations entre les différents incidents (recherche d’une même cause pour plusieurs incidents)
  • A chacune des itérations, le référentiel de tests est mis à jour pour pouvoir être opérationnel à chacune des livraisons
  • RM3 – VER9 la grille d’effort de tests associée à la matrice des exigences Les mesures des taux de défaut sont centralisées sur tous les projets, avec une qualification des projets. Identification des taux de défaut selon les caractéristiques des projets => taux de défaut prévisionnel sur toutes les phases.
  • Démarche de partage et d’acoompagnement
  • A l’oral : définir la release  une version de l’application devant être mise sur le marché
  • A l’oral : les phases de tests sont organisées dans le cadre d’une relation client fournisseur Sans exigence grande difficulté pour définir la stratégie de tests. Si l’on se base sur les besoins définis plus que sur les spécifications un gain de 25% peut être observé
  • CONSEIL : - Audit et préco : analyse de situation, de problèmes, clarification des objectifs, définition d’une situation cible, analyse des écarts - Processus et normes : politique qualité produit, lien avec la politique de release, PAQ, indicateurs et KPI, lien avec les processus de l’entreprise - Centre de tests : préparation d’une externalisation : définition des étapes : transition, phase opérationnelle, réversibilité, mise en place d’un plan de progrès - Conduite du changement : accompagnement, coaching, formation, mesure de retours d’expérience, ajustement d’organisation, plan de communication, identification des points durs, sponsorship - Formation : aux fondamentaux (CFTL), aux outils, aux techniques, aux méthodes et pratiques EXPERTISE : - Outillage du test : tracking des défauts, référentiel de tests et campagnes - Automatisation : scripting (conception, programmation) - Reporting d’activité : indicateurs, KPI, seuils de décision - Tests de charge : stratégie, scénarii, dimensionnement, injection, analyses, coordination avec architectes, équipes techniques, équipes de production CONCEPTION : - Stratégie de tests : ajustement de l’effort en fonction de la criticité métier - Réalisation des plans de test : construction du plan de tests selon les contraintes projet/produit. Prise en compte de la réutilisabilité et des évolutions - Réalisation scénarios et cahier de tests : règles de nommage, connexion au référentiel d’exigences, rédaction, revue des cahiers, utilisation d’un outil - Valorisation des cas de tests : brique élémentaire constituant les scénarios de tests - Mise en œuvre (création / modification) des jeux de données nécessaires à la stratégie EXECUTION : - Gestion des plate-formes de recette : en délégation de la MOE, plate-forme Virtuelles, mise en place de bouchons - Gestion des jeux de données : réinitialisation des jeux, vérification des jeux, chargement des plate-formes, chargement des scripts, chargement des cahiers de tests - Exécution des cas de tests : déroulement, saisie des résultats - Gestion des anomalies : saisie et qualification des anomalies (gravité, type (TU, TI) ) - Tests de compatibilité navigateurs - Assistance à la recette : support/renfort aux tests d’acceptation, vérification de la démarche et des méthodes employées, coaching sur les outils
  • Tra optimiser preparation_tests_v1

    1. 1. Optimiser la préparation de vos tests : un référentiel de tests pour fiabiliser votre application SQLI, fournisseur d'innovation – Positionnement 2010 #
    2. 2. SQLI # <ul><ul><li>1 958 personnes </li></ul></ul><ul><ul><li>CA 2008 : 157,7 M€ </li></ul></ul><ul><ul><li>11 sites en France, 7 en Europe </li></ul></ul><ul><ul><li>2 centres offshore </li></ul></ul>Notre stratégie repose sur deux axes fondamentaux Le groupe est leader sur le segment des NTIC en France <ul><li>Expertise </li></ul><ul><li> * Nouvelles technologies et SAP </li></ul><ul><ul><li>* Centres de Services ( Build et TRA) </li></ul></ul><ul><ul><li>* TMA </li></ul></ul><ul><li>Qualité totale </li></ul><ul><li>SQLI est la 1ère SSII européenne à avoir construit sa stratégie de développement sur l’industrialisation et le choix de CMMI dès 2002 </li></ul>Q1 2010 CMMI 5
    3. 3. Une offre innovante et industrielle # Une offre complète d’innovation, de résultats et d’engagement
    4. 4. Sommaire SQLI, fournisseur d'innovation – Positionnement 2010 # <ul><li>Introduction </li></ul><ul><li>Les attentes </li></ul><ul><li>Les enjeux d’un référentiel de tests </li></ul><ul><li>Le Référentiel : les étapes de sa constitution </li></ul><ul><li>La  mise en place chez SQLI  et les gains sur nos projets au forfait ou TMA </li></ul><ul><li>Retour d’expérience de nos clients </li></ul><ul><li>Conclusion </li></ul>
    5. 5. Les attentes <ul><li>Les questions que nous rencontrons le plus chez nos clients </li></ul><ul><ul><li>Comment mieux organiser les phases de tests ? </li></ul></ul><ul><ul><li>Comment fiabiliser les mises en production ? </li></ul></ul><ul><ul><li>Comment faire diminuer le nombre d’anomalies ? </li></ul></ul><ul><li>Les réponses que nous leur apportons </li></ul><ul><ul><li>Un accompagnement dans la conduite du changement </li></ul></ul><ul><ul><li>Une organisation d’équipe chez eux ou en externalisant dans nos locaux </li></ul></ul><ul><ul><li>La mise en place d’un référentiel de tests </li></ul></ul>SQLI, fournisseur d'innovation – Positionnement 2010 #
    6. 6. Une équipe dédiée aux tests? <ul><li>Constat n°1 : un problème humain. </li></ul><ul><li>Constat n°2 : une démarche peu organisée et au final peu efficace. </li></ul><ul><li>Constat n°3 : des compétences spécifiques qui font défaut. </li></ul><ul><li>L’un des facteurs clés de la réussite des phases de test passe par la mise en place d’une équipe dédiée et formée aux méthodes de tests. Des  professionnels du test  motivés par cette activité et qui ont acquis les compétences et connaissances requises. </li></ul>SQLI, fournisseur d'innovation – Positionnement 2010 #
    7. 7. Les enjeux d’un référentiel <ul><li>Maîtriser les coûts et délais des phases de test et recette : </li></ul><ul><ul><li>Optimiser la productivité des acteurs </li></ul></ul><ul><ul><li>Capitaliser le référentiel de tests </li></ul></ul><ul><ul><li>Disposer de moyens de planification et de suivi des campagnes de test </li></ul></ul><ul><ul><li>Anticiper la préparation à la lecture des Spécifications Fonctionnelles Générales. </li></ul></ul><ul><li>Industrialiser les processus de test et recette : </li></ul><ul><ul><li>Améliorer la qualité des logiciels par leur qualification </li></ul></ul><ul><ul><li>Homogénéiser les pratiques de tests et recette, et les diffuser </li></ul></ul><ul><ul><li>Maîtriser la couverture des exigences </li></ul></ul><ul><ul><li>Mettre à la disposition des acteurs un outil efficace, adapté et accessible </li></ul></ul><ul><ul><li>Accompagner la mise en place du référentiel et des pratiques sous-jacentes. </li></ul></ul>SQLI, fournisseur d'innovation – Positionnement 2010 #
    8. 8. Référentiel de Test et Activités de Test Exigences Cas de Test Stratégie Exécution Test Anomalie Changement Réalisation Correction Couverture Couverture Référentiel Activité Effort Résultat Campagne(s) Scénario de test
    9. 9. Les exigences <ul><li>Le référentiel des exigences permet de collecter et piloter l'ensemble des exigences explicites et implicites d’une application ou d’un ensemble d’applications, tant d'un point de vue fonctionnel que technique. </li></ul><ul><li>Au cours du projet, le référentiel permet également </li></ul><ul><ul><li>De parcourir l'ensemble des exigences initiales et s'assurer de la compréhension réciproque des éléments suivants : description, réponse, statut </li></ul></ul><ul><ul><li>D’arbitrer et traiter le cas des exigences « oubliées » dans le périmètre initial et de définir avec le client la réponse au besoin </li></ul></ul><ul><ul><li>Si le projet est itératif ou par lots, de planifier l'itération prévisionnelle de chaque exigence </li></ul></ul><ul><ul><li>D'identifier les changements et de les gérer </li></ul></ul>SQLI, fournisseur d'innovation – Positionnement 2010 #
    10. 10. Grille d’effort de tests <ul><li>La grille d'effort de test permet de choisir et définir les différentes techniques de test à mettre en place sur le projet : </li></ul><ul><ul><li>Par exemple : </li></ul></ul><ul><ul><li>Des tests unitaires, manuels ou automatisés </li></ul></ul><ul><ul><li>Des tests d'intégrations, manuels ou automatisés </li></ul></ul><ul><ul><li>Des tests systèmes, manuels ou automatisés </li></ul></ul><ul><ul><li>Eventuellement des tests de performance </li></ul></ul><ul><ul><li>Eventuellement des tests de sécurité </li></ul></ul><ul><ul><li>… </li></ul></ul><ul><li>Pour chaque item, sont identifiés des critères de criticité afin d’associer l’effort de tests en adéquation avec l’importance de l’item </li></ul><ul><ul><li>Par exemple : </li></ul></ul><ul><ul><li>Nombre d’utilisateurs </li></ul></ul><ul><ul><li>Fréquence d’utilisation </li></ul></ul><ul><ul><li>Complexité technique de la fonctionnalité </li></ul></ul><ul><ul><li>Fonctionnalité métier critique </li></ul></ul><ul><ul><li>… </li></ul></ul>SQLI, fournisseur d'innovation – Positionnement 2010 #
    11. 11. Cartographie <ul><li>Dans le cadre de la préparation des tests, il faut disposer d’une cartographie de l'application, qui recense tous les objets fonctionnels et techniques : </li></ul><ul><ul><li>A partir du référentiel d'exigences et des spécifications détaillées, recenser tous les cas d'utilisation de l'application pour définir le périmètre des composants à tester </li></ul></ul><ul><ul><li>Détailler chaque cas d'utilisation avec toutes les fonctionnalités attendues (par exemple les éléments de menus) </li></ul></ul><ul><ul><li>Ajouter un bloc avec les exigences techniques et les interfaces </li></ul></ul><ul><li>On obtient ainsi une nouvelle &quot;cartographie&quot; qui recense, avec une granularité homogène, tous les objets fonctionnels et techniques à tester </li></ul><ul><li>L’effort de tests est associé aux exigences priorisées afin de répondre aux objectifs de couverture définis en stratégie pour une release donnée </li></ul>SQLI, fournisseur d'innovation – Positionnement 2010 #
    12. 12. Conception et préparation des tests <ul><li>Cas de Tests </li></ul><ul><li>Scénarios </li></ul><ul><li>Jeux de données </li></ul><ul><li>Campagnes de tests </li></ul><ul><li>Le suivi de la couverture des exigences avec mises à jour du référentiel </li></ul>SQLI, fournisseur d'innovation – Positionnement 2010 #
    13. 13. Cas de test <ul><li>Un cas de test fait référence à une exigence à tester </li></ul><ul><li>Il faut connaître les exigences et les critères de satisfaction de ces exigences </li></ul><ul><li>Les cas de tests doivent couvrir tous les types de tests définis dans la Stratégie de Tests </li></ul><ul><ul><li>Test des interfaces utilisateurs </li></ul></ul><ul><ul><li>Test des conditions limites des données en entrée et en sortie </li></ul></ul><ul><ul><li>Test du fonctionnement applicatif en condition normale </li></ul></ul><ul><ul><li>Test du fonctionnement applicatif en condition d’exception, en mode dégradé </li></ul></ul><ul><ul><li>Tests de Robustesse pour éprouver les systèmes face à des évènements inattendus </li></ul></ul><ul><ul><li>Tests d’Ergonomie </li></ul></ul><ul><ul><li>Tests de sécurité… </li></ul></ul><ul><li>En général, les cas de tests sont saisis directement dans l’outil de test </li></ul>SQLI, fournisseur d'innovation – Positionnement 2010 #
    14. 14. Scénarios <ul><li>Il s’agit de la conception de scénarios à partir des cas de test </li></ul><ul><li>Chaque scénario fonctionnel doit être représentatif de l’activité d’un utilisateur final </li></ul><ul><ul><li>Il vaut mieux commencer par des conditions simples et valides </li></ul></ul><ul><ul><li>Evolution progressive vers des situations plus complexes </li></ul></ul><ul><ul><li>Terminer par des conditions d’erreur </li></ul></ul><ul><li>Ajouter les instructions utiles à l’exécution des test </li></ul><ul><ul><li>Initialisation des scénarios </li></ul></ul><ul><ul><li>Exécution pas à pas </li></ul></ul><ul><ul><li>Description des résultats attendus </li></ul></ul><ul><ul><li>Conditions de suspension ou de poursuite en cas d’erreur </li></ul></ul><ul><ul><li>Sauvegarde des jeux de données </li></ul></ul><ul><li>Le déroulement de scénarios « métier » nécessite le manuel utilisateur et des échanges réguliers avec le client </li></ul><ul><li>En général, les scénarios de test sont saisis directement dans l’outil de test </li></ul>SQLI, fournisseur d'innovation – Positionnement 2010 #
    15. 15. Campagne de test <ul><li>Il s’agit de déterminer les dépendances entre les scénarios de test afin d’organiser leur enchainement </li></ul><ul><li>Pour cela, il est utile d’établir un diagramme des dépendances, et de se mettre au plus près des conditions réelles d’utilisations de l’application </li></ul><ul><li>L’état et l’évolution des données d’essai doit être compatible avec l’ordonnancement des scénarios </li></ul><ul><li>Procéder à un choix judicieux des tests initiaux pour : </li></ul><ul><ul><li>Tester rapidement les fonctions principales du système </li></ul></ul><ul><ul><li>Traiter les cas simples au début et les situations complexes vers la fin </li></ul></ul><ul><ul><li>Evaluer succinctement la qualité globale du système </li></ul></ul>SQLI, fournisseur d'innovation – Positionnement 2010 #
    16. 16. Exécution des campagnes de tests SQLI, fournisseur d'innovation – Positionnement 2010 # <ul><li>Création des campagnes en associant tous les scénarios permettant une couverture des exigences, comme défini dans la stratégie de tests </li></ul><ul><li>Au cours de l’exécution, à tout moment avoir des indicateurs permettant de connaître </li></ul><ul><ul><li>Les scénarios exécutés/ scénarios prévus </li></ul></ul><ul><ul><li>Les nombres d’anomalies </li></ul></ul><ul><ul><ul><li>Par scénarios </li></ul></ul></ul><ul><ul><ul><li>Par exigences </li></ul></ul></ul><ul><ul><ul><li>Par sévérité </li></ul></ul></ul><ul><ul><ul><li>Par campagne </li></ul></ul></ul>
    17. 17. Traçabilité <ul><li>Les exigences qui caractérisent le produit doivent être reliées par un lien de traçabilité avec les cas de tests, de façon à pouvoir mesurer en permanence la couverture des exigences par les tests réalisés et associer l’effort de test </li></ul>SQLI, fournisseur d'innovation – Positionnement 2010 # Référentiel des exigences Référentiel des tests Production des tests Traçabilité Experts Métier Equipe Tests
    18. 18. La Gestion des anomalies <ul><li>Référencer toutes les anomalies selon les différentes phases de tests </li></ul><ul><li>La remontée des anomalies doit permettre à tout moment : </li></ul><ul><ul><li>De saisir de nouvelles anomalies ou évolutions </li></ul></ul><ul><ul><li>De qualifier les dysfonctionnements remontés </li></ul></ul><ul><ul><li>De suivre l’évolution de la fiche : en cours d’analyse, en cours de correction… </li></ul></ul><ul><ul><li>De planifier les prochaines campagnes de tests </li></ul></ul><ul><ul><li>D’accéder à l’historique et la traçabilité des échanges </li></ul></ul><ul><li>Gestion des régressions </li></ul><ul><li>Suppression des doublons </li></ul><ul><li>Recherche de la relation (corrélation) entre anomalies </li></ul>SQLI, fournisseur d'innovation – Positionnement 2010 #
    19. 19. # Les apports d’un référentiel partagé # Capitalisation Référentiel de Test Exigences Cas de Tests Anomalies Campagnes Equipe de Développement Equipe de Test MOE MOA Gestion des tests Stratégie de Tests Bilan des Tests Outillage Exécution des tests
    20. 20. Mise en place Projets SQLI <ul><li>Dans le cadre de notre démarche CMMI, chaque projet est suivi dans notre outil IDEOPROJECT : </li></ul><ul><ul><li>Le projet est qualifié selon les technologies mises en œuvre, l’expérience des équipes, la taille du projet…. </li></ul></ul><ul><ul><li>Au cours du projet la charge est suivie dans cet outil, de même que toutes les anomalies sur chacune des phases du projet </li></ul></ul><ul><li>Le suivi de nos projets nous permet ainsi d’identifier les taux de défaut selon les phases de tests. A chaque phase de tests selon le taux de défaut trouvé il est possible : </li></ul><ul><ul><li>De revoir les efforts de tests si le taux est trop faible </li></ul></ul><ul><ul><li>De présager un taux de défaut important dans la phase de tests suivantes </li></ul></ul>SQLI, fournisseur d'innovation – Positionnement 2010 #
    21. 21. Bien tester ? Quoi – Quand - Comment # # <ul><li>Résultats de l’application de bonnes stratégies de tests sur les projets SQLI (Bordeaux). </li></ul><ul><li>Mesures effectuées au travers du référentiel IdeoProject/TCM/Mantis </li></ul>Q1 2010 CMMI 5
    22. 22. Exemple d’Accompagnement d’un client <ul><li>Caractéristiques du client : client qui a attendu la release de fin d’année pour réaliser les tests pour un projet ayant de multiples interfaces avec les applications existantes </li></ul><ul><li>Consultation de la part d’un client qui « subissait » les livraisons </li></ul><ul><ul><li>Bilan : </li></ul></ul><ul><ul><li>Trop de temps passé en recette : un problème de méthodologie (éclairé par un regard extérieur). </li></ul></ul><ul><ul><li>Un vrai éveil à ce sujet. </li></ul></ul><ul><ul><li>Il faut monter en compétence – le test est un « vrai » métier. Conduite du changement : tous les intervenants doivent être impliqués dans l’assurance-qualité du produit. </li></ul></ul><ul><li>Suite à l’état de lieux, une méthodologie a été mise en œuvre </li></ul><ul><ul><li>Respect du cycle de la phase de tests. </li></ul></ul><ul><ul><li>Identifications des points fonctionnels à tester, identification de priorités. </li></ul></ul><ul><ul><li>Constructions des scénarios et cas de tests. </li></ul></ul><ul><ul><li>Planification et ordonnancement de la recette (mais grosse déviation par rapport au plan). </li></ul></ul>SQLI, fournisseur d'innovation – Positionnement 2010 #
    23. 23. Exemple d’Accompagnement d’un client <ul><li>Les constats après 4 mois de pratique </li></ul><ul><li>Des bons points : </li></ul><ul><ul><li>Scénarios </li></ul></ul><ul><ul><li>Jeux de tests </li></ul></ul><ul><ul><li>Volonté de mise en place des recettes </li></ul></ul><ul><ul><li>La recette sert vraiment pour valider une mise en production </li></ul></ul><ul><li>Perspectives </li></ul><ul><ul><li>Vers un accompagnement sur un périmètre bien défini, autour d’un projet dès son démarrage </li></ul></ul><ul><ul><li>Le vendre en interne vers les équipes et le management => nécessité d’indicateurs </li></ul></ul><ul><ul><li>Une piste : le projet « Référentiel Personne – transverse » </li></ul></ul>SQLI, fournisseur d'innovation – Positionnement 2010 #
    24. 24. Pilotage d’une release par les tests <ul><li>Pour mener à bien ces phases de tests, les facteurs clés de succès passent par : </li></ul><ul><ul><li>Pilotage / coordination du processus de test et de corrections. </li></ul></ul><ul><ul><li>Définition planning / priorités / objectifs de chaque release. </li></ul></ul><ul><ul><li>Stratégie d’intégration des corrections. </li></ul></ul><ul><ul><li>Priorisation des corrections, contenus des releases (cut-off) </li></ul></ul><ul><ul><li>Fabrication de la nouvelle release (build) </li></ul></ul><ul><ul><li>Exécution des tests </li></ul></ul><ul><li>L’outillage permet d’assurer le pilotage </li></ul><ul><ul><li>Tableaux de bord de pilotage et de suivi des anomalies. </li></ul></ul><ul><ul><li>Pilotage des revues d’anomalies. </li></ul></ul><ul><ul><li>Des scénarios pour les applications toujours disponibles et un référentiel de tests de non-régression opérationnel </li></ul></ul><ul><ul><li>Mise en œuvre des environnements de test </li></ul></ul>SQLI, fournisseur d'innovation – Positionnement 2010 #
    25. 25. En résumé <ul><li>Satisfaction des MOA et MOE </li></ul><ul><ul><li>Respect des coûts – de la qualité – des délais </li></ul></ul><ul><ul><li>Qualité accrue des produits livrés (applications et documentations) </li></ul></ul><ul><ul><li>Sérénité dans la gestion des anomalies et donc de l’atterrissage </li></ul></ul><ul><li>Budget maîtrisé </li></ul><ul><ul><li>Gain de productivité sur les activités de recette </li></ul></ul><ul><ul><li>Gain de temps dans la planification des tests à mettre en œuvre </li></ul></ul><ul><ul><li>Gain de coût des correctifs </li></ul></ul># # Stock anomalies Stock d’anomalies Stratégie de recette
    26. 26. SQLI – Votre partenaire Tests <ul><li>Expertise Tests </li></ul><ul><ul><li>SQLI dispose de centres de services Tests constitués de spécialistes dédiés aux métiers du test. </li></ul></ul><ul><ul><ul><li>CDS NearShore basés à Bordeaux, Lyon </li></ul></ul></ul><ul><ul><ul><li>CDS OffShore au Maroc (Casablanca et Rabat) </li></ul></ul></ul><ul><li>Qualité </li></ul><ul><ul><li>Depuis 2002, SQLI s’est engagé dans une démarche d’amélioration des processus de production basée sur CMMI . Les tests sont un secteur à part entière de CMMI, largement éprouvé par nos équipes. </li></ul></ul><ul><li>Indépendant </li></ul><ul><ul><li>SQLI agit en toute indépendance d’outils et de méthodologie </li></ul></ul><ul><ul><li>Le choix des méthodes et des outils est réalisé en fonction des besoins et du contexte client. </li></ul></ul><ul><li>Des références significatives dans de multiples contextes. </li></ul>#
    27. 27. SQLI – Notre Offre Tests # # # <ul><li>Conseil : audit, mise en place de méthodologie, conduite du changement, formation… </li></ul><ul><li>Expertise : Outillage du test, Automatisation des tests, Mise en place de reporting d'activité de tests, Tests de charge, Tests de sécurité, Tests d’Ergonomie… </li></ul><ul><li>Conception : Stratégie de tests, Réalisation du plan de tests, des scénarios et cahier de tests, Valorisation des cas de tests, Mise en œuvre des jeux de données … </li></ul><ul><li>Exécution : Gestion des plateformes de recette, Gestion des jeux de données, Exécution des cas de tests, Gestion des anomalies, Tests de compatibilité navigateurs, Assistance à la recette … </li></ul>
    28. 28. <ul><li>Arnaud DEFOSSEZ Responsable du Centre de Tests Email : [email_address] Tél : +33 (0)6 17 65 70 73 Fax : +33 (0)5 56 07 76 41 Web : www.sqli.com </li></ul><ul><li>Groupe SQLI Agence Bordeaux Europarc Immeuble Le Fiducia 27, avenue Léonard de Vinci 33608 PESSAC </li></ul>Vos Contacts SQLI SQLI, fournisseur d'innovation – Positionnement 2010 # <ul><li>Pascale NEGRI Chef de Projet TRA – Consultant Qualité Email : [email_address] Tél : +33 (0)4 72 40 53 59 Fax : +33 (0)4 72 40 53 54 Web : www.sqli.com </li></ul><ul><li>Groupe SQLI Agence Lyon 1, Place Verrazzano CP 611 69258 LYON Cedex 09 </li></ul>

    ×