Remerciez-le!

Remerciez @Admin pour avoir partagé cet document gratuitement, de la manière la plus simple, en partageant sur les réseaux sociaux.

ISTQB Foundation level Certification en test de logiciels basé sur le Syllabus

ISTQB Foundation level Certification en test de logiciels basé sur le Syllabus ISTQB Version 2018 Agenda  Introduction - ISTQB  ISTQB ?  Les niveaux de connaissance  Fondamentaux des Tests  Pourquoi les tests sont ils nécessaires?  Que sont les tests  Les 7 principes généraux des tests  Processus de test fondamental  La psychologie des tests Agenda  Tester Pendant le Cycle de Vie Logiciel  Modèles de Développement Logiciel Test specification  Niveaux de tests  Types de tests  Tests de maintenance Techniques Statiques  Techniques statiques et processus de test  Processus de revue  Analyse statique avec des outils Agenda Techniques de Conception de Tests Le processus de développement de test Catégories de techniques de conception de tests Techniques basées sur les spécifications ou techniques boîte noire Technique de conception basée sur la structure ou technique de conception boîte blanche Techniques basées sur l’expérience Sélectionner les techniques de tests Agenda  Gestion des Tests  Organisation des tests  Estimation et planification des tests  Suivi et contrôle du déroulement des tests  Gestion de configuration  Test et risque  Gestion des déauts Outils de Support aux Tests  Introduction aux outils de test (K2)  Utilisation efficace des outils : Bénéfices potentiels et Risques Introduction ISTQB?  « International Software Testing Qualifications Board » • Le Comité international de qualification du test logiciel reconnue dans le monde entier. • Il a été fondé en novembre 2002 à Édimbourg, comme association à but non lucratif, et est légalement enregistrée en Belgique. ISTQB® Certified Tester • une qualification standardisée pour le test logiciel • Basé sur le Syllabus et Glossaire, définis par ISTQB et formant la base de la Qualification Internationale en Test de Logiciels Syllabus : FR_ISTQB_FL_Syll_2018_Released Glossaire : Glossaire CFTL/ISTQB des termes utilisés en tests de logiciels http://www.istqb.org/about-as/istqb-levels-and-modules.html ISTQB: différent niveaux Niveaux de connaissance (K-levels)  K-levels • Utilisés pour la classification des objectives d‟apprentissage suivant la taxonomie de Bloom [Anderson 2001]. Compréhension K2 Connaissance K1 Utilisation K3 Analyse K4 Evaluation K5 Synthèse K6 Foundation & Advanced: K1-> K3  K1: Se souvenir  K2: Comprendre  K3: Utiliser Advanced & Experts: K2->K6  K4: Analyser  K5: Evaluer  K6: Créer Niveaux de connaissance (K-levels)  Niveau 1: Se souvenir (K1) • Le candidat reconnaîtra et se rappellera des termes ou des concepts • Mots clés: Se souvenir, retrouver, reconnaître, mémoriser, savoir  définition Niveau 2: comprendre (K2) • Le candidat peut sélectionner les raisons pour des affirmations liées au sujet traité, et peut donner des exemples sur les concepts de test • Mots clés: Résumer, interpréter, conclure  le pourquoi des choses Niveaux de connaissance (K-levels) Niveau 3: Utiliser / Appliquer (K3) • Le candidat peut sélectionner l'application correcte d'un concept ou d'une technique et l'appliquer à un contexte donné • Mots clés: Implémenter, exécuter, utiliser, suivre une procédure identifier des valeurs, calculer…. Fondamentaux des test Pourquoi les tests sont ils nécessaires (K2) Logiciels de jeux, applications web… Mécontentement et risque de perte du client Applications bancaires, commerce électronique… Pertes financières, risque sur les entreprises Logiciels pour automobiles, avioniques, médecine…. Risque sur les vies humaines Logiciels pour les engins de guerre, les stations nucléaires… Risque sur toute l‟humanité Contexte (K1) Explosion de Ariane5 en 1996 Cause  Changement de spécification entre Ariane4 et Ariane 5 non pris en compte  l'accélération maximum d'Ariane 4 était d'environ 64  choix d‟une variable sur 8 bits  accélération de Ariane 5 pouvait atteindre la valeur 300  besoin de 9 bit pour le chiffre 300 Effet la variable codée sur 8 bits a connu un dépassement  valeur absurde dans la variable  autodestruction de la fusée Origine des défauts Logiciels (K2) 1. L’erreur humaine Pourquoi les tests sont ils nécessaires (K2) Erreur humaine (méprise) Défaut , bug dans le code Défaillance dans le système Les causes de l’erreur humaine  TimeToMarket de plus en plus serré  Des systèmes logiciels de plus en plus complexe  Des technologies de plus en plus innovantes  Multiples interactions entre les systèmes  Manque de communication Origine des défauts Logiciels (K2) 2. Les conditions d’environnement  Radiations  Magnétismes  Pollution  ………. Pourquoi les tests sont ils nécessaires (K2) Conditions d‟environn ement Défaut dans les micro- programmes Défaillance dans le système Erreur / Méprise  Error / Mistake action humaine produisant un résultat incorrect [d‟après IEEE 610] Glossaire ISTQB (K1) Défaut /Bug /Problème  Defect / Fault /Bug Manifestation d‟une erreur dans un logiciel Si exécuté un défaut peut causer une défaillance Défaillance  Failure Déviation constatée du composant ou du système par rapport au service ou au résultat attendu [d‟après Fenton]; Cause Racine Root Cause Une source de défaut telle que si elle est retirée, l‟apparition de ce type de défaut est diminuée ou supprimée Défauts, causes racines et effets Analyse des causes racines  Root Cause Analysis Une technique d‟analyse au but d‟identifier les causes premières de défauts. En dirigeant les mesures correctives sur les causes premières, on espère que la probabilité de réapparition des défauts soit minimisée un manque de connaissance de la part du PO une erreur lors de la rédaction de la US calcul incorrect dans le code paiements d'intérêts incorrects plaintes des clients Cause Racine Erreur Défaut Défaillance Effet Formation du PO Le test? Définition IEEE 729:1993  Le test est un processus manuel ou automatique, qui vise à établir qu‟un système vérifie les propriétés exigées par sa spécification , ou à détecter des différences entre les résultats engendrés par le système et ceux qui sont attendus par la spécification Activité de l’Assurance Qualité  Tester c‟est: Mesurer /Evaluer la qualité (en terme de défauts trouvés) Accroitre la confiance en la qualité (réduction des risques) Augmenter la qualité logicielle (apprentissage des erreurs, processus amélioré) Assurance qualité vs contrôle qualité Assurance qualité (QA) C‟est une approche proactive et continue mettant en place des systèmes, processus et actions visant à répondre à des besoins spécifiques. Principalement axée sur le respect des processus adéquats, elle comprend l‟amélioration continue des processus et le paramétrage d‟un système adéquat de gestion de la qualité, basé généralement sur le standard ISO 9001. Contrôle qualité (QC) Il s‟agit d‟une approche réactive, se concentrant sur les produits principalement et sur ce qui a été fabriqué. Cela permet d‟identifier de potentielles non-conformités et mettre en place des mesures correctives. Le test a pour objectif de Mettre en évidence les défauts d‟un logiciel Prouver la conformité fonctionnelle, aux normes contractuelles, légales ou réglementaires Donner une indication de la qualité du logicielle => un niveau de confiance Fournir suffisamment d'information aux parties prenantes pour leur permettre de prendre des décisions Réduire le niveau de risque d'une qualité logicielle inadéquate Prévenir des défauts Rôle des tests (K2) Le test n’a pas pour objectif de Diagnostiquer les fautes Corriger les défauts Prouver qu‟un logiciel est correcte Prévenir les défauts(K2) Conception des tests tôt dans le cycle de vie  Réflexion sur les cas de tests  Vérification des bases de test existantes Revue des documents  Identification et résolution des problèmes avant le codage  prévenir les défauts Revue de code  Identification et résolution des défauts dans le code  prévenir les défaillances Tests rigoureux des systèmes et de la documentation  Réduction des risques  Augmentation de la qualité  Respect des exigences légales  Atteinte des normes spécifiques User Experience Facilité d‟utilisation Maturité Tolérance aux pannes Fiabilité Tests et qualité (K2) ISO 9126 Répond aux besoins fonctionnels Capacité fonctionnelle Performance, charge, stress Rendement / efficacité Effort pour les évolutions Maintenabilité Transfert vers un autre environnement Portabilité Le test permet de mesurer la qualité des logiciels en vérifiant: Combien de test est suffisant ? (K2) Comment juger la quantité de tests suffisante? Ce n‟est jamais suffisant Quand on a fait ce qu‟on a planifié Quand le client est content Quand on a prouvé que le système fonctionne correctement Quand on est confiant que le système fonctionne correctement Ca dépend du risque sur le système x x x x x  Prendre en compte l’évaluation des risques comment faire un minimum de tests pour un minimum de risques Les activités de test ≠ exécution de test  Planification et contrôle  Etablir les exigences de test  Conception des cas de test et vérification des résultats  Evaluation des critères de sortie  Exécution des tests  Information sur le processus de test  Revues et analyses statiques  La réalisation des activités de Clôture Que sont les tests (K2) Déboguer  Debugging le processus de trouver, analyser et éliminer les causes de défaillance dans les logiciels. Déboguer vs Tester (K1) Les Testeurs: Révéler des défaillances causées par des défauts Les Développeurs: Identifier les causes des défaillances, corriger le code et vérifier que c‟est bien corrigé Les Testeurs: S‟assurer que la correction résout en effet la défaillance Principes généraux des tests Principes généraux des tests (K2) • Les tests montrent la présence de défauts 1 • Les uploads/Management/ istqb-support-2018 1 .pdf