Syllabus CFTL

Retour au sommaire

Fondamentaux des Tests

1. Fontamentaux des Tests

1.1 Pourquoi les tests sont-ils nécessaires? (K2)

Termes Bug, défaut, erreur, défaillance, défaut, méprise, qualité, risques, logiciel, test.

1.1.1 Contexte des systèmes logiciels (K1)
Les systèmes logiciels deviennent une part intégrante de notre existence, des applications commerciales (p.ex. bancaires) aux produits de grande consommation (p.ex. automobiles). La plupart d‟entre nous ont eu l‟expérience d‟un logiciel qui n‟a pas fonctionné comme attendu. Des logiciels ne fonctionnant pas correctement peuvent générer de nombreux problèmes, depuis des pertes financières, de temps ou de réputation, et pouvant même aller jusqu‟à causer des blessures ou la mort.

1.1.2 Origine des défauts logiciels (K2)
Un être humain peut faire une erreur (méprise), qui produit un défaut (bug) dans le code, dans un logiciel ou un système, ou dans un document. Si un défaut dans du code est exécuté, le système n‟effectuera pas ce qu‟il aurait dû faire (ou fera ce qu‟il n‟aurait pas dû faire), générant une défaillance. Des défauts dans les logiciels, systèmes ou documents peuvent générer des défaillances, mais tous les défauts ne le font pas.
Les défauts apparaissent parce que les humains peuvent se tromper et à cause des échéanciers serrés, de la complexité du code et des infrastructures, des modifications de technologies et/ou de multiples interactions entre les systèmes.
Les défaillances peuvent être aussi causées par des conditions d‟environnement : radiations, magnétisme, champs électroniques et pollution peuvent causer des défauts dans les microprogrammes ou influencer l‟exécution des logiciels en modifiant les conditions matérielles.

1.1.3 Rôle des tests dans le développement, la maintenance et l’opération des logiciels (K2)
Des tests rigoureux des systèmes et de la documentation peuvent aider à réduire les risques d‟occurrence de problèmes dans l‟environnement opérationnel et contribuent à la qualité des systèmes logiciels, si les défauts découverts sont corrigés avant la livraison du système pour un usage opérationnel.
Les tests de logiciels peuvent aussi être nécessaires pour respecter des exigences légales ou contractuelles, ou atteindre des normes industrielles spécifiques.

1.1.4 Tests et qualité (K2)
Avec l‟aide des tests, il est possible de mesurer la qualité des logiciels en termes de défauts trouvés, pour des caractéristiques et exigences tant fonctionnelles que non-fonctionnelles (p.ex. fiabilité, utilisabilité, rentabilité, maintenabilité et portabilité). Pour plus d‟informations sur les tests non-fonctionnels voir Chapitre 2; pour plus d‟informations sur les caractéristiques logicielles voir „Software Engineering – Software Product Quality‟ (ISO 9126).
Les tests peuvent augmenter le niveau de confiance en la qualité d‟un logiciel s‟ils trouvent peu ou pas de défauts. Un test conçu correctement et qui est exécuté sans erreur réduit le niveau de risque général du système. Quand les tests trouvent des défauts, la qualité du système logiciel s‟accroît quand ces défauts sont corrigés. Des leçons devraient être apprises à partir des projets précédents. En comprenant les causes premières des défauts trouvés dans d‟autres projets, les processus peuvent être améliorés, ce qui ensuite peut prévenir l‟apparition de ces défauts et, en conséquence, améliorer la qualité des systèmes futurs. C‟est un aspect de l‟assurance qualité.
Les tests devraient être intégrés comme une activité de l‟assurance qualité (p.ex. au côté des standards de développement, de la formation et de l‟analyse des défauts).
1.1.5 Combien de test est suffisant? (K2)
Décider de combien de test est suffisant devrait prendre en compte le niveau de risque, incluant les risques techniques, les risques liés à la sureté et au projet, ainsi que les contraintes du projet telles que le temps et le budget. Les risques seront développés au chapitre 5.
Les tests doivent fournir suffisamment d‟informations pour que les responsables puissent prendre des décisions informées concernant la mise en production du logiciel ou du système en cours de test, pour l‟étape de développement suivante ou la livraison aux clients.

1.2 Que sont les tests ? (K2)

Termes débogage, exigences, revues, cas de test, test, objectifs des tests, test,
Contexte
Une perception habituelle des tests est qu‟ils consistent uniquement en l‟exécution de tests, en fait exécuter le logiciel. C‟est une partie des tests, mais pas l‟ensemble des activités de test.
Des activités de test existent avant et après l‟exécution des tests. Ces activités incluent la planification et le contrôle, la sélection des conditions de test, la conception et l‟exécution des cas de tests, la vérification des résultats, l‟évaluation des critères de sortie, l‟information sur le processus de test et sur le système en cours de test ; elles incluent aussi la réalisation et la finalisation des activités de clôture définitive à la fin d‟une phase de test. Les tests incluent aussi la revue de documents (incluant le code source) et les analyses statiques.
Les tests dynamiques et les tests statiques peuvent être utilisés comme des moyens pour atteindre des objectifs similaires, et fourniront des informations permettant l‟amélioration du système à tester et des processus de développement et de test.
Les objectifs de tests peuvent varier :
o Trouver des défauts
o Acquérir de la confiance sur le niveau de qualité
o Fournir de l‟information utile aux prises de décision
o Prévenir des défauts
Le processus de réflexion et les activités visant à concevoir des tests tôt dans le cycle de vie (vérifier les bases de tests via la conception des tests) peuvent aider à prévenir l‟introduction de défauts dans le code. Les revues de documents (p.ex. exigences), l‟identification et la résolution de problèmes peuvent aussi aider à prévenir l‟apparition de défauts dans le code.
Les points de vue différents des tests prennent en compte des objectifs différents. Par exemple, dans les tests de développement (p.ex. tests des composants, d‟intégration ou système), l‟objectif principal peut être de générer le plus de défaillances possible de façon à identifier et à corriger les défauts dans le logiciel. Dans les tests d‟acceptation, l‟objectif principal peut être de confirmer que le système fonctionne comme attendu, pour s‟assurer qu‟il atteint les exigences. Dans certains cas l‟objectif principal des tests peut être d‟évaluer la qualité d‟un logiciel (sans chercher à trouver des anomalies), de façon à fournir aux responsables de l‟information sur les risques de distribuer un système à un moment précis. Les tests de maintenance incluent souvent des tests pour s‟assurer que de nouvelles anomalies n‟ont pas été introduites pendant le développement des évolutions. Pendant les tests d‟opération, les objectifs principaux peuvent être d‟évaluer les caractéristiques du système telles la disponibilité ou la fiabilité.
Tester et déboguer sont différents. Les tests dynamiques peuvent montrer des défaillances causées par des défauts. Déboguer est l‟activité de développement qui trouve, analyse et supprime les causes de la défaillance. Les tests de confirmation ultérieurs effectués par un testeur assurent que la correction résout effectivement la défaillance. La responsabilité de chaque activité est différente : les testeurs testent, les développeurs déboguent.
Le processus de test et les activités de test sont expliqués en Section 1.4.

1.3 Les 7 principes généraux des tests (K2)

Termes
Tests exhaustifs.
Principes
Un nombre de principes de test ont été suggérés au cours des 40 dernières années et offrent des indications communes à tous les tests.
Principe 1 – Les tests montrent la présence de défauts
Les tests peuvent prouver la présence de défauts, mais ne peuvent pas en prouver l‟absence. Les tests réduisent la probabilité que des défauts restent cachés dans le logiciel mais, même si aucun défaut n‟est découvert, ce n‟est pas une preuve d‟exactitude.
Principe 2 – Les tests exhaustifs sont impossibles
Tout tester (toutes les combinaisons d‟entrées et de pré-conditions) n‟est pas faisable sauf pour des cas triviaux. Plutôt que des tests exhaustifs, nous utilisons l‟analyse des risques et des priorités pour focaliser les efforts de tests.
Principe 3 – Tester tôt
Pour trouver des défauts tôt, les activités de tests devraient commencer aussi tôt que possible dans le cycle de développement du logiciel ou du système, et devraient être focalisées vers des objectifs définis.
Principe 4 – Regroupement des défauts
L‟effort de test devrait être fixé proportionnellement à la densité des défauts prévus et constatés dans les différents modules. Un petit nombre de modules contiennent généralement la majorité des défauts détectés lors des tests pré-livraison, ou affichent le plus de défaillances en opération.
Principe 5 – Paradoxe du pesticide
Si les mêmes tests sont répétés de nombreuses fois, il arrivera que le même ensemble de cas de tests ne trouvera plus de nouveaux défauts. Pour prévenir ce “paradoxe du pesticide”, les cas de tests doivent être régulièrement revus et révisés, et de nouveaux tests, différents, doivent être écrits pour couvrir d‟autres chemins dans le logiciel ou le système de façon à permettre la découverte de nouveaux défauts.
Principe 6 – Les tests dépendent du contexte
Les tests sont effectués différemment dans des contextes différents. Par exemple, les logiciels de sécurité critique seront testés différemment d‟un site de commerce électronique.
Principe 7 – L’illusion de l’absence d’erreurs
Trouver et corriger des défauts n‟aide pas si le système conçu est inutilisable et ne comble pas les besoins et les attentes des utilisateurs.

1.4 Processus de test fondamental (K1)

Termes
Tests de confirmation, incident, test de régression, base de tests , conditions de tests, couverture de test, données de tests, exécution des tests, critères de sortie, registre de test, plan de test, stratégie de test,procédure de test, politique de test, suite de test, rapport de synthèse de tests, testware.
Contexte
La partie la plus visible des tests est l‟exécution des tests. Mais pour être efficaces et rentables, les plans de tests devraient aussi inclure du temps pour planifier les tests, concevoir les cas de tests, préparer les exécutions et évaluer l‟état.
Le processus de test fondamental comprend les activités principales suivantes:
 Planification des tests et contrôle
 Analyse et conception des tests
 Implémentation et exécution des tests
 Evaluer les critères de sortie et informer
 Activités de clôture des tests
Bien que logiquement séquentielles, les activités du processus peuvent se chevaucher partiellement ou être concurrentes. Une adaptation de ces activités principales au contexte du système ou du projet est en général requise.

1.4.1 Planification et contrôle des tests (K1)
La planification des tests consiste à définir les objectifs du test et à spécifier les activités de test à mettre en oeuvre pour atteindre les objectifs et la mission.
Le contrôle des tests est une activité continue de comparaison de l‟avancement actuel par rapport au plan, et d‟information sur l‟état, y compris les déviations par rapport au plan. Cela implique de prendre les actions nécessaires pour atteindre la mission et les objectifs du projet. Afin de contrôler les tests, les activités de test devraient être contrôlées tout au long du projet. La planification des tests prend en compte le feed-back des activités de contrôle et de suivi.
Les tâches de planification et contrôle sont définies au chapitre 5 de ce syllabus.

1.4.2 Analyse et Conception des tests (K1)
L‟analyse et la conception des tests représentent les activités où les objectifs de test généraux sont transformés en des conditions de test et des conceptions de test tangibles.
L‟analyse et la conception des tests se composent des tâches majeures suivantes:
o Réviser les bases du test (telles que les exigences, le niveau d‟intégrité logiciel* (niveau de risque), les rapports d‟analyse de risque, l‟architecture, la conception et les interfaces)
o Evaluer la testabilité des exigences et du système
o Identifier et prioriser les conditions de test sur la base de l‟analyse des articles de test, la spécification, le comportement et la structure du logiciel

o Concevoir et prioriser les tests de haut niveau
o Identifier les données de test nécessaires pour les conditions de test et les cas de test
o Concevoir l‟initialisation de l‟environnement de test et identifier les infrastructures et outils requis
o Créer une traçabilité bi-directionnelle entre les bases de test et les cas de test
*Le degré de conformité auquel le logiciel satisfait ou doit satisfaire par rapport à un ensemble de caractéristiques sélectionnées par les parties-prenantes ou basées sur les systèmes logiciels, et devant être définies pour refléter l‟importance du logiciel pour les personnes concernées (p.ex: complexité logicielle, niveau de sureté, niveau de sécurité, performance souhaitée, robustesse ou coût).


1.4.3 Implémentation et exécution des tests (K1)
L‟implémentation et l‟exécution des tests est l‟activité où les procédures ou scripts de test sont spécifiés en arrangeant les cas de test selon un ordre précis et en ajoutant toute information utile pour l‟exécution des tests; l‟environnement est initialisé et les tests sont lancés.
L‟implémentation et l‟exécution des tests se composent des tâches majeures suivantes:
o Finaliser, développer et prioriser les cas de test (yc l‟identification des données de test)
o Développer et prioriser les procédures de test, créer les données de test et, éventuellement, préparer les harnais de test et écrire les scripts de tests automatiques
o Créer des suites de tests à partir des procédures de test pour une exécution rentable des tests
o Vérifier que les environnements de tests ont été mis en place correctement
o Vérifier et mettre à jour la traçabilité bi-directionnelle entre les bases de test et les cas de test
o Exécuter les procédures de test soit manuellement soit en utilisant des outils d‟exécution de tests, en suivant la séquence planifiée
o Consigner les résultats de l‟exécution des tests et enregistrer les identités et versions des logiciels en test, outils de test et testware
o Comparer les résultats actuels et les résultats attendus.
o Signaler les divergences comme des incidents et les analyser de façon à établir leur cause (p.ex. défaut dans le code, dans les données de test, dans la documentation de test, ou méprise dans la manière d‟exécuter le test)
o Répéter les activités de test en réponse aux actions prises pour chaque divergence. Par exemple, réexécution d‟un test qui était préalablement défaillant de façon à valider une correction (test de confirmation), exécution d‟un test corrigé et/ou exécution de tests de façon à s‟assurer que des défauts n‟ont pas été introduits dans des secteurs non modifiés du logiciel ou que le défaut corrigé n‟a pas découvert d‟autres défauts (test de régression)

1.4.4 Evaluer les critères de sortie et informer (K1)
Evaluer les critères de sortie est l‟activité où l‟exécution des tests est évaluée en fonction des objectifs définis. Ceci devrait être fait pour chacun des niveaux de test.
Evaluer les critères de sortie contient les tâches majeures suivantes:
o Vérifier les registres de tests en fonction des critères de sortie spécifiés dans la planification des tests
o Evaluer si des tests supplémentaires sont requis ou si les critères de sortie doivent être changés
o Ecrire un rapport de synthèse des tests pour les parties prenantes

1.4.5 Activités de clôture des tests (K1)
Les activités de clôture des tests rassemblent les données des activités de tests terminées de façon à consolider l‟expérience, les testwares, les faits et les valeurs. Ces activités sont menées aux jalons d‟un projet, par exemple, quand un système logiciel est mis en production, un projet de test est terminé (ou annulé), un jalon est atteint, ou une version de maintenance est terminée.
Les activités de clôture des tests incluent les tâches majeures suivantes:
o Vérifier quels livrables prévus ont été livrés
o Clôturer les rapports d‟incidents ou créer des demandes d‟évolution pour ceux restant ouverts
o Documenter l‟acceptation du système

o Finaliser et archiver les testwares, environnements de test et infrastructures de test pour une réutilisation future
o Fournir les testwares à l‟organisation en charge de la maintenance
o Analyser les leçons apprises pour identifier les changements nécessaires pour les versions et projets futurs
o Utiliser l‟information collectée pour améliorer la maturité des tests
 

1.5 La psychologie des tests (K2)

Termes
Estimation d‟erreur, test indépendant.
Contexte
La tournure d‟esprit à utiliser pendant les tests et les revues est différente de celle utilisée lors de l‟analyse ou du développement. Avec la mentalité appropriée, des développeurs sont capables de tester leur propre code, mais affecter cette responsabilité à des testeurs permet typiquement de focaliser l‟effort et de fournir des bénéfices additionnels tels qu‟une perspective indépendante par des ressources de test entraînées et professionnelles. Les tests indépendants peuvent être effectués à n‟importe quel niveau des tests
Un certain degré d‟indépendance (évitant le parti-pris de l‟auteur) est souvent plus efficace pour détecter des défauts et des défaillances. L‟indépendance n‟est pas cependant un remplacement de la familiarité, et les développeurs peuvent efficacement trouver beaucoup d‟erreurs dans leur propre code. Plusieurs niveaux d‟indépendance peuvent être définis, comme les niveaux suivants présentés du plus faible au plus élevé :
o Tests conçus par la (les) personne(s) qui a (ont) écrit le logiciel à tester (niveau faible d‟indépendance).
o Tests conçus par une (des) autre(s) personne(s) (p.ex. de l‟équipe de développement).
o Tests conçus par une (des) personne(s) d‟un groupe différent au sein de la même organisation (p.ex. équipe de test indépendante) ou par des spécialistes de test (p.ex. spécialistes en tests de performance ou utilisabilité)
o Tests conçus par une (des) personne(s) d‟une organisation ou société différente (p.ex. sous-traitance ou certification par un organisme externe)
Les personnes et les projets sont dirigés par des objectifs. Les personnes ont tendance à aligner leurs plans en fonction des objectifs mis en place par le management et les autres responsables, par exemple, pour trouver des défauts ou confirmer qu‟un logiciel fonctionne. De ce fait, il est important de spécifier clairement les objectifs des tests.
L‟identification de défaillances pendant les tests peut être perçue comme une critique contre le produit et contre son(ses) auteur(s). Les tests sont, de ce fait, souvent vus comme une activité destructrice, même si c‟est très constructif dans la gestion des risques du produit. Rechercher des défaillances dans un système requiert de la curiosité, du pessimisme professionnel, un oeil critique, une attention au détail, une bonne communication avec ses pairs en développement, et de l‟expérience sur laquelle baser l‟estimation d‟erreurs.
Si des erreurs, défauts ou défaillances sont communiqués de manière constructive, l‟animosité entre les testeurs et les analystes, concepteurs et développeurs peut être évitée. Ceci s‟applique autant aux revues qu‟aux tests.
Les testeurs et le responsable des tests ont besoin de bonnes compétences relationnelles pour communiquer des informations factuelles sur les défauts, les progrès et les risques, de manière constructive. Pour l‟auteur du logiciel ou du document, une information sur les défauts peut permettre d‟améliorer leur savoir-faire. Les défauts trouvés et corrigés pendant les tests permettront de gagner du temps et de l‟argent plus tard, et de réduire les risques.
Des problèmes de communication peuvent survenir, particulièrement si les testeurs sont vus uniquement comme messagers porteurs de mauvaises nouvelles concernant des défauts.
Cependant, il existe plusieurs manières d‟améliorer la communication et les relations entre les testeurs et leurs interlocuteurs :
o Commencer par une collaboration plutôt que par des conflits – rappeler à chacun l‟objectif commun de systèmes de meilleure qualité
o Communiquer les découvertes sur le produit de façon neutre et factuelle sans critiquer la personne responsable, par exemple, écrire des rapports d‟incidents (ou des résultats de revues) objectifs et factuels
o Essayer de comprendre ce que ressent une autre personne et pourquoi elle réagit comme elle le fait
o Confirmer que l‟autre personne a compris ce que l‟on a dit et vice versa
 

1.6 Code d’éthique

L‟implication dans le test logiciel permet aux individus d‟avoir accès à des informations confidentielles et privilégiées. Un code d‟éthique est nécessaire, notamment pour assurer que les informations ne soient pas utilisées dans des cas non appropriés. En référence au code d‟éthique d‟ACM et de l‟IEEE pour les ingénieurs, l‟ISTQB définit le code d‟éthique suivant :
PUBLIC – les testeurs de logiciels certifiés doivent agir en fonction de l‟intérêt public
CLIENT ET EMPLOYEUR – les testeurs de logiciels certifiés doivent agir pour l‟intérêt de leur client et de leur employeur tout en respectant l‟intérêt public
PRODUIT – les testeurs de logiciels certifiés doivent assurer que les fournitures qu‟ils produisent (concernant les produits et les systèmes qu‟ils testent) répondent le plus possible aux standards professionnels
JUGEMENT – les testeurs de logiciels certifiés doivent conserver leur intégrité et leur indépendance dans leur jugement professionnel
GESTION – les chefs de projet de test de logiciels certifiés et les responsables doivent respecter et promouvoir une approche morale dans la gestion de projets de test de logiciels
PROFESSION – les testeurs de logiciels certifiés doivent mettre en avant l‟intégrité et la réputation du métier en cohérence avec l‟intérêt public
COLLEGUES – les testeurs de logiciels certifiés doivent être loyaux, aider leurs collègues, et promouvoir le partenariat avec les développeurs de logiciels
PERSONNELLEMENT – les testeurs de logiciels certifiés doivent participer en permanence à de la formation pour leur métier et doivent promouvoir une approche morale concernant sa pratique.