Chapitre1: Les fondamentaux des tests

1.1 Qu'est-ce qu’un test?

1.2 Pourquoi les tests sont-ils nécessaires ?

1.3 Les sept principes généraux des tests

1.4 Processus de test

1.5 La psychologie des tests

1.1 Qu'est-ce qu’un test?

(K1) Identifier les objectifs habituels des tests

1. évaluer les produits d’activités tels que les exigences, les User Stories, la

conception et le code

2. vérifier si toutes les exigences spécifiées ont été satisfaites

3. valider si l'objet de test est complet et fonctionne comme attendu par les

utilisateurs et autres parties prenantes

4. Construire la confiance dans le niveau de qualité de l'objet de test

5. Prévenir des défauts

6. Trouver des défaillances et des défauts

7. Fournir suffisamment d'information aux parties prenantes pour leur permettre

de prendre des décisions éclairées, en particulier en ce qui concerne le niveau

de qualité de l'objet de test

8. Réduire le niveau de risque d'une qualité logicielle inadéquate (p. ex. des

défaillances non détectées auparavant se produisant en opération)

9. Se conformer aux exigences ou aux normes contractuelles, légales ou

réglementaires, et/ou pour vérifier la conformité de l’objet de test à ces

exigences ou normes.
 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
Le test a pour objectif de
• Mettre en évidence les défauts d’un logiciel
• Prouver la conformité fonctionnelle
• Donner une indication de la qualité du logicielle => un niveau de
confiance
• Prévenir des défauts

Comment peut-on prévenir les défauts?

Verification Vs Validation :

Verification : • Est-ce que nous avons bien construit le produit? (produit en marche)
Validation : • Est-ce que nous avons construit le bon produit?
Tests et qualité (K2) ISO 25010

Les tests logiciels sont un moyen d’évaluer la qualité du logiciel et de réduire le

risque de défaillance de logiciel lors de son fonctionnement

Facilité d’utilisation : User Experience

Fiabilité : Maturité Tolérance aux pannes
Aptitude fonctionnelle : Répond aux besoins fonctionnels
Efficacité du rendement : Performance, charge, stress
Maintenabilité : Effort pour les évolutions
Portabilité : Transfert vers un autre environnement
Compatibilité : Interopérabilité
Securité : Accès à des informations autorisées

Combien de test est-ce suffisant? (K2)

✓ Ca dépend du risque sur le système

Prendre en compte l’évaluation des risques

comment faire un minimum de tests pour un minimum de risques

Test vs Debogage :

*Test est l'exploration du système

afin de trouver des défauts
*Debogage est un processus de
détermination des causes des
erreurs (bugs) dans un code et de
les corriger
1.2 Pourquoi les tests sont-ils nécessaires ?

• Les systèmes logiciels deviennent une part de notre existence, des applications
commerciales aux produits de grande consommation

• Des logiciels ne fonctionnant pas correctement peuvent générer de nombreux problèmes:

pertes financières, temps, réputations, allant même aux blessures ou mort

• Il est important de détecter et de corriger ces défaillances avant qu’elles soient livrés aux
clients

1.2.1 Contribution des tests au succès

* involvemennt of testers requirement reviews and userStory refinement.
* testers working closely with system designers.
*Having testers work closely with developers
* Testers verifying and validating the software before its release

1.2.2 Assurance qualité et test

• La gestion de la qualité comprend toutes les activités qui dirigent et contrôlent une
organisation en matière de qualité

• L’assurance qualité est principalement axée sur le respect des processus adéquats, afin de
donner l'assurance que les niveaux de qualité appropriés seront atteints (processus, produits
d’activité de bonne qualité, causes des erreurs, application des résultats de rétrospective)

• Le contrôle de la qualité comprend diverses activités, y compris des activités de test, qui
contribuent à l'atteinte de niveaux de qualité adéquats.

1.2.3 Erreurs, défauts et défaillances

1/ Les erreurs peuvent survenir suite à de nombreuses raisons, telles que :

- Les contraintes de temps, la faillibilité humaine, l’inexpérience ou le manque de

compétence des participants au projet

- Une mauvaise communication entre les participants au projet, y compris au sujet des
exigences et de la conception

- La complexité du code, de la conception, de l'architecture, du problème sous-jacent à

résoudre, et/ou des technologies utilisées

- Les malentendus sur les interfaces intra-système et inter-système, en particulier lorsque de

telles interfaces intra-système et inter-système sont très nombreuses.

- Des technologies nouvelles, peu connues

- la pollution peuvent causer des défauts dans le firmware

2/ Les défaillances peuvent être causées par :

- Une erreur humaine causée par une échéance serrée, complexité du code, infrastructure ou
multiple interaction entre les systèmes

- Une condition d’environnement (radiation, magnétisme, pollution, etc.)

3/ • Erreur= méprise => Défaut(=Bug) => Défaillance qui peut être aussi causée
par les conditions de l’environnement
• En effectuant des tests, il est possible de mesurer la qualité des logiciels en termes
de défauts trouvés
• En comprenant les causes principales 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
=> 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é
(e.g., en utilisant des standards de développement, de la formation et de
l’analyse des défauts) • C’est l’aspect d’aide à la décision => en prenant en compte le niveau
de risque
1.3 Les sept principes généraux des tests

1.4 Processus de test

➢ Le processus de test dans le contexte :

*Les facteurs contextuels qui influencent le processus de test d'une organisation

comprennent
− Le modèle de SLC et les méthodologies de projet utilisées
− Les niveaux de test et les types de test prévus
− Les risques liés aux produits et aux projets
− Le domaine d’activités
*Les contraintes opérationnelles incluent
− Les budgets et ressources
− Les délais
− La complexité
− Les exigences contractuelles et réglementaires, etc
 ➢ Activités et tâches de test :
1. Plannification des tests : La planification des tests implique de définir les objectifs du
test et
l’approche retenue pour atteindre les objectifs du test dans le respect des contraintes
imposées par le contexte

2. Suivit et contrôle de test (« definition of done ») : Le pilotage des tests implique la

comparaison régulière de l’avancement réel par rapport au plan de test à l'aide des métriques
de pilotage définies dans le plan de test

3. Analyse de test (quoi)

Activité 1: Analyser les bases de test appropriées au niveau de test considéré (UML, epics,
US, spec, l’implémentation de la base des composants ou du système, rapport d’analyse de
risque fonctionnel , non fonctionnel et structurel, métier)
Activité 2 : Evaluer les bases de test et des éléments de test pour identifier des défauts de
différents types (Ambiguïtés, Omissions, Incohérences Inexactitudes, Contradictions
déclarations superflues)
Activité 3: Identifier les caractéristiques (éléments) et les ensembles de caractéristiques à
tester
Activité 4: Définir et prioriser les conditions de test pour chaque caractéristique en fonction
de l’analyse des bases de test et en tenant compte des caractéristiques fonctionnelles, non-
fonctionnelles et structurelles, des autres facteurs métiers et techniques, et des niveaux de
risque
Activité 5: Capturer la traçabilité bidirectionnelle entre chaque élément des Conception des
tests
activités d’analyse de test ne se contentent pas de vérifier si les
exigences sont cohérentes, correctement exprimées, et complètes,
mais aussi de valider si les exigences capturent correctement les
besoins des clients, utilisateurs et des autres parties prenantes
4. Conception des tests (Comment tester?)
• Concevoir et prioriser les cas de test et les ensembles de cas de test
• La déclinaison des conditions de test en cas de test et ensembles de cas de test lors
de la conception des tests implique souvent l’utilisation de techniques de test
 5. Implementation de test (Est-ce que tout est en place pour exécuter les
tests?)
• Développer et prioriser les procédures de test, et, éventuellement, créer des scripts de
test automatisés

•Construire l’environnement de test (y compris, potentiellement, les harnais de test, la

virtualisation des services, les simulateurs et d’autres éléments d’infrastructure) et vérifier
que tout le nécessaire a été correctement mis en place

 Les tâches de conception et d’implémentation des tests sont souvent combinées.

Dans le cas des tests exploratoires et d’autres types de tests basés sur l’expérience, la
conception et l’implémentation des tests peuvent être réalisées et éventuellement
être documentées lors de l’exécution des tests.

6. Execution des tests

• Enregistrer les IDs et les versions des éléments de test ou de l’objet de test, des
outils de test et des testware
• Vérifier et mettre à jour la traçabilité bidirectionnelle entre les bases de test, les
conditions de test, les cas de test, les procédures de test et les résultats des tests
• Test de confirmation et de régression

7. activité de cloture des test :

• Vérifier si tous les rapports de défauts sont clôturés, et saisir des demandes de
modification ou des items du backlog du produit pour tous les défauts non résolus à
la fin de l’exécution des tests
• Créer un rapport de synthèse de test à communiquer aux parties prenantes
➢ Les produits d’activités du test :
Produits d’activités de la planification des tests
Le plan de test comprend des informations sur les bases de test,
critère E/S,
risque

Produits d’activités du pilotage et contrôle des tests

-les rapports d'avancement des tests,
-synthèse des tests,
-un résumé des résultats de l'exécution

Produits d’activités de l’analyse de test

les conditions de test définies et priorisé
*Pour les tests exploratoires, l'analyse de test peut impliquer la création de
chartes de test

Produits d’activités de la conception des tests

La conception de cas de tests de haut niveau, affiner ou finaliser les condition ,
les données, environnement

Produits d’activités de l’implémentation des tests

− Les procédures de test et l’ordonnancement de ces procédures de test
− Les suites de test
− Un calendrier d'exécution des tests

Produits d’activités de l’exécution des tests

La documentation du statut de chaque cas de test ou des procédures de test
Les rapports de défauts
La documentation précisant quel(s) élément(s) de test, objet(s) de test, outils
de test et testware ont été impliqués dans le test.
Produits d’activités de la clôture des tests
• les rapports de synthèse de test
• les mesures à prendre pour améliorer les projets ou les itérations ultérieurs

➢ Traçabilité entre les bases de test et les produits d’activités du test :

 • il est important d'établir et de maintenir la traçabilité tout au long du processus de
test entre chaque élément des bases de test et les divers produits d'activités du test associés
à cet élément. En plus de l'évaluation de la couverture de test, une bonne traçabilité facilite
• L’analyse de l'impact des changements, L’audit des tests· La satisfaction des critères
de gouvernance IT
• L’amélioration du caractère compréhensible des rapports d'avancement des tests et
des rapports de synthèse de test

5 La psychologie des tests :

Il existe plusieurs manières d’améliorer la communication et les relations entre les testeurs et
leurs interlocuteurs :

• Commencer par une collaboration plutôt que par des conflits – rappeler à chacun l’objectif
commun de systèmes de meilleure qualité

• 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

6. Niveaux de Tests (chapitre2 P9)

1. Test de composants / unitaires :

Objectif : empecher les defauts de passer à niveaux de test plus elevés

Bases de tests: Exigences des composants, conception détaillée (par unité), Code,
Modèle de données
Objets habituels de test: Composants, programmes, conversions de données /
utilitaires ou programmes de migration, modules de bases de données
Défauts et défaillances courants : Fonctionnalité incorrecte/ Problèmes de flux de
données/ Code et logique incorrects
2. Tests integration

Objectif : Test d’intégration des composants teste les interactions entre les
composants logiciels (fait après test de composant)
Et l’interaction entre les différents systèmes (fait après test système)

Bases de test : Diagrammes de séquence, Spécifications des protocoles d’interface et

de communication, Cas d’utilisation, Workflows, Conception du logiciel et du système

Objets de test : Sous-systèmes, Interfaces, Micro-services, Bases de données, APIs

Défauts et défaillances courants : Défaillances dans la communication entre les

systèmes / Structures de message incohérentes entre les systèmes

3. Test système :

Objectifs : Réduire les risques

• Vérifier si les comportements fonctionnels et non-fonctionnels du système sont tels
qu'ils ont été conçus et spécifiés
• Valider que le système est complet et fonctionnera comme prévu…

Bases de test : Ces tests sont opérés par une équipe de test indépendante, ils
peuvent être aussi bien fonctionnels que non-fonctionnels
Ils peuvent aussi être des tests boîte blanche (basées sur les structures) ou boîte
noire (basées sur les spécifications avec une table de décision par exemple)

Objets de test : Système , application

Défauts et défaillances courants : • Calculs incorrects /Comportement fonctionnel ou

non-fonctionnel du système incorrect ou inattendu
 4. Tests d’acceptation
C’est la responsabilité du client finale ou the user finaux du systèmes
L’objectif est d’établir un niveau de confiance par rapport au logiciel
Les tests d’acceptation peuvent évaluer si le système est prêt à être déployé et utilisé,
*Tests d’acceptation utilisateur qui vérifient l’aptitude et l’utilisabilité du système par
des utilisateurs.
* Tests (d’acceptation) opérationnelle qui englobe les tests des backups et
restaurations; la reprise après sinistre; la gestion des utilisateurs; les tâches de maintenance;
les chargements de données et tâches de migration; la vérification périodique des
vulnérabilités de sécurité.
* Tests d’acceptation contractuelle et réglementaire
5. Les Alpha tests sont exécutés sur le site de l’organisation effectuant le développement
mais pas par les équipes de développement
6. Les Béta tests ou tests sur le terrain sont exécutés par des personnes sur leurs sites
propres.
 7. Les Types de tests : (Il est possible d'effectuer n'importe quel type de à n'importe quel
niveau de test)

Les Tests Fonctionnels (couverture):

• Les tests fonctionnels concernent le comportement extérieur du logiciel (tests boîte
noire) et peuvent être exécutés à tous les niveaux de tests.
• Interopérabilité
Les Tests Non-Fonctionnels (couverture) :
• Les tests non-fonctionnels incluent, sécurité mais pas uniquement, les tests de
performances, tests de charge (grand nombre d’utilisateurs), tests de stress, tests
d’utilisabilité, tests de maintenabilité, tests de fiabilité et les tests de portabilité.

Les Tests de la Structure / Architecture Logicielle (Tests Structurels) :

A tous les niveaux de tests, mais spécialement dans les tests de composants et les
tests d’intégration de composants, des outils peuvent être utilisés pour mesurer la
couverture du code
Tests liés aux changements :
Quand un défaut est détecté et corrigé, le logiciel devrait être re-testé pour confirmer que le
défaut original a été correctement ôté. Ceci est appelé test de confirmation

Ré-exécuter des tests sur un programme déjà testé s’appelle « test de régression ». Cela se
fait après que des modifications du programme aient eu lieu.

Les tests de régression peuvent être exécutés à tous les niveaux de tests, et
s’appliquent aux tests fonctionnels, non-fonctionnels et structurels ; ce sont les bons candidats à
l’automatisation.
 8. Tests de maintenance
Les tests de maintenance sont effectués sur un système opérationnel existant et sont
déclenchés par des modifications, migrations ou suppression de logiciels ou de systèmes.
Selon le changement, les tests de maintenance peuvent être effectués à chacun ou à tous les
niveaux de tests et pour certains ou tous les types de tests (selon l’analyse d’impact)

L'analyse d'impact peut être effectuée avant qu'un changement ne soit apporté, pour
aider à déterminer si le changement devrait être apporté en fonction des conséquences
potentielles dans d'autres parties du système.