Tra optimiser preparation_tests_v1
•
1 recomendación•1,574 vistas
Comment préparer ses tests en s'appuyant sur un référentiel de tests ?
![SQLI # ,[object Object],[object Object],[object Object],[object Object],Notre stratégie repose sur deux axes fondamentaux Le groupe est leader sur le segment des NTIC en France ,[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],Q1 2010 CMMI 5](data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7)
Recomendados
Más contenido relacionado
La actualidad más candente
La actualidad más candente (20)
Destacado
Destacado (10)
Similar a Tra optimiser preparation_tests_v1
Similar a Tra optimiser preparation_tests_v1 (20)
Último
Último (19)
Tra optimiser preparation_tests_v1
- 1. Optimiser la préparation de vos tests : un référentiel de tests pour fiabiliser votre application SQLI, fournisseur d'innovation – Positionnement 2010 #
- 3. Une offre innovante et industrielle # Une offre complète d’innovation, de résultats et d’engagement
- 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
- 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
Notas del editor
- 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