Test entreprise MIAGE PDF

1 Le test en général C2 – Usage restreint Quelques définitions avant de commencer… Cycle de vie du projet Projet...

1 Le test en général C2 – Usage restreint Quelques définitions avant de commencer… Cycle de vie du projet Projet représente la succession des phases C’est un ensemble d'activités coordonnées d'un projet pour passer d'un besoin à et maîtrisées pour atteindre un objectif un système fonctionnel en service qui clarifié en respectant des exigences de répond aux besoins des utilisateurs. Le qualité, de coûts et de délais. Un projet a cycle de vie dépend de la une date de début et une date de fin. Tout méthodologie de gestion de projet projet a également des caractéristiques adoptée. spécifiques, ce qui le rend unique Besoin Cahier des charges C’est l’expression des attentes du client et / ou des utilisateurs. Il doit est document contractuel fourni impérativement être clarifié sans par le client au fournisseur qui interprétation. Le besoin doit être exprime les attendus d’un projet exprimé de façon affirmative et à réaliser. Il permet d'exprimer avec des métriques ou des avec précision le besoin afin éléments de résultat attendus qu’un fournisseur puisse observables. Jalon proposer une solution technique viable. Le cahier des charges est est utilisé pour désigner un un document qui vit, qui se met événement important de la à jour pendant le projet. réalisation d'un projet, nécessitant un contrôle. Un jalon peut par exemple être la remise d'un livrable 2 ou la clôture d'une phase du projet. C2 – Usage restreint  Les équipes d’un projet Le cadrage Le développement La qualification La livraison client La recette La mise en production 3 C2 – Usage restreint  Le développeur et le testeur Les développeurs : Les testeurs : Ecrire le code Trouver les cas du logiciel Faire les tests unitaires Vérifier la cohérence globale et d’intégration Anticiper les problèmes Débugger Donner de l’importance aux détails Les testeurs et développeurs doivent travailler ensemble pour améliorer la qualité globale du logiciel. Le développeur fait souvent des tests orientés car il connait son code. Le testeur arrive en bout de chaine, souvent alors livraison ou mise en PROD 4 C2 – Usage restreint  Le test dans un projet Les tests sont présents tout au long du cycle de vie d’un projet, ils interviennent aussi bien dans le cadrage que dans la mise en œuvre et la maintenance. CADRAGE REALISATION TESTS PRODUCTION Collecte des besoins Rédaction des SFD Accompagnement aux Gestion de la production tests Pilotage Développement Gestion des anomalies et/ou Gestion des anomalies évolutions Gestion des livraisons Paramétrage et/ou évolutions Retour arrière Identification des Gestion stockage Conception et exécution exigences Accompagnement Exécution tests unitaires des scénarios Elaboration stratégie de Gestion des anomalies et évolutions Création plan de tests Gestion des anomalies 5 tests Préparation JDD Autres tests C2 – Usage restreint  Pourquoi tester ? Les logiciels font partie intégrante de notre vie quotidienne, depuis les applications commerciales (ex : les services bancaires) jusqu’aux produits pour les consommateurs (ex : téléphones portables, voitures) La plupart des gens ont déjà vécu l’expérience d’un logiciel n’ayant pas fonctionné comme attendu Ces dysfonctionnements peuvent occasionner des : - Des pertes financières - Pertes de temps - Pertes de réputation - Blessures ou la mort Les tests logiciels sont un moyen d'évaluer la qualité du logiciel et de réduire le risque de problème de ce logiciel en cours de fonctionnement C2 – Usage restreint  Les conséquences - exemples Financières Décalage du paiement des salaires de plusieurs jours Lors d’un achat par internet, des comptes ont été débités plusieurs fois Images Impossibilité de saisie de la déclaration pour des milliers de personnes suite à un problème de sous-estimation de montée en charge des serveurs Personnes Calibrage d’un scanner défectueux des personnes ont subi des irradiations trop importantes suite à un mauvais codage du driver pilotant le scanner Un constructeur automobile a été accusé pour des accidents suite aux accélérations brutales Environnementales Terres rendues impropres à la culture suite à l’utilisation massive de pesticides, la pulvérisation était mal calculée Rejet toxique important des échappements d’une voiture lié au mauvais réglage des injecteurs dans un cas donné C2 – Usage restreint  Pourquoi tester ? Une erreur courante du test est de considérer que cela se réduit à exécuter des tests et vérifier les résultats. Le processus de test inclut des activités différentes : La planification des tests L’analyse La conception et la mise en œuvre des tests Le suivi de la progression et des résultats des tests L’évaluation de qualité de l’objet de test et des objectifs de tests Une autre perception erronée courante sur le test est qu'il se concentre entièrement sur la vérification des exigences, des cas d’utilisation ou d'autres spécifications. Il permet également de s’assurer : que le système répondra aux besoins des utilisateurs et des autres parties prenantes dans son environnement(s) opérationnel(s) C2 – Usage restreint  Les cycles En fonction du projet, le modèle de développement est différent et le modèle de test l’est également. Le modèle est choisi selon plusieurs critères : - Des objectifs du projet - Du type de produit à développer : mutuelle, site de vente en ligne - Des priorités métier (délai de mise sur le marché ou réglementation) - Des risques projet et produit identifiés (migration) Exemple de modèle de développement : Cascade : une phase ne peut commencer que si la phase précédente est terminée Dans ce modèle, les activités de test arrivent seulement après que toutes les activités de développement ont été complétées Cycle en V : le modèle en V intègre le processus de test partout dans le processus de développement C2 – Usage restreint  Les cycles : modèle en V C2 – Usage restreint  Les cycles Développement incrémental : Implique la définition des exigences, la conception, le développement et le test d'un système par morceaux Développement itératif : Chaque itération délivre un logiciel opérationnel qui est un sous ensemble croissant de l'ensemble global des caractéristiques jusqu'à ce que le logiciel final soit livré ou que le développement soit arrêté C2 – Usage restreint  Définitions : test (non) fonctionnel C’est un ensemble de procédures qui visent à garantir la conformité d’un système. Les tests assurent un niveau de qualité. Le test fonctionnel : Le test non fonctionnel : Les éléments sont évalués en fonction Ces tests ne concernent pas directement du besoin défini afin de s’assurer que le l’utilisateur final, ils correspondent à des résultat est conforme aux attentes de tests techniques. l’utilisateur final ou d’identifier les différences. Le test structurel : Dans ce cas, il s’agit de vérifier directement le codage. Des fois, c’est la seule solution. C2 – Usage restreint  A votre avis… Classer les exemples suivants en fonction de s’ils sont des tests fonctionnels ou non : Les actions de l’application Tests fonctionnels Les performances du logiciel La sécurité du logiciel Ex : La zone numéro de téléphone n’accepte que les chiffres Ex : La page de connexion est affichée en moins de 5 secondes Ex : la page de connexion doit afficher la Tests non fonctionnels zone identifiant et la zone mot de passe Le comportement Les exigences du client de l’application Ex : 30 000 personnes doivent pouvoir se connecter en même temps C2 – Usage restreint  Des exemples ? C2 – Usage restreint  Les techniques de tests Les facteurs qui influencent le choix des techniques de tests : - Le type de composant ou de système - La complexité du composant ou des systèmes - Le règlement en vigueur - Les exigences règlementaires, contractuelles ou client - Les compétences des testeurs - Les types de risques - Les objectifs du test - La documentation disponible - Les outils disponibles - Le temps et le budget - Le modèle du cycle de vie du développement logiciel - L’utilisation prévue du logiciel - Les expériences précédentes dans l’utilisation des techniques de tests - Les types de défauts à trouver C2 – Usage restreint  Boite noire et boite blanche Tests « Boites blanches » : Tests « Boites noires » : Il s’agit de tests qui prennent en Ces tests sont réalisés en ignorant compte les mécanismes internes en l’implémentations de l’application. considérations, comme le code. Ces tests sont réalisés par un profil Ces tests sont souvent réalisés par le utilisateur. développeur lors des tests unitaires. Les tests sont impartiales, le L’accès au code testé permet de programme fonctionne ou non. couvrir l’ensemble du périmètre Les besoins utilisateurs sont vérifiés développé et de couvrir un maximum de cas Ex : la voiture Boites noires : On vérifie que la voiture fonctionne en tournant la clef et en démarrant le moteur => La voiture fonctionne. Boites blanches : On emmène la voiture chez le garagiste, qui regarde le moteur => La voiture fonctionne C2 – Usage restreint  L’expérience Dans certains cas, les cas de test et les données sont basés sur les connaissances et l’intuition du participant. Les testeurs utilisent leur compréhension approfondie du système et leur intuition pour identifier les zones susceptibles de contenir des défauts. Cette méthode repose souvent sur la capacité du testeur à deviner où les erreurs sont les plus probables. Les tests exploratoires où le testeur explore librement l’application, sans suivre de scénario permet également découvrir des anomalies. Cette méthode est utilisée principalement lorsque les spécifications sont incomplètes ou manquantes. Elle est basée sur l’expertise du testeur, il faut donc que le testeur ne soit pas junior. C2 – Usage restreint  La boite noire – partie d’équivalence La démarche : 1. Identifier les partitions de valeurs valides et invalides en entrée. 2. Identifier les partitions de valeurs valides et invalides en sorties 3. Créer les cas de test 4. Tester une donnée dans une partition pour la tester C2 – Usage restreint  La boite noire – partie d’équivalence Une entreprise met à disposition des salariés un outil de saisie des frais de déplacement en voiture selon les règles suivantes : - Seuls les déplacements inférieurs à 50 kms sont remboursés - Si le nombre de kilomètres est inférieur à 0 alors affichage du message « Le nombre de kilomètres doit être supérieur à 0 » - Si le nombre de kilomètres est supérieur à 50 alors affichage du message « Le nombre de kilomètres doit être inférieur à 50 » Message 1 Remboursés + message 2 C2 – Usage restreint  La boite noire – valeurs limites Les valeurs limites (minimum et maximum) de chaque partition d’équivalence sont propices pour déceler des défauts. Une valeur limite pour une partition valide est une valeur limite valide Idem pour les valeurs limites invalides. Deux façons d’aborder la technique : - à 2 valeurs : les valeurs minimale et maximale d'une partition sont ses valeurs limites C2 – Usage restreint  La boite noire – valeurs limites - à 3 valeurs : les valeurs en dessous , sur et juste au dessus de la limite. C2 – Usage restreint  La boite noire – les transitions d’états Un système peut se comporter différemment en fonction des conditions actuelles ou passées (son état). Cela peut se représenter par un diagramme d’états et de transitions. Une table des états montre la relation entre les états et les entrées et peut mettre en lumière des transitions invalides Les tests de transitions d’états sont fréquemment utilisés dans l’industrie du logiciel embarqué et généralement dans l’automatisation technique. Colonne = état Ligne = évènement Case tableau = état final Les cases vides sont des transitions invalides C2 – Usage restreint  La boite noire – les cas d’utilisation Chaque cas d'utilisation spécifie le comportement qu'un sujet Se connecte peut exercer en collaboration avec un ou plusieurs acteurs. Accède à ces Chaque cas d’utilisation a des bénéficiaires pré conditions qui doivent être remplies pour que le cas d’utilisation soit exécuté avec Ajoute un bénéficiaire succès Créer un virement C2 – Usage restreint  Tests de non régression Les types de tests Ils permettent de vérifier que l’application fonctionnent Test d’acceptation comme avant l’ajout de l’évolution (ou de la correction). Ces tests permettent de vérifier que le développement correspond besoin Aucune fonctionnalité existante n’a été impacté défini en amont, notamment en par l’ajout du développement. tenant compte de sa facilité d’utilisation. Ils peuvent être également des pré- requis à l’acceptation d’une livraison 01 03 05 par le client. Test unitaire 02 04 Test court qui sert à vérifier un composant du développement. Ils sont créés par les Test de performance, charge développeurs Tests d’intégration Ces tests assurent que le programme est capable de fonctionner correctement avec des flux de tests permettent de vérifier que la données importants et des connexions simultanées nouvelle fonctionnalité (ou sans problème. correction) s’intègre bien dans le reste de l’application. Ces tests permettent de mesurer la fiabilité, la vitesse, l'évolutivité et la réactivité d'une Ils peuvent par exemple tester application. 24 l’intéraction avec la base de C2 – Usage restreint données  Erreur, défaut et défaillance L’erreur est humaine et peut donc être introduit dans une documentation ou dans le code. L’erreur peut donc amener un défaut et ainsi générer une défaillance du logiciel. Erreur Défaut Défaillance Les causes racines des défauts sont les premières actions ou conditions qui ont contribué à la création des défauts. En cherchant les causes racines, on peut améliorer les processus et réduire ainsi le nombre de défaillances futures. Par exemple le rédacteur de SFD n’a pas compris le besoin, il pourra être formé. C2 – Usage restreint  Manque Erreur, défaut et défaillance connaissance du BA Calcul Indemnités Ambiguïté incorrect Plaintes des mal calculées dans la bénéficiaires spécification Cause racine Défaut origine Défaut Défaillance Effet C2 – Usage restreint  Les 7 grands principes Défauts 01 Exhaustivité Les tests montrent la présence de défauts, pas leur absence 02 Temps Les tests exhaustifs sont impossibles 03 Regroupement Tester tôt économise du temps et de l’argent 04 Regroupement des défauts Pesticides 05 Contexte Paradoxe du pesticide 06 Illusion Les tests dépendent du contexte 07 L’illusion de l’absence d’erreurs C2 – Usage restreint  Les défauts Les tests réduisent la probabilité que des défauts restent cachés dans le logiciel mais, même si aucun n’est découvert ce n’est pas une preuve d’absence complète L’exhaustivité L’exhaustivité dans le test n’est pas possible, il est indispensable de prioriser. Prenons l’exemple d’une application avec : 10 écrans 4 menus 3 options 10 champs 2 types de données 50 valeurs possibles Pour être « exhaustif » il faudrait 10 x 4 x 3 x 10 x 2 x 50 Soit 120 000 cas de tests C2 – Usage restreint  Le temps Tester tôt dans le cycle de vie du développement du logiciel permet de réduire ou d'éliminer des changements coûteux. Si le développeur trouve l’anomalie alors il pourrait la corriger, si c’est le client il faudra repasser par tout le cycle. Les regroupements Les erreurs sont souvent regroupées. Ils sont souvent responsables de la plupart des défaillances. Par exemple un développeur va écrire toute une partie de code. Les pesticides Exécuter plusieurs fois le même cas de tests ne permettra pas de trouver plus d’anomalies. Il est donc nécessaire de modifier les tests, changer les données et écrire de nouveaux tests. Le changement de testeur est également important. Souvent le concepteur n’est pas l’exécutant. C2 – Usage restreint  Le contexte Les tests dépendent du contexte, de l’environnement et des données. Un test sur android et le même sur apple ne donnera pas nécessairement le même résultat. Les illusions C’est une illusion de penser qu’uniquement trouver les défauts assurera la réussite de l’application testée. C2 – Usage restreint  2 Stratégie de tests C2 – Usage restreint  Définition : stratégie de tests Une stratégie de test est une feuille de route décrivant l'ensemble des éléments qui permettront de garantir la qualité du programme lors de la livraison. Elle fournit une description générale du processus de tests. - Collaboration entre le client et les managers : ateliers, échanges - Rédiger en amont des tests : anticiper les sujets - Prises en compte et définition des paramètres o Environnements de tests : jeux de données, disponibilité, vieillissement o Industrialisation : automatisation des tests o Organisation : plan de tests, reporting, livrables o Préparation : vérification exigences, construction patrimoine de tests, JDD o Exécution : parallélisation des campagnes C2 – Usage restreint  Les différentes approches - Analytique : se base sur l’analyse d’un facteur (exigence ou risque), Le test basé sur les risques est un exemple d'approche analytique, où les tests sont conçus et priorisés en fonction du niveau de risque - Méthodiques : Ce type de stratégie de test repose sur l'utilisation systématique d'un ensemble prédéfini de tests ou de conditions de test. - Conforme à un processus : Ce type de stratégie de test implique l'analyse, la conception et l'implémentation de tests basés sur des règles et normes externes - Dirigée ou consultative : Ce type de stratégie de test est principalement dicté par les recommandations, les conseils ou les instructions des parties prenantes, des experts du domaine métier ou des experts techniques - Anti-régressions : Ce type de stratégie de test est motivé par le désir d'éviter la régression au niveau des fonctionnalités existantes - Réactive : Dans ce type de stratégie de test, le test est adapté aux composants ou systèmes testés en réaction aux événements se produisant pendant l'exécution des tests, plutôt que pré planifié C2 – Usage restreint  Les différentes approches - exemples - Projet de refonte du système d’encaissement d’un client - Projet de migration d’une BDD oracle v11 à v12 - Projet concernant la sécurité des sites Web - Projet d’évolution réglementaire (tarification internationale, comptabilité) C2 – Usage restreint  Cas concret * * Le monde est tel que nous le façonnons.  Cas pratique Vous êtes chargé de tester un logiciel de gestion de garage. Le logiciel doit permettre les actions suivantes : - Gérer un rendez-vous. - Enregistrer une réparation. - Générer une facture. - Consulter et mettre à jour le stock de pièces détachées. - Gérer les clients. Définissez différents cas de tests, fonctionnels ou non. Suite à un nouveau concurrent, le garage souhaite mettre en place une promo pour la prochaine livraison de son logiciel. Pour les 20 premières vidanges, 20% de réduction sera appliqué C2 – Usage restreint  Rappel - Les tests font parties de toutes les étapes d’un projet - Les tests fonctionnels sont des cas concrets qui pourront être réalisés par un utilisateur final. - Les tests non fonctionnels ne concernent pas directement l’utilisateur final, ils correspondent à des tests techniques. - Il existe différents types de tests qui doivent être utilisés selon le moment du projet et le besoin (unitaire, intégration, non régression, acceptance, performance) - Un défaut entraine une erreur qui entraine une anomalie. - 7 grands principes de tests : - Les tests montrent la présence de défauts, pas leur absence - Les tests exhaustifs sont impossibles - Tester tôt économise du temps et de l’argent - Regroupement des défauts - Paradoxe du pesticide - Les tests dépendent du contexte - L’absence d’erreurs est une illusion Une stratégie de test est une feuille de route décrivant l'ensemble des éléments qui permettront de garantir la qualité du programme lors de la livraison C2 – Usage restreint  3 Cas de tests & scénarios C2 – Usage restreint  Définition d’un cas de tests Un cas de test c’est un ensemble de valeurs d’entrées, de préconditions, résultats attendus et postconditions, qui sert un objectif. Un ensemble de cas de test compose un scénario. C2 – Usage restreint  Conception d’un cas de tests Jeux de données Il doit être trouvé dans la mesure du possible avant l’exécution. Prérequis (De quoi j’ai besoin) Jeux de Ils peuvent être techniques ou données Etapes fonctionnels. Une étape = une action Prérequis Etapes Elle doit être écrite de manière claire et concise. Détails L’exécutant ne doit pas Les cas doivent être détaillés un maximum. Cas de avoir besoin du concepteur. Attention aux coûts de tests rédaction et au niveau de l’exécutant. Détails Résultat clair Résultat Le résultat doit être clair et exhaustif. Identification Identificati on Il doit être précis et Un cas de test est unique, correspondre à l’étape en son nom doit permettre de cours pour la valider. savoir quelle fonctionnalité est testée. C2 – Usage restreint  Exemple de cas de tests Ex : Vérifier la création d’un compte Etapes Description Attendu 1 Connexion au site internet Affichage de la page d’accueil du site internet Ouvrir l’adresse mail www.vegetinfo.com 2 Accéder à la création du compte L’utilisateur est redirigé vers la page de création de compte Cliquer sur l’onglet « Devenir membre » 3 Vérifier les informations obligatoires Les champs ont une astérix rouge indiquant leur caractère obligatoire Vérifier que les champs Prénom, mail, téléphone sont obligatoires 4 Renseigner le mail Le message suivant apparait et l’enregistrement n’est pas fait : Renseigner le mail et cliquer sur Enregistrer « Merci de renseigner tous les champs obligatoires » C2 – Usage restreint  Concrètement sur ALM Arborescence et Description des Attendu cas de test step des step C2 – Usage restreint  Les critères d’entrée Les critères d’entrées définissent les conditions pour entreprendre l’activité de test. Si les critères d’entrée ne sont pas satisfaits il est probable que l’activité s'avérera plus difficile, plus longue, plus coûteuse et plus risquée. Exemples : - User stories, spécifications fonctionnelles - Disponibilité de l’environnement - Disponibilité des outils - Disponibilité des données et ressources - Défauts critiques C2 – Usage restreint  Les critères de sortie Les critères d’entrées définissent les conditions à remplir pour déclarer un ensemble de tests terminés. Si les critères de sortie ne sont pas satisfaits, il est courant que les tests soient également réduits notamment en raison du budget, du temps et de la pression pour mettre en production le logiciel. Exemples : - Exécution complète des tests prévus - Couverture des exigences - Absence de défauts critiques - Respect des délais et coûts - Taux de réussite défini atteint - Niveau de fiabilité, performance, utilisabilité et sécurité jugés suffisants C2 – Usage restreint  Les critères – exemples concrets Critères d’entrée Démarrage de l’acceptation s’il ne reste aucune anomalie bloquante ouverte à la suite de la phase de test développeur Démarrage de l’acceptation si toutes les SFD sont validées par le client Critère de sortie Arrêt de l’acceptation si 90 des cas de tests ont été exécutés ok Arrêt de l’acceptation si pas d’anomalie bloquante ouverte C2 – Usage restreint  Les paramètres dans les cas de tests Les paramètres sont des variables qui peuvent prendre différentes valeurs pour tester divers scénarios avec le même cas de test. Ils permettent ainsi de personnaliser de plusieurs manière un même cas de tests en testant différentes conditions sans avoir à écrire de nouveaux cas. Ils sont utilisés pour rendre les cas de test plus flexibles et réutilisables. C2 – Usage restreint  Les paramètres dans les cas de tests Les paramètres peuvent être présents sous différentes formes. Paramètres d’entrée Il s’agit de valeurs spécifiques utilisées pour tester les fonctionnalités du logiciel. Par exemple, des noms d’utilisateur et des mots de passe pour tester une fonctionnalité de connexion. Paramètres de sortie Les résultats que le test doit produire pour être considéré comme réussi. Par exemple, un message de confirmation après une soumission de formulaire. Paramètres de contrôle Les conditions spécifiques sous lesquelles le test doit être exécuté, comme les environnements de test (développement, test, production). C2 – Usage restreint  Les paramètres dans les cas de tests 01. Réduction de la Redondance Évite la duplication des cas de test en permettant de tester plusieurs scénarios avec un seul cas de test 02. Couverture Étendue. Permet de couvrir un large éventail de conditions et de données d’entrée 01 03. Maintenance Simplifiée Facilite la mise à jour des cas de test, 02 car il suffit de modifier les paramètres plutôt que de réécrire les tests. 03 04. Clarté 04 Ils permettent de séparer les données de test de la logique de test, ce qui rend les tests plus lisibles et compréhensibles C2 – Usage restreint  Les paramètres dans les cas de tests 01. Compléxité Ajoute de la complexité, surtout si les tests deviennent très nombreux ou si les paramètres 04 sont nombreux et variés 03 02. Débug plus difficile Il peut être plus difficile de déterminer quelle 02 combinaison de paramètres a causé l’échec 01 03. Performance L’exécution de nombreux tests paramétrés peut prendre plus de temps, surtout si chaque combinaison de paramètres doit être testée de manière exhaustive 04. Maintenance Les données de test doivent être soigneusement maintenues et mises à jour, ce qui peut devenir une tâche fastidieuse si les paramètres changent fréquemment C2 – Usage restreint  Les paramètres dans les cas de tests Vérification de la fonctionnalité de connexion utilisateur. Étapes : Entrer le nom d’utilisateur. Entrer le mot de passe. Cliquer sur “Se connecter”. Résultats Attendus : L’utilisateur est redirigé vers la page d’accueil. Paramètres : nom_utilisateur : user1 | user2 | user3 Password : password1 | password2 | password3 C2 – Usage restreint  Les paramètres dans les cas de tests Vérification de la fonctionnalité de connexion utilisateur. Étapes : Entrer le nom d’utilisateur. Entrer le mot de passe. Cliquer sur “Se connecter”. Résultats Attendus :. Paramètres : nom_utilisateur : user1 | user2 | user3 Password : password1 | password2 | password3 Resultat : L’utilisateur est redirigé vers la page d’accueil | Affichage pop-up de modification de mot de passe | Affichage pop-up de mot de passe erroné C2 – Usage restreint  A vous de jouer Vous travaillez pour une application de gestion de boulangerie, vous testez la fonction de gestion des stocks de produits et les commandes des clients Créer des cas de tests utilisant des paramètres C2 – Usage restreint  A vous de jouer Exemple de correction Scénario : vente réussie Scénario : vente réussie 1. Connexion au logiciel de boulangerie 1. Connexion au logiciel de boulangerie 2. Sélection du produit 2. Sélection du produit avec un stock pour un prix avec un stock pour un prix unitaire de unitaire de 3. Entrée la quantité 3. Entrée la quantité 4. Enregistrer la vente 4. Enregistrer la vente 5. Vérifier que le montant de la 5. Vérifier que le montant de la commande est de commande est de => Le stock a été déduit de => Le stock a été déduit de Paramètres : Paramètres : - : baguette, croissant, - : baguette, croissant, chouquette chouquette - : 50 | 100 | 150 - : 50 | 100 | 150 - : 1 | 2 | 0.5 - : 1 | 2 | 0.5 - : 3 | 10 | 25 - : 3 | 10 | 25 - : 1x3 | 2x10 | 0.5x25 - : 1x3 | 2x10 | 0.5x25 C2 – Usage restreint  A vous de jouer Exemple de correction Scénario : solde insuffisant Scénario : solde insuffisant 1. Connexion au logiciel de boulangerie 1. Connexion au logiciel de boulangerie 2. Sélection du produit 2. Sélection du produit avec un stock pour un prix avec un stock pour un prix unitaire de unitaire de 3. Entrée la quantité 3. Entrée la quantité 4. Valider la vente 4. Valider la vente => Affichage du message « stock => Affichage du message « stock insuffisant, achat maximum insuffisant, achat maximum Paramètres : Paramètres : - : éclair, religieuse, flan - : éclair, religieuse, flan - : 10 | 8 | 12 - : 10 | 8 | 12 - : 3 | 4 | 2.5 - : 3 | 4 | 2.5 - : 11 | 9 | 25 - : 11 | 9 | 25 C2 – Usage restreint  Cas de tests et scénarios Un scénario de test est une situation d’utilisateur final. Il couvre plusieurs cas de test et vise à valider un processus métier complet Exemple d’un achat en ligne : Scénario : Cas de tests : Connexion au compte client 1. Connexion au compte client 1. Renseigner l’adresse du site et client sur 2. Recherche d’un produit entrée 3. Ajout au panier 2. Dans le champ login saisir l’adresse mail et dans le champ mot de passe saisir le mot de 4. Paiement passe 5. Confirmation 3. Cliquer sur Connexion C2 – Usage restreint  Les scénarios Un cas de tests peut également être inclus dans plusieurs scénarios Cas de tests : Connexion au compte client Scénarios : 1. Renseigner l’adresse du site et client sur entrée 1. Achat d’un produit 2. Dans le champ login saisir l’adresse mail et 2. Vérification du statut de la commande dans le champ mot de passe saisir le mot de 3. Récupération de la facture passe 4. Procéder à une réclamation 3. Cliquer sur Connexion Tous les scénarios n’ont pas la même priorité, il est donc important de déterminer l’importance et la valeur métier du scénario en se demandant quelle est la gravité si le cas de test ne fonctionne pas. C2 – Usage restreint  Les types de scénarios Début Scénarios nominaux Il s’agit des scénarios pour l’utilisation « normale » de l’application. L’objectif est atteint. Scénarios alternatifs Il s’agit des scénarios qui sont des variantes du scénarios nominal. Ils sont souvent moins courants que les scénarios nominaux. L’objectif est atteint au moins partiellement. Scénarios d’exceptions Il s’agit des scénarios qui sont des variantes du scénarios nominal. Il s’agit généralement de cas à la marge. L’objectif n’est pas atteint. Fin C2 – Usage restreint  Végét’info Panier Mon compte Végét’Info Intérieur Extérieur Les pots Astuces Entretien Produits Pots d’intérieur Les pots >Réflexion sur Pots d’intérieur quelques scénarios nominaux, alternatifs et exceptionnels Taille Ce logiciel permet aux utilisateurs de parcourir un catalogue de plantes, de les ajouter à leur panier et de passer commande. Diamètre Couleur (3) Blanc Marron Jaune Rouge Emplacement Pot Camille Pot Aurore Pot Lisa Matières A partir de 22€ A partir de 15€ A partir de 18€  Les types TNR Les tests de non-régression permettent de vérifier que les évolutions ou corrections rajoutées n’ont pas de conséquences non souhaitées sur le développement déjà fait. Préviennent les bugs Ils aident à identifier et à corriger les régressions avant que le logiciel ne soit livré. Assurent la qualité Ils garantissent que Economisent du temps et le logiciel fonctionne de l’argent comme prévu après les modifications En corrigeant les bugs avant la mise en production C2 – Usage restreint  Les TNR Les TNR doivent être appliqués à chaque fois qu’une modification est faite sur le logiciel, souvent dans les cas suivants : - Une évolution ajoutée - Des corrections effectuées à la suite d’un défaut - Une optimisation du code pour améliorer les performances - Une modification de structure - Une mise à jour C2 – Usage restreint  Les types de TNR Test de non-régression correctif Utilise les tests existants pour vérifier que les corrections de bugs n’ont pas introduit de nouveaux problèmes. Ces tests ne peuvent être utilisés que si la modification n’entraine pas de changement au scénario de test. Test de non-régression complet Teste l’ensemble du logiciel pour s’assurer que toutes les fonctionnalités fonctionnent correctement après des modifications. Avec ce type de tests, le logiciel est testé à partir de zéro. On utilise cette technique quand on redoute que quelque chose a été oublié. Les tests de non-régression complet sont plutôt rare car ils coutent cher et sont longs. Test de non-régression sélectif Cible uniquement les parties du code qui ont été modifiées. C’est le juste milieu entre TNR complet et TNR correctif. C2 – Usage restreint  Les types de TNR Test de non-régression progressif Ajoute de nouveaux tests lorsque les anciens ne sont plus pertinents. Lorsqu’une fonctionnalité est modifiée alors le TNR qui l’associe doit être modifié afin de répondre au nouveau besoin. Test de non-régression partiel Utilisé lorsque différents modules sont fusionnés. Admettons que plusieurs développeurs travaillent sur différentes branches et qu’ils se regroupent et fusionnent leur développement, la méthode des TNR partiels peut être utilisée en se basant sur les scénarios existants. Test de non-régression unitaire Teste des unités de code spécifiques de manière isolée. Cette méthode ne tient pas compte des contraintes, intégrations ou autres éléments gravitant autour de la modification. C2 – Usage restreint  Réaliser des TNR 1. Identification des modifications Identifier quelles modifications a été faites dans le code afin de déterminer quels modules sont impactés par la modification. 2. Prioriser les changements Hiérarchiser les modifications en fonction de l’utilisation finale. 3. Déterminer les points de départ Les points de départs doivent être conforment avant de lancer l’exécution des TNR. 4. Définir les points de sortie Les points de sortie doivent être définis et fixés afin de pouvoir valider les TNR. 5. Planifier l’exécution Lancer les tests. 6. Analyse des résultats Vérifier que les résultats obtenus correspondent aux résultats attendus. 7. Corriger les bugs En cas d’anomalie détectée, corriger et réexécuter les TNR. C2 – Usage restreint  Les bonnes pratiques des TNR Les TNR doivent être intégrer au plan de tests et doivent être réalisés à chaque modification. La mise à jour des TNR et l’ajout de nouveaux TNR dans les campagnes doit être fait à chaque versions. Les TNR doivent être documentés, le jeu de données et les résultats doivent être clairs, ce qui permet de faciliter le suivi et la résolution des problèmes. Les TNR font souvent l’objet de campagne de tests automatisés. C2 – Usage restreint  Cas concret * * Le monde est tel que nous le façonnons.  Cas pratique Vous travaillez sur un logiciel de gestion de bibliothèque. Ce logiciel permet aux bibliothécaires de gérer les emprunts et les retours de livres, ainsi que de consulter le catalogue en ligne. Objectifs : 1. Définir des Tests de Non-Régression (TNR). 2. Définir des tests nominaux, alternatifs et d’exception pour une nouvelle fonctionnalité : la réservation de livres en ligne. - Rédigez les cas de tests en utilisant les paramètres fournis. - Assurez-vous que chaque cas de test est clair et précis. - Discutez en groupe des résultats attendus et des éventuelles améliorations à apporter aux tests. C2 – Usage restreint  Rappel Un cas de test c’est un ensemble de valeurs d’entrées, de préconditions, résultats attendus et postconditions, qui sert un objectif. Les paramètres sont des variables qui permettent de tester divers scénarios avec le même cas de test. Ils sont utilisés pour rendre les cas de test plus flexibles et réutilisables. Il existe des paramètres d’entrée, de sortie et de contrôle. Un scénario de test est une situation d’utilisateur final. Il couvre plusieurs cas de test et vise à valider un processus métier complet. Il existe des scénarios nominaux (l’objectif est atteint), des scénarios alternatifs (l’objectif est partiellement atteint) et des scénarios d’exceptions (l’objectif n’est pas atteint). Les tests de non-régression permettent de vérifier que les évolutions ou corrections rajoutées n’ont pas de conséquences non souhaitées sur le développement déjà fait. Ils assurent la qualité, préviennent les bugs et économise du temps et de l’argent. Les TNR doivent être intégrer au plan de tests et doivent être réalisés à chaque modification. La mise à jour des TNR et l’ajout de nouveaux TNR dans les campagnes doit être fait à chaque versions. C2 – Usage restreint  4 Plan de tests C2 – Usage restreint Définition : plan de tests Un plan de test valide la couverture du périmètre fonctionnel du projet. Contenu Il contient les cas de tests fonctionnels nécessaire pour 01 assurer la qualité de la livraison. Objectif 02 Il a pour objectif d’identifier les scénarios et les Le plan prioriser. de tests Il valide ainsi le périmètre fonctionnel. 03 Périmètre Son périmètre peut être associé à une version de l’application ou à un projet dans sa globalité. 04 Quand ? Il est rédigé dès la définition du périmètre. C2 – Usage restreint  Cas d’usage Construction d’un plan de tests Il s’agit d’une description des différentes utilisations que le ou les utilisateurs finaux devront pouvoir réaliser SFD/SFG Stategie de tests Spécifications fonctionnelles C’est un document de haut détaillées, souvent écrit par niveau définissant, pour un l’entreprise qui développe le besoin, les niveaux de tests à besoin. Les SFD détaillent le exécuter et les tests dans besoin plus en profondeur. chacun de ces niveaux. Spécifications fonctionnelles générales, écrits par l’entité ayant besoin du service. Plan de test C2 – Usage restreint  Construction d’un plan de tests Dans la majorité des projets, les SFG/SFD sont écrites avec les marques de révisions. Documents Les écarts sont directement Ils contiennent les dans le document. fonctionnalités qui vont être implémentées ou Ecart corrigées. Il est fondamental de savoir ce qui va être ajouté à Cas de tests l’application déjà existante. Les cas de tests peuvent être Stratégie de tests commun à certains scénarios Documents (ex : connexion). Ils seront ensuite rédigés afin Stratégie de test Existant d’être exécutés. Elle peut contenir des Ecart informations essentielles sur le périmètre à tester. Scénarios Existant L’existant sera à tester grâce Cas de tests aux TNR, il est important de le connaitre afin de Scénarios déterminer et prioriser Les scénarios nominaux, correctement les tests. alternatifs ou d’exceptions permettront de prioriser les cas de tests. C2 – Usage restreint  Les caractéristiques Un cas de test peut être défini dans un plan de test par : - Son nom qui doit être unique et permettre de savoir rapidement ce que l’on test On peut mettre le nom de la règle de gestion à tester ou encore le cas particulier. ex : Connexion_RG12_Onglets - Son résultat : passant ou non passant On précise systématique si le résultat du test est passant ou non - Sa charge estimée : combien de temps pour l’écrire / l’exécuter Si le test doit être écrit ou exécuter en 1h et qu’il reste 30min alors le cas ne pourra être exécuté. C2 – Usage restreint  Les caractéristiques - Ses prérequis Si le cas dépend d’un autre scénario alors il devra être jouer après le scénario en question. - Son attendu L’attendu du scénario correspond au résultat final suite à l’enchainement des actions du scénarios. On peut rajouter : - Son type : unitaire, de charge, acceptation, non régression - La personne qui va l’écrire ou l’exécuter - Si le cas jouer est un prérequis pour un autre cas Le plan de tests est défini en fonction des besoins du projet. C2 – Usage restreint  La priorité - Tous les scénarios ne peuvent être réalisés - Il est important de prioriser Impact Prioriser en fonction de : Priorité Priorité - La fréquence moyenne haute - L’impact sur l’utilisateur final - Les risques - La probabilité Priorité Priorité - Les conséquences financières basse moyenne - La quantité impactée Probabilité Le temps de tests et les coûts sont importants dans la priorisation. C2 – Usage restreint  Le calendrier Le calendrier d’exécution doit tenir compte de plusieurs facteurs : - l’ordre de priorité - Les dépendances entre les cas de tests & scénarios - Les tests de confirmation (tests effectués après la correction d’un défaut) - Les tests de non-régression - La séquence la plus efficace Les tests sont souvent exécutés en fonction de leur priorité mais dans certains cas de dépendance; il arrive que des scénarios avec des niveau de priorité moins important soient joués avant les tests dont la priorité est plus élevée. Généralement, plusieurs enchainements sont possibles avec des niveaux d’efficacités différents, il est donc important de trouver un compromis entre l’efficacité des exécutions et la priorité des scénarios. C2 – Usage restreint  Définir l’ordre d’exécution En considérant la série de cas de tests suivantes et 2 testeurs disponibles : Série Priorité Prédécesseurs Successeurs S1 0 S3 S2 0 S3, S4 S3 1 S1, S2 S5, S6 S4 2 S2 S6 S5 0 S3 S6 2 S3, S4 S7 S7 2 S6 S8 1 Ecrire un enchainement d’exécution le plus efficace possible, les priorités 0 doivent être exécutée le plus tôt. C2 – Usage restreint  L’effort de tests Prioriser est un facteur nécessaire pour estimer l’effort de tests. L’effort de test fait référence à l’ensemble des activités et des ressources nécessaires pour planifier, concevoir, exécuter et évaluer les tests d’un produit. Il consiste à prédire la quantité de travail qui sera nécessaire pour atteindre les objectifs de tests et garantir la qualité du logiciel. L’objectif est de permettre de faire une projection de la charge nécessaire par phase de test et par activité mais également d’anticiper les phases de re-jeu après relivraison de corrections. Il est également nécessaire de capitaliser cet effort afin d’affiner les estimations futures. C2 – Usage restreint  L’effort de tests Les factures qui influent l’effort de tests peuvent être : Les caractéristiques d’un produit - Les risques associés au produit - La qualité de base - La taille du produit - La complexité du domaine métier - Les exigences relatives aux caractéristiques de qualité (sécurité, fiabilité) - Le niveau de détails requis pour la documentation des tests - Les exigences en matière de conformité juridique et réglementaire Les caractéristiques liées aux personnes - Les compétences et l’expérience des personnes impliquées dans le projet. - La cohésion et le leadership de l’équipe C2 – Usage restreint  L’effort de tests Les caractéristiques du processus de développement - La stabilité et la maturité de l’organisation - Le modèle de développement utilisé - L’approche de test - Les outils utilisés - Le processus de test - La pression des délais Les résultats de tests - Le nombre et la sévérité des défauts trouvés - La quantité de travail nécessaire à refaire C2 – Usage restreint  L’effort de tests Il existe plusieurs techniques pour estimer l’effort de tests. La technique basée sur les métriques : estimer l’effort de tests basée sur d’anciens projets similaire ou sur la base de valeurs représentatives. exemple : les modèles de corrections de défaut : Le nombre de défaut et le temps nécessaire à la correction sont recueillis et enregistrés ce qui fournit une base pour estimer les nouveaux projets similaires. La technique basée sur l’expertise : estimer l’effort de tests sur la base de l’expérience des responsables des tâches ou par des experts. exemple : les groupes d’experts fournissent des estimations basées sur leur expérience. C2 – Usage restreint  L’effort de tests Les métriques peuvent déterminer la complexité de chaque test et ainsi de fournir une charge de création de cas de tests, d’élaboration de jeux de données et d’exécution. Nombre de cas de tests Nombre de RG Simple 1à4