Introduction aux concepts et techniques

de test logiciel

Tests logiciels : tester le fonctionnement d’un software dans un environnement contrôlé, et

essayer de trouver des problèmes dans ce logiciel .

Assurance qualité logicielle : c'est l'ensemble des processus de développement logiciel

qui englobe l'amélioration, la surveillance, et la résolution de tous les problèmes (prévention)

l'objectif de testing :
- Satisfaire les exigences
- Trouver des défauts
- Prévenir les défauts
- Vérifier si les normes sont respectées
- Fournir des informations aux décideurs

Erreur : une personne commet une erreur.

Bug : une déviation du résultat réel par rapport au résultat attendu. le résultat d'une erreur.
Failure : peut résulter d'un bug.

Il existe deux types de bugs : les bugs logiciels et les bugs de spécification. Les bugs de
spécification signifient que la documentation ou les spécifications du logiciel sont
insuffisantes, peu claires ou non conviviales pour l'utilisateur.
Parfois, on peut rencontrer des cas où la société n'a pas de spécifications logicielles. Pour
cette raison, on peut les obtenir à partir d'autres sources :
- Normes : Se référer au domaine dans lequel on travaille et examiner les règles
suivies par les professionnels de ce domaine, puis faire de même.
- Communication : Communiquer avec des personnes plus expérimentées dans le
domaine du test pour obtenir des informations.
- Statistiques : Utiliser des données statistiques pertinentes.
 - Expérience de vie : Exploiter mes propres expériences pour résoudre les problèmes
causés par l'absence de spécifications logicielles.

Le testeur, dans la phase de test, doit tester l’application avec des données valides et des
données invalides.

Traitement des bugs : Après avoir trouvé les bugs, on les enregistre dans un système de
suivi des bugs pour faciliter la communication avec les développeurs.

bug process

Parmi les outils utilisés pour le système de suivi des bugs, on trouve :

- Excel
- Bugzilla
- BugHost

Au niveau des tests, il existe des vocabulaires à comprendre :

● Test case : où le testeur écrit tous les tests à exécuter pour tester chaque partie du
logiciel et compare si les résultats actuels sont similaires à ceux attendus. S'il trouve
un bug, il le signale.
● Test procedure : les étapes suivies pour réaliser les test cases.
● Test execution : l'exécution des étapes des test cases, ce qui nous indique si le test
a échoué (test fail), réussi (test pass) ou est bloqué (test block).
● Test suite : ensemble des test cases.

test case attribut :

ER : Résultat attendu du test case (Expected Result).

Recision history : Contient qui a effectué le test, quand il l'a fait, ce qu'il a modifié, quand et
pourquoi le test a été modifié.

Des pratiques à éviter dans les tests :

● Dépendance entre les tests : Un test case peut être modifié ou supprimé, donc
éviter les dépendances entre les tests.
● Description médiocre des test cases et éviter les abréviations : Assurez-vous
que les test cases sont clairement décrits et évitez d'utiliser des abréviations qui
pourraient rendre la compréhension difficile.

testing level :
- Unit testing : Le test est effectué sur la plus petite partie du projet par le
développeur.
● why : Parce que les bugs se trouvent souvent dans les plus petits modules, il
est donc plus facile pour le développeur de les découvrir et de les corriger, ce
qui économise du temps et des coûts.
- Integration testing : On regroupe les modules afin de tester leur bon
fonctionnement ensemble.
● why : Dans cette phase, on s'assure que l'interaction entre les sous-
systèmes se déroule bien. De plus, certains modules peuvent être achetés et
ne sont pas testés en unit testing.
● Il existe des type d integration test :
- Big bang test : Teste tous les modules à la fois (déconseillé).
- Bottom-up integration test : Tester les modules individuellement
puis avec d'autres modules afin de tester l'interaction entre tous les
modules.
- Top-down integration test : On commence par les modules les plus
grands pour terminer par les plus petits modules.

Parfois, dans les tests, on peut rencontrer des cas où certains modules n'existent pas.
Pour résoudre ce problème, on utilise des "stubs" pour le test top-down et des "drivers" pour
le test bottom-up.
Ce principe s'appelle le scaffolding.
- System testing : Tester le système avec de vraies données en entrée. Il existe deux
types de tests à cette étape
- Functional test : Tester le logiciel en se basant sur les exigences.
- Non-functional test : Tester le logiciel pour évaluer sa capacité à supporter
différents aspects tels que le temps, la sécurité, la compatibilité, l'environnement, etc.

- accepting test :Test effectué par le client lui-même pour vérifier si le produit est
compatible avec les exigences. Ce type de test se déroule en deux étapes :
1. Alpha testing : se déroule dans l'environnement de développement
en présence du client.
2. Beta testing : se déroule dans l'environnement réel du client et se fait
sans la présence du développeur.
test case design technique :
Le test case design technique va nous permettre :
- d'écrire le test approprié pour chaque partie du logiciel,
- de déterminer le nombre de lignes adéquates pour le test,
- d'écrire le minimum de test cases nécessaires.
Le test design se divise en deux catégories :
- black box testing techniques

Ce type de test est approprié pour les dernières étapes de test (tests système, tests
d'acceptation).

- Techniques de test boîte blanche (White box testing techniques) : Je vois le

code, je connais la structure du code, et ce type de test est approprié pour les deux
premières étapes de test (tests unitaires, tests de module).

Le test peut avoir deux objectifs :

● Test to pass : Le test est écrit pour s’assurer que le logiciel satisfait au minimum les
exigences. Il s'agit d'un test simple.
● Test to fail : Le test est écrit de manière complexe pour essayer de trouver des
bugs.

black box techniques :

- equivalence partitioning : Utilisée lorsqu'on a une entrée qui peut avoir une
plage de données. On divise les données de test en deux groupes : données valides
et données invalides. De cette façon, on aura un nombre minimum de test cases.
- boundry value : Consiste à tester les extrêmes de la plage de valeurs. Par
exemple, pour une plage de (0, 100), on teste les valeurs aux extrémités.

N.B : La boundary value est appliquée uniquement sur les nombres.

- Decision table : Ce type de test est utilisé lorsqu'on a des conditions "if". C'est un
tableau contenant un sous-tableau des sorties qui prend les actions possibles et un
autre tableau des entrées correspondant à chaque combinaison d'entrées, comme le
montre le tableau suivant :

- State transition : Dans ce type de test, on prend tous les états et on schématise
l'action de transition d'un état à un autre comme suit :

À partir de ce diagramme, on réalise un tableau d'états (state table) illustrant toutes

les transitions possibles :
 - On peut utiliser les diagrammes de cas d'utilisation pour extraire les test cases.

white box techniques :

Statement test : Le but est d'exécuter toutes les lignes du code avec un minimum
de test cases.

Decision test : Ce test vérifie que toutes les décisions sont exécutées ou testées.
Ce type de test est appliqué lorsqu'on a des conditions "if".

Statement coverage : Nombre des lignes couvertes.

 ISTQB foundation level
Chapitre 1 : les fondamentale de test
- 7 testing principle
early testing : On doit commencer le test le plus tôt possible.
absence of error fallacy : Si le produit ne satisfait pas les exigences du client, même si on
identifie plusieurs erreurs et qu'on les corrige, le produit ne va pas bien fonctionner.
testing shows presence of defects : Le test permet d'identifier les bugs mais on ne peut
pas dire que le logiciel ne contient pas de bugs.
testing context dependent : Le test se fait d’une manière différente pour chaque logiciel.
default clustering : Concentrer les tests sur des modules qu’on pense qu’ils peuvent
contenir plusieurs bugs.
pesticide paradox : Après chaque modification dans un module, on doit changer le
processus de test sur ce module pour découvrir de nouveaux bugs.
exhaustive testing : Tester toutes les possibilités dans la phase de test est impossible,
c’est pourquoi on travaille avec les principes de la priorité et du risque élevé.
- fundamental test process
Réellement, le test pour n’importe quel logiciel contient cinq activités principales :
Test planning and control : Cette activité se compose de deux parties. La première partie
est la planification des tests, où nous définissons les objectifs de test (ex : trouver le
maximum de bugs). La deuxième partie est le contrôle des tests, où nous surveillons toutes
les activités de test tout au long de la réalisation du projet. Cela se fait en comparant ce qui
est planifié avec la progression actuelle et en déclarant toute déviation, ce qui nous pousse
à replanifier les objectifs.
test analysis and design : Cette activité se compose de deux parties. La première partie
est l'analyse des tests, où nous faisons une révision de la base des tests (exigences, niveau
d'intégrité du logiciel, rapport d'analyse des risques, structure du logiciel et interface du
logiciel) et précisons les éléments testables parmi ces derniers, appelés conditions de test.
La deuxième partie est la conception des tests, où nous définissons les cas de test avec une
priorité descendante, les données de test, l'environnement de test, l'infrastructure et les
outils nécessaires, afin de construire un fichier où nous rédigeons toutes les conditions de
test avec les cas de test (traçabilité bidirectionnelle).
test implementation and execution :

La mise en œuvre pour les cas de test inclut la création de la procédure de test (déjà
expliquée dans le premier fichier) et la suite de tests qui rassemble tous les cas de test. De
plus, nous avons besoin de données de test, de harness (drivers et stubs), d'un
environnement de test et enfin d'une traçabilité bidirectionnelle (fichier de feuilles).
La deuxième étape est l'exécution, qui se fait soit manuellement, soit avec un outil de test.
On exécute les cas de test, puis on compare les résultats actuels avec les résultats
attendus. Ensuite, on reporte toutes les informations sur les cas de test (nom du testeur,
date d'exécution, résultat du test, etc.), et cette action est appelée logging ou recording.
Puis, on effectue un test de confirmation pour vérifier si les bugs sont corrigés ou non, et si
c'est le cas, on le déclare.
N.B : après la fixation d’un bug dans un module on doit faire des tests sur d’autre module
pour vérifier si la fixation du bug n’a pas affecter d’autre module ce qu’on appel regression
test
evaluating exit criteria and reporting :
exit criteria : Ce sont les objectifs qui, lorsqu'ils sont atteints, permettent d'arrêter les tests
(ex : coût ou temps, défauts trouvés, etc.). Ces critères de sortie sont déterminés à partir du
logging, ce qui permet de décider si nous devons tester davantage ou modifier les critères
de sortie. Le reporting consiste à écrire une conclusion générale pour indiquer où nous en
sommes et ce que nous avons accompli.

test closure activities :

check : Indiquer ce qui a été délivré et ce qui ne l'est pas encore.

closing : Terminer tous les rapports et les modifications qui ne sont pas encore achevés.
documenting : Mentionner que le système est accepté.
finalizing archiving : Archiver le matériel de test (harness, outil utilisé, cas de test, etc.).
puis handover , pour donner testware à l'organisation de maintenance
- The psychology of Testing
indépendance du test :
Le fait de confier la fonctionnalité de testing à une autre personne que le développeur est
très important :
● Le testeur se concentre totalement sur les tests.
● Il a une grande capacité à trouver des défauts.
et cette indépendance a 4 niveau :
1- le test se fait par développeur
2- le test se fait par une autre personne appartient à l'équipe de développeur
3- le test se fait par une personne appartient à un autre organisation groupe dans
l’entreprise
4- le test se fait par une personne appartient à une autre entreprise
la communication entre les membres de l'équipe :
les membre de l'équipe doivent savoir
● faut savoir tout d’abord que le testing exige : la curiosité , une vision critique , une
attention au détails , une expérience pour deviner l’erreur
● identifier les défaut peut optimiser l’argent , le temps de le fixer après la diffusion
● identifier les défaut peut aider le développeur pour développer ses compétence
le testeur de son part :
● avoir l’attitude de travailler collectivement
● essayer de comprendre les autres
● s’assure que les autres vous a bien compris
● les resultat de test doit être délivré à la personne concernée singulièrement
Chapitre 2 : Software development life cycle :
SWDLC :
Provient de l'ISO 12207 (organisation qui a rassemblé toutes les règles et les standards
pour les ingénieurs en logiciel et les modèles SDLC).
les types de SWDLC :
● modèle séquentiels : waterfall et V model
waterfall :

- avantage : simple à utiliser , chaque étape a ses propre exigence , chaque

étape est exécutée complètement après qu’on passe à une autre et ce
modèle est plus adéquat pour les petits projets
- disadvantage : une difficulté pour modifier dans le projet , un risque au
niveau du projet puisqu’on ne sait si le projet mache qu'à la fin
V-model : v-model est une sorte d'amélioration de waterfall vu que le test se fait
dans chaque niveau de développement
 - avantage : Il est simple à utiliser et permet de gagner du temps puisque les
activités de test commencent tôt, ce qui nous permet de découvrir des défauts tôt et de les
corriger rapidement.
- disadvantage : Il ne permet pas de modifier le projet, ce qui le rend moins
flexible.
● les modèles itératives :Dans ce modèle, on divise le cycle de vie en de petits cycles
où l'on effectue le design, le développement et le test, puis on répète ces étapes
plusieurs fois afin d'obtenir le produit final. Ce qui est particulier dans ce modèle,
c’est qu’on peut commencer même si on n'a pas toutes les exigences, mais il
nécessite toujours des tests de régression.
ex :

● itérative incrémentale modèle : utilise simultanément les modèles itératif et

séquentiel. On doit avoir toutes les exigences, puis à partir de chaque exigence, on
les divise de manière à avoir plusieurs cycles de vie. Chaque cycle de vie résulte en
un module fonctionnel. On répète ce processus itératif sur les exigences pour obtenir
le produit final. Parmi les exemples de ce modèle, on trouve le prototypage, le RAD
(développement rapide d'applications), le RUP (processus unifié rationalisé) et les
modèles de développement Agile.
ex:
la différence entre vérification test et validation test :
dans vérification on vérifie si le projet respect les exigence du client et dans validation on
vérifie si le projet peut accomplir les besoin du clients
les types de test :
1. le test fonctionnel (black box) : dans cette étape on répond à une question qui est
que fait le système c’est pour cela on test les fonctionnalités du système selon les
exigence ( ex : software sous forme d’une calculatrice => test : tester le calculatrice
s’il fait tout type de calcul mentionnée dans les exigence ) et le test fonctionnel a des
sous type :
● test de sécurité
● interoperability testing : tester le software s’il marche avec d’autre
component externe ou non
● suitability testing : vérifier si le système répond à toutes les exigences
● accurateness : vérifier si le AR sont les même que ER
2. le test non-fonctionnel (black box) : dans cette étape on répond à une question
comment le système fonctionne , on teste par exemple performance , stress ,
portabilité , maintenabilité , reliabilité …
3. le test structuré (white box testing ) : s'intéresse par la structure interne du système
et dans ce type de test on utilise une technique s’appelle code coverage ou on traite
le nombre de ligne teste
4. testing related to change : c’est un test ce fait après la fixation d’un défaut ce qu'on
appelle confirmation test , et cela va résulter un autre type de test qui est regression
test ( déjà expliqué )
test de maintenance :
après la délivrance du produit au client il se peut que le client veut changer quelque chose
dans software , ou changer l’environnement … c’est pour cela on a besoin de test de
maintenance et ce type de test se fait en 3 cas :
1. test de maintenance pour la modification
2. test de maintenance pour la migration d’un environnement à un autre
3. test de maintenance pour la retraite est fait dans les cas ou on est besoin de retirer
qlq modules
le teste de maintenance devient difficile parfois si on a pas de spécification
Chapitre 3 : Technique statique
Le test peut se faire en deux phases : soit dans la phase d'exécution, on parle de test
dynamique, soit avant l'exécution, on parle de test statique. Ce dernier se divise en deux :
Review : on détermine les fautes commises dans les documents sans exécuter le
code manuellement.
Static analysis : on vérifie la qualité du code en utilisant des outils qui automatisent
cette tâche.

review process :
review process se déroule de deux manières : soit de manière informelle entre les membres
de l'équipe sans documentation, seulement par une discussion verbale, soit de manière
formelle, ce qui se compose de 6 étapes :
1. planning : contient
● entry criteria : on vérifie si document est disponible
● review criteria
● roles et responsibility
● selecting part concerned with review
● exit criteria
2. kick off meeting : la distribution de document à revoir en définissant les objectif de
review
3. individual preparation : chaque membre prendre une partie du document a revoir et
vérifie s’il y a un potentiel de défaut , et prépare les observations et le question pour
review meeting prochain
4. review meeting : pour discuter les observations et les questions de chaque membres
5. rework : on donne les document à son propriétaire pour corriger les défauts et il doit
documenter tout sorte de modification
6. follow-up : on vérifie si les défauts sont fixe ou non
- les rôles et les responsabilités :
Pour passer d'un review informel à une review formel, il existe d'autres types de review où la
formalité augmente.
informal : comme il est déjà mentionné il se fait verbalement , et l’avantage de cette
méthode c’est d’avoir quelque gain et prendre l’avis d’un spécialiste d’une manière moin
cher
walkthrough : l’auteur qui dirige review et qui peut contient pre-review meeting et des
rapport de cette révision , et le but derrière cette méthode c’est que les reviewers prend le
maximum des information d’author
technical review : dans ce type on fait en révision de document avec la présence des
personne avec une grande background technique et le meeting est dirigé par moderateur
inspection review ( very formal ) : ressemble au technical review

- le facteurs du succès pour une révision :

static analysis :
pour static analysis utilise les outils de test statique qui nous donne les résultats sous forme
de fichier xml ou html , en plus il nous donne la defaut et son localisation dans le code
source , et ce type de test nous permettre de découvrir des chose qu’on ne peut pas les voir
si on utilise dynamique test :

et ce type de test est souvent utilisé par les développeurs pour vérifier s’il respecte les
règles de codage
Chapitre 4 : Test design techniques
- test development process

- category of test design techniques

Principalement, il existe trois techniques : black box test design, white box test design et
experience-based test design, qui sont plus expliquées dans ce lien:
link : [Link]
- black-box techniques
● equivalence partition
● boundary value analysis
● decision table testing
● state transition testing
ces technique sont déjà abordé dans le premier document
- white-box techniques
● statement test
● decision test
- experience-based techniques
C'est une technique informelle mais très importante où le testeur utilise son expérience pour
détecter les défauts. On a deux techniques que le testeur peut utiliser :

● error guessing : Avant que le testeur commence le test, il devine les erreurs
qui pourraient apparaître et commence par tester ces cas.
● exploratory testing : C'est une méthode utilisée lorsque le temps de test est
limité ou lorsque les spécifications sont pauvres

Chapitre 4 : Test management

- test organization
Cette partie concerne le moment où le manager de test choisit son équipe de test. À ce
stade, on choisit le type de testeur parmi les options suivantes :
● Développeur du même projet : ce choix est un peu risqué car la personne
détecte rarement ses propres erreurs.
● Développeur ne faisant pas partie du même projet.
● Testeur de la même organisation.
● Testeur d'une organisation externe.
● Testeur indépendant et spécialiste (usabilité, sécurité, etc.).
● Testeur indépendant externalisé.
Le facteur qui détermine quel type de testeur nous devons choisir est la complexité et la
taille du projet. Plus le projet est complexe, plus nous avons tendance à préférer des
testeurs indépendants. Ces derniers présentent des avantages, car un testeur indépendant
apporte un regard neuf sur le projet. Cependant, il y a aussi un inconvénient : nous perdons
l'esprit d'équipe.
pour la hiérarchie de l'équipe :
1. test manager : Définit la stratégie et le plan de test, et rédige le rapport de test.
2. testeur : Exécute les tests, manipule le plan défini par le manager, analyse et révise
les exigences, prépare l'environnement de test, et exécute les données de test.
3. Développeur : Réalise les tests de composants et d'intégration.
- test plan overview
Chaque projet a un plan, un budget et un temps clairement définis pour sa réalisation. Dans
le cadre des tests, il existe également des exigences que nous devons prendre en
considération :
● l’importance du projet
● le but et les objectifs du test : dans ce cadre se pose une question : d'où commence-
t-on le test ? On commence à partir des buts et des objectifs
● La taille et la complexité du projet
Les tests nécessitent des ressources, parmi lesquelles :
● Les compétences de l'équipe
● Les équipements existants
● Le financement
et dans le test on doit connaître
● La testabilité du logiciel
● Les risques produits et les risques projet :
- Risques produits : bugs non résolus
- Risques projet : un membre n'a pas accompli sa tâche, ce qui conduit à un
manque de ressources et à des changements d'exigences.
● La stratégie de test de l'organisation : nous donne une idée de l'approche suivie par
l'organisation en déterminant le niveau et le type de tests. Cela soulève la question :
quand commence-t-on le test ?
- pro-active : dès que les exigences sont définies
- re-active : lorsque le design et le code sont prêts
- test planning activities
Les activités effectuées dans la phase de planification sont:
1. test scope :déterminer les objectifs et les risques du test
2. Déterminer l'approche adoptée pour le test.
3. Intégrer les activités de test dans le SDLC (Software Development Life Cycle).
4. Prendre des décisions sur les éléments à tester.
5. Pour chaque activité de test, mentionner les ressources nécessaires, le niveau de
détail requis et les métriques sélectionnées pour la surveillance et le contrôle des
tests. Cela signifie suivre l'activité du test pour s'assurer qu'elle se déroule comme
prévu, et prendre des mesures correctives si nécessaire.
6. Déterminer les critères d'entrée et de sortie :
- Critères d'entrée : indiquer quand commencer le test (par exemple,
commencer le test à chaque niveau de test). Cela nécessite un
environnement de test, des outils et des données de test, ainsi que la
testabilité du code et sa préparation pour un test de type boîte blanche.
- Critères de sortie : peuvent inclure le pourcentage de couverture du code,
l'analyse des risques (tests des parties les plus risquées), la densité des
 défauts (nombre d'erreurs dans le code) ou les défauts non corrigés pour
lancer le produit le plus proche possible de la perfection.
7. Les facteurs qui définissent les critères d'entrée et de sortie :
- Disponibilité de l'équipe.
- Disponibilité des outils.
- Élément de test.
- Défauts.
- Mesure de l'exécution des tests : combien de tests réussissent et combien
échouent.
- Mesure de la couverture : couverture du code et couverture des exigences.
- Mesure de la qualité.
- Budget. …….

- test estimation
Le test leader, lorsqu’il travaille avec une équipe de testeurs, doit estimer l’effort que chaque
membre devra fournir, en termes de nombre de tâches et du temps nécessaire pour chaque
tâche. Cette estimation se fait en se basant sur différentes approches :
- matrix base : on donne des estimations en se basant sur des projets similaires à
celui-ci.
- expert based : on donne une estimation en se basant sur l'expérience du
responsable de cette tâche.
Il existe des éléments qui affectent l'effort de test :
- Caractéristiques du produit : la base de test, la taille du projet, la complexité, etc.
- Processus de développement
- Résultats des tests : chaque fois qu'un défaut est trouvé, il doit être cédé au
développeur pour correction, puis le testeur doit le retester.

Dans les tests, nous choisissons des approches basées sur le contexte, qui comprend les
technologies disponibles, les membres de l'équipe, le taux de risque dans le projet, etc.
C'est pour cela qu'il existe des approches typiques :

1. Approche analytique : analyser le taux de risque présent dans le système, et l'effort

est concentré sur les modules les plus risqués.
2. Approche basée sur les modèles : le test stochastique nous donne la fiabilité du
système par rapport aux bugs existants.
3. Approche méthodique : basée sur l'estimation des erreurs et réalisée en se basant
sur l'expérience des ingénieurs de test.
4. Approche standard ou conforme : suivre les standards et les normes d'une industrie
spécifique.
5. Approche dynamique et heuristique : ajuster les tests en fonction de la situation et
des retours.
6. Approche consultative : inviter une personne externe expérimentée dans le domaine
cible et la consulter sur ce qui doit être couvert.
7. Approche de régression inverse : en utilisant les outils de test, refaire les tests sur
tous les modules.
- test mentoring and control :
Après que les tâches et les responsabilités sont distribuées, nous devons suivre les progrès
des testeurs dans leur travail. Ce suivi ou surveillance se fait de deux manières :
- Si la taille du projet est petite, on peut le faire manuellement, soit avec des
documents, soit par des discussions.
- Si la taille du projet est grande, on peut utiliser des outils d’automatisation.

Nous pouvons également utiliser des métriques de test telles que :

● Le pourcentage de travail accompli dans la phase de préparation des cas de test.

● Le pourcentage de travail accompli pour la préparation de l’environnement de test.
● L’exécution des cas de test.
● Les informations sur les défauts trouvés.
● La couverture des tests.
● La confiance des testeurs dans le produit.
● Les défauts par rapport aux jalons.
● Les coûts des tests.

Après la surveillance, il peut y avoir des écarts entre les activités de test planifiées et la
réalité. Pour rectifier ces écarts, le manager doit prendre des décisions telles que
l'augmentation du nombre de testeurs, la replanification des tâches, etc.

Après la surveillance et le contrôle, nous devons rédiger un rapport de synthèse qui inclut :

- Rapport de test.
- Analyse des informations des métriques de test.
- Recommandations pour les actions futures.

Le rapport doit être divisé en plusieurs parties :

1. Identification : nom et version du projet.

2. Version testée : éléments testés, environnement de test, etc.
3. Variations : les écarts qui sont apparus.
4. Évaluation de la compréhension : déterminer les objectifs couverts parmi ceux
planifiés.
5. Statut des incidents.
6. Évaluation.
7. Résumé des activités : comparaison entre ce qui est planifié dans le plan de test et
ce qui est réellement réalisé.
8. Approbation.
- configuration management
C'est une plateforme où nous téléchargeons notre travail en tant que développeur ou
testeur, afin de travailler sur une seule version. Chaque modification est visible par les
membres de l'équipe, au lieu que chacun travaille sur une partie pour les rassembler, ce qui
pourrait engendrer plusieurs problèmes. De plus, le gestion de configuration nous permet
d'identifier tous les éléments de test (testware) et de conserver la traçabilité.
- project and product risk
Les risques de projet sont ceux qui peuvent apparaître durant le projet. Les facteurs de ces
risques sont :

● organisation :
- Manque au niveau du staff , de compétences et de formation.
- Problèmes personnels ou politiques entre les membres de l'équipe.
- Manque de respect envers l'effort fourni par l'équipe de test.

● technical :
- Problèmes pour définir correctement les exigences.
- Environnement de test non disponible.
- Retard dans une migration de données.
- Faible qualité du design et du code.

● supplier : Parfois, l'utilisation d'outils externes peut poser problème si l'on ne sait pas
comment les utiliser ou s'ils sont endommagés et que le support technique est
indisponible.

Après avoir terminé les tests et préparé le produit, il existe des risques de non-succès liés
aux caractéristiques de qualité spécifiques du produit. Si le produit ne satisfait pas les
attentes du client, cela peut être grave. Pour éviter ces risques, nous devons adopter une
approche proactive pour les minimiser. Parmi les éléments qui identifient l'approche à
suivre, nous avons Identification des risques produits qui doit être pris en considération
dans le plan de test. Cet élément nous indique les parties où des bugs peuvent apparaître,
permet de faire une analyse des risques produit et de prioriser ces risques. Les avantages
de l'identification des risques produit incluent :

- Techniques de test.
- Ampleur des techniques.
- Priorisation des tests.
- Activités non liées aux tests, telles que la formation de l'équipe pour acquérir les
compétences nécessaires aux tests.
- incident management
Un incident est toute différence entre les résultats attendus (ER) et les résultats réels (AR).
Cela peut être un bug, mais pas nécessairement, et il peut apparaître lors des étapes de
développement, de revue, de test, ou lors de l'utilisation du produit. Lorsque je trouve un
incident, je dois rédiger un rapport d'incident. Les objectifs de ce rapport sont :
- Identifier, isoler et corriger ces problèmes.
- Suivre le progrès des tests.
- Apprendre des leçons pour améliorer le processus de test des futurs projets.
Le rapport doit contenir des détails tels que :
- Date, organisation et auteur ayant découvert l'erreur.
- Mention des résultats attendus (ER) et des résultats réels (AR).
- Mention de l'environnement de test.
- Étape du cycle de vie où l'incident est apparu.
- Description de l'incident et les étapes ayant conduit à sa découverte.
 - Degré d'impact en termes d'urgence ou de priorité.
- Statut de l'incident (à résoudre, résolu, non résolu, résolu mais non testé, etc.).
- Conclusion, recommandations et approbation pour éviter ce genre d'incident à
l'avenir.
- Problèmes globaux comme l'impact de cet incident sur les autres parties du logiciel.
- Historique des modifications.
- Référence contenant l'identification du cas de test ayant conduit à l'apparition de cet
incident.

cycle de vie d’un incident :

le rapport d’incident selon le standard ieee 829

après l’explication vient des subtitles

- Inputs : la procédure qui m'a amené à découvrir cet incident.
- Expected results
- Actual results
- Anomalie : explication de la divergence entre les résultats attendus (ER) et les
résultats réels (AR).
- Date and time : date et heure de la découverte de l'incident.
 - Environnement : environnement de test où l'incident est survenu.

-
- les tentative de répétition

- testers

- observers

Les dangers qui peuvent résulter d'un incident sont classifiés en se basant soit sur la gravité
de cet incident, soit sur la priorité pour le corriger :
- les exemples de gravité

- les exemples de la priorité

 - types of test tools :
1. test support management of test :
Test management tool :

● Chargé par le test management du projet tout entier.

● Traçage des objets de test selon les spécifications des exigences.
● Le rapport contient une analyse sur le progrès.
● Cet outil doit être interfacé avec les autres outils.

requirement management tool :

● Stocker les déclarations et attributs des exigences.

● Traçage des exigences de test.
● Cet outil doit contenir d'autres fonctionnalités comme la priorisation des exigences et
l'identification des exigences manquantes.

Incidents management tool :

● Stocker et gérer les rapports d'incidents.

● Le rapport contient une analyse des incidents.

Configuration management tool :

● Son rôle est de gérer les versions du logiciel.

● Stocker et gérer les versions du testware.

2. tool support for static testing :

- Review tools : Rapport sur les défauts, stockage de commentaires et de
reviews, communication des commentaires pour résoudre les défauts,
fourniture de reviews en ligne pour les grandes équipes dispersées.
- Static analysis tools : Trouver les défauts dans le code, imposer des
normes de codage (y compris le codage sécurisé), analyser la structure et les
dépendances, fournir des métriques pour le code (complexité) pouvant aider
à l'analyse des risques.
- Modeling tools : Leur rôle est de valider les modèles sur lesquels nous
travaillons en identifiant les défauts existants.
3. tool support for test specification :
 - test design tool : Générer les inputs de test à partir des exigences, interface
utilisateur graphique, modèles de conception et code, et générer les rapports
d'exécution (ER).
- test data preparation tool : Son rôle est d'extraire les données de test de la
base de données et de les sécuriser.
4. tool support for test execution and logging :
- test execution tool : Exécute les tests automatiquement ou semi-
automatiquement en fournissant les entrées et les résultats attendus.
- test harness/unit test framwork tool : Utilisé pour tester les petits modules,
et les harness utilisés
- test comparator tool :Compare les résultats attendus (ER) avec les résultats
réels (AR), soit pendant l'exécution (dynamique) soit après l'exécution (post-
comparaison).
- coverage measurement tool : Utilisé pour mesurer le pourcentage de code
couvert par les tests.
- security testing tool : Tente d'attaquer le logiciel pour tester sa sécurité vis-
à-vis des données.
5. tool support for test performance and mentoring :
- Dynamic and analysis tool : Identifient l'indépendance temporelle et les
fuites de mémoire.
- performance / load / stress : Exécutent le système en lui fournissant des
conditions spécifiques, puis suivent sa réaction.
- mentoring tool : Trace la situation du système pendant son fonctionnement
réel, ce qui permet de générer un rapport sur l'utilisation du système et des
avertissements concernant les problèmes éventuels.