Chapitre I : Fondamentaux des tests

1.1.1- Les objectifs de test :

Evaluer les produits du travail : Les exigences, user stories conception et le code (évaluer ce qui
est demandé peut être il y a une contradiction)

Trouver les défauts et les erreurs

Assurer la couverture requise d’un objet de test

Réduire le niveau de risque de qualité logicielle

Vérifier si les exigences identifiées ont été remplies : comparer ce qui est fait par rapport à ce qui
est demandé

Vérifier qu’un objet de test est conforme aux exigences contractuelles légales et réglementaires

Fournir des informations aux parties prenantes afin qu’elles puissent prendre des décisions*

Renforcer la confiance dans la qualité de l’objet de test

Valider si l’objet de test est complet et fonctionne comme prévu par les parties prenantes

1.1.2- La différence entre tester et déboguer :

Les tests déclenchent les échecs causés par les défauts du système, le débogage consiste à
chercher les causes de ces défauts, les analyser et les éliminer.

 Le testeur a la responsabilité de :

Exécution des tests

Test de confirmation pour vérifier la correction

 Le développeur a la responsabilité de :

Débogage :

- Reproduction d’un échec

- Diagnostic (trouver la cause profonde)
- Réparer la cause

Tests unitaires du composant concerné par la panne

1.2.1- Importance des tests :

Identification et élimination des erreurs / Amélioration de la qualité de l’application

1.2.2 - Assurance qualité et test sont les mêmes ?

Ils ne sont pas identiques, les tests sont une forme de contrôle qualité.

 Contrôle qualité : centré sur le produit

 Assurance qualité : centrée sur le processus
QM > QA > QC >Tests

1.2.3 - Exemple :

Cause première : Problème de configuration du serveur : le serveur n’est pas correctement

configuré pour gérer les demandes de connexion.

Erreur : Un comportement imprévu dans le processus de connexion.

Défaut : La cause de l’erreur par exemple, si le logiciel ne valide pas correctement l’adresse
email saisie par l’utilisateur et permet une connexion avec une adresse invalide c’est un défaut
dans la fonctionnalité du logiciel.

Echec : Serait le résultat observable du défaut. Si l’utilisateur saisit une adresse email invalide et
parvient quand même à se connecter c’est un échec dans le processus de validation des
données.

Erreur → Défaut (bug) → Panne (Echec)

► Si on a un défaut, pas forcément on a un échec : Un défaut observable est un échec

► Si on a un échec toujours signifie qu’on a un défaut.

► Les défauts peuvent être des symptômes de problèmes systémiques dans le SDLC.

Pourquoi les erreurs se produisent-elles ?

Pression du temps

La faillibilité humaine

L'inexpérience et le manque de compétences

La complexité

L'incompréhension

Techniques nouvelles et non familières

1.3 – Les principes de test :

1- Paradoxe des pesticides

2- L'absence d'erreurs est une erreur

3-Les tests dépendent du contexte.

4- Les défauts se regroupent

5- Les tests montrent la présence de défauts et non leur absence

6- Les tests précoces permettent d'économiser du temps et de l'argent

7- Des tests exhaustifs sont impossibles

1.4.1 – Les activités de test :

Planification

Surveillance et contrôle

Analyse

Conception et mise en œuvre

Implémentation

Exécution

Achèvement

1.4.2 – Le logiciel de test de chaque activité :

Plan de test – calendrier et dates – registre des risques-critères d’entrée et

Planification de sortie

Rapports d’avancement – documentation des directives de contrôle et des

Surveillance et informations sur les risques
contrôle

Les conditions de test (priorisées) – Les critères d’acceptation – Rapport

Analyse des défauts dans la base de test

Cas de test (priorisées) – Chartes de test – Les éléments de couverture –

Conception et Les exigences en matières de donnés de test – Les exigences en matière
mise en œuvre d’environnement

Les procédures de test – Les script de test automatisés – suites de test –

Implémentation les donnés de test – Le calendrier d’exécution – les éléments de
l’environnement de test

Exécution Les journaux de tests et les rapports de défauts

Les rapports d’achèvement de test éléments d’action pour l’amélioration –

Achèvement les leçons apprises – les demandes de changement

1.4.3 – L’importance de la traçabilité :

3- La traçabilité des scénarios de test par rapport aux exigences peut vérifier que les exigences
sont couvertes par les scénarios de test

La traçabilité des résultats de test jusqu'aux risques peut être utilisée pour évaluer le niveau de
risque résiduel dans un objet de test

Une bonne traçabilité permet de déterminer l’impact des changements, facilite les audits de tests
et contribue à répondre aux critères de gouvernance informatique

La traçabilité fournit des informations permettant d'évaluer la qualité des produits, la capacité des
processus et l'avancement du projet par rapport aux objectifs commerciaux

1.4.4 – Les rôles de test :

Le rôle de gestion des tests assume la responsabilité globale du processus de test, de l’équipe
de test et de la direction des activités de test. Il se concentre principalement sur les activités de
planification des tests, de surveillance et de contrôle des tests et de réalisation des tests.

Le rôle de test assume la responsabilité globale de l’aspect ingénierie (technique) des tests. Il se
concentre principalement sur les activités d'analyse des tests, de conception de tests, de mise en
œuvre et d'exécution des tests.

1.5.1 – Compétences génériques requises pour les tests :

Connaissances en matière de tests (pour augmenter l'efficacité des tests, par exemple en
utilisant des techniques de test) Minutie, prudence, curiosité, attention aux détails, être
méthodique (pour identifier les défauts, en particulier ceux qui sont difficiles à trouver

Bonnes compétences en communication, écoute active, esprit d'équipe (pour interagir

efficacement avec toutes les parties prenantes, transmettre des informations aux autres, être
compris, signaler et discuter des défauts)

Pensée analytique, pensée critique, créativité (pour augmenter l'efficacité des tests)

Connaissances techniques (pour augmenter l'efficacité des tests, par exemple en utilisant des
outils de test appropriés)

Connaissance du domaine (pour être capable de comprendre et de communiquer avec les

utilisateurs finaux/représentants de l'entreprise)

1.5.2 - Approche de l’équipe intégrée :

Dans l'approche d'équipe globale, tout membre de l'équipe possédant les connaissances et les
compétences nécessaires peut effectuer n'importe quelle tâche, et chacun est responsable de la
qualité.
Les membres de l’équipe partagent le même espace de travail (physique ou virtuel), car la
colocalisation facilite la communication et l’interaction

 Rôle des testeurs :

Collaborer avec les représentants des entreprises pour les aider à créer des tests d’acceptation
adaptés.

Travailler avec les développeurs pour convenir de la stratégie de test et décider des approches
d'automatisation des tests.

1.5.3 – Les avantages de l’indépendance des tests :

Les testeurs indépendants sont susceptibles de reconnaître différents types de pannes et de

défauts par rapport aux développeurs en raison de leurs différents parcours, perspectives
techniques et préjugés.

1.5.3 - Les inconvénients de l’indépendance des tests :

Les testeurs indépendants peuvent être isolés de l’équipe de développement, ce qui peut
entraîner un manque de collaboration, des problèmes de communication ou une relation
conflictuelle avec l’équipe de développement.

Les décisions en matière de test peuvent être influencées par :

 Facteurs externes Facteurs internes

L’intérêt des parties prenantes Le modèle SDLC

Les lois générales Le budget
Le domaine Les ressources
Les normes applicables Le temps
La complexité globale du système

Stéréotype négative :

Porteur de mauvaises nouvelles :

 Solution : Etablir une relation avec les développeurs / Montrer que tu es là pour les soutenir
et les aider.

Trop critique :

 Solution : Les rapports des bugs et la communication doivent être constructives, claires et
informatives et surtout pas de critique.

Biais de confirmation :

Tendance à privilégier les informations qui confirment ou soutiennent nos croyances et nos
valeurs, souvent au détriment des faits.

 Les développeurs : ne veulent pas de travail supplémentaire (correction des bugs) :

tendance à rechercher la preuve que le logiciel fonctionne correctement.
 Les testeurs pensent le contraire : tendance à toujours penser qu'il y a encore un bug à
trouver.

L’Etat d’esprit dus testeur doit contenir :

 Curiosité
 Pessimisme professionnel
 Regard critique
 Attention aux détails
 Motivation pour une communication et des relations bonnes et positives