Pfe 1

République Tunisienne
Ministère de l’Enseignement Supérieur

et de la Recherche Scientifique
Université de Carthage
Institut Supérieur des Technologies de
l’Information et de la Communication
Rapport de Projet de Fin d’Etudes

Présenté en vue de l’obtention de la
Licence Fondamentale en Sciences et Technologies
Mention : Sciences de l’Informatique
Spécialité : Sciences de l’Informatique
Plateforme d’automatisation des tests pour

les applications web
Par
Emna BAYOUDH
Hazem GDARA
Réalisé au sein de Tritux
Soutenu publiquement le 11 Juillet 2020 devant le jury composé de :

Président : Mme. Nour Brinis, Enseignante, ISTIC
Examinateur : M. Hazem Yahyaoui, Enseignant, ISTIC
Encadrant professionnel : Mme. Ribeh Abda, Ingénieur, TriTux
Encadrant académique : Mme. Zayneb Trabelsi, Enseignante, ISTIC
Année Universitaire : 2019-2020

République Tunisienne
Ministère de l’Enseignement Supérieur
et de la Recherche Scientifique
Université de Carthage
Institut Supérieur des Technologies de
l’Information et de la Communication
Rapport de Projet de Fin d’Etudes

Présenté en vue de l’obtention de la
Licence Fondamentale en Sciences et Technologies
Mention : Sciences de l’Informatique
Spécialité : Sciences de l’Informatique
Plateforme d’automatisation des tests pour

les applications web
Par
Emna BAYOUDH
Hazem GDARA
Réalisé au sein de TriTux
Autorisation de dépôt du rapport de Projet de Fin d’Etudes :
Encadrant professionnel : Encadrant académique :

Mme. Ribeh Abda, Ingé- Mme. Zayneb Trabelsi, Ensei-
nieur, TriTux gnante, ISTIC
Le : Le :
Signature : Signature :
Dédicaces
Nous dédions cet événement marquant de notre vie à nos chères familles, nous ont doté
d’une éducation digne, leur amour a fait de nous ce que nous somme aujourd’hui.
A nos professeurs qui nous encouragent souvent de mieux faire et qui nous bénéficient
avec leurs connaissances.
Et aussi, à nos chers amis et leur soutien infini.
i
Remerciements
On tient à exprimer toute notre reconnaissance à notre encadreur Madame Lahbib

Mariem. On la remercie de nous avoir encadré, orienté, aidé et conseillé. «Grand Merci».
On adresse nos sincères remerciements à tous les professeurs, intervenants et toute l’équipe
de Tritux qui ont guidé nos réflexions et ont accepté de nous aider et répondre à nos ques-
tions durant nos études, nos recherches et notre stage. «Merci».
On remercie également notre encadreur Madame Trabelsi Zayneb, pour son aimable en-
cadrement et toutes ses consignes et recommandations. «Merci».
Nos sincères remerciements s’adressent à Dieu, nos parents et nos amis pour leur encou-
ragement, leur soutien et leur grand amour. «Grand Merci».
ii
Table des matières
Dédicaces i
Remerciements ii
Introduction Générale 1
1 Cadre du projet et étude de l’existant 3

1.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2 Présentation de l’organisme d’accueil . . . . . . . . . . . . . . . . . . . . . 3
1.3 Etude de l’existant . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.3.1 Solution actuelle adoptée par l’entreprise . . . . . . . . . . . . . . . 5
1.3.2 Critiques de l’existant . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.3.3 Objectifs du projet . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.3.4 Travail à réaliser . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.4 Méthodologie adoptée . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
1.5 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2 Etat de l’art 8
2.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.2 Automatisation des tests . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.2.1 Test automatisé . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.2.2 Intérêt des tests automatisés . . . . . . . . . . . . . . . . . . . . . . 9
2.2.3 Critères de l’automatisation . . . . . . . . . . . . . . . . . . . . . . 9
2.2.4 Automatisation des tests dans les entreprises . . . . . . . . . . . . . 10
2.2.5 Exemple d’utilisation de l’automatisation . . . . . . . . . . . . . . . 11
2.2.6 Certification ISTQB . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.3 Choix techniques pour l’automatisation des tests . . . . . . . . . . . . . . . 13
2.3.1 Selenium . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.3.2 Choix du langage de programmation . . . . . . . . . . . . . . . . . 16
2.3.3 Framework de génération de test . . . . . . . . . . . . . . . . . . . 18
2.4 Architecture de l’application . . . . . . . . . . . . . . . . . . . . . . . . . 18
2.5 Choix techniques pour l’application . . . . . . . . . . . . . . . . . . . . . . 20
2.5.1 Partie back-end : Spring Boot . . . . . . . . . . . . . . . . . . . . . 20
2.5.2 Partie front-end : Angular8 . . . . . . . . . . . . . . . . . . . . . . 21
2.6 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
3 Spécification des besoins 23

3.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
3.2 Besoins fonctionnels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
iii
Table des matières Table des matières
3.3 Besoins non fonctionnels . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

3.4 Identification et structuration des cas d’utilisation . . . . . . . . . . . . . 24
3.4.1 Identification des acteurs . . . . . . . . . . . . . . . . . . . . . . . . 24
3.4.2 Diagramme de cas d’utilisation globale . . . . . . . . . . . . . . . . 25
3.5 Backlog Produit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
3.6 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
4 Sprint 1 : Profil Administrateur 28

4.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
4.2 Sprint Backlog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
4.3 Conception . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
4.3.1 Diagrammes de séquences . . . . . . . . . . . . . . . . . . . . . . . 30
4.3.2 Diagramme de classe . . . . . . . . . . . . . . . . . . . . . . . . . . 35
4.4 Réalisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
4.4.1 Authentification et Espace Admin . . . . . . . . . . . . . . . . . . . 36
4.4.2 Gestion des utilisateurs . . . . . . . . . . . . . . . . . . . . . . . . . 37
4.4.3 Gestion des projets . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
4.5 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
5 Sprint 2 : Profil Equipe qualité 44

5.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
5.2 Sprint Backlog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
5.3 Conception . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
5.4 Réalisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
5.4.1 Espace Equipe Qualité . . . . . . . . . . . . . . . . . . . . . . . . . 53
5.4.2 Visualiser le projet à tester . . . . . . . . . . . . . . . . . . . . . . . 54
5.4.3 Préparation et gestion du processus test automatique . . . . . . . . 55
5.4.4 Préparation de l’environnement de test automatique . . . . . . . . . 58
5.4.5 Consultation des rapports . . . . . . . . . . . . . . . . . . . . . . . 61
5.5 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
6 Sprint 3 : Profil Equipe software 63

6.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
6.2 Sprint Backlog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
6.3 Conception . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
6.4 Réalisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
6.4.1 Espace Equipe Software . . . . . . . . . . . . . . . . . . . . . . . . 68
6.4.2 Consulter les scripts BDD des tests développés . . . . . . . . . . . . 69
6.4.3 Consulter les rapports . . . . . . . . . . . . . . . . . . . . . . . . . 70
6.4.4 Rapport . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
6.5 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
Conclusion Générale 72
Bibliographie 73
iv
Table des figures
1.1 Entreprise TRITUX . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.1 Pourcentage d’utilisation des projets d’automatisation des tests par les en-
treprises . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.2 ISTQB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.3 Selenium . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.4 Le projet et les outils Selenium . . . . . . . . . . . . . . . . . . . . . . . . 15
2.5 Langage JAVA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
2.6 Cucumber . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
2.7 JUnit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
2.8 Architecture MVC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
2.9 Spring Boot . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
2.10 Angular . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
3.1 Diagramme de cas d’utilisation général . . . . . . . . . . . . . . . . . . . . 25
4.1 Diagramme de cas d’utilisation “Administrateur” . . . . . . . . . . . . . . 30

4.2 Diagramme de séquence “Authentification” . . . . . . . . . . . . . . . . . . 31
4.3 Diagramme de séquence “ Créer un utilisateur” . . . . . . . . . . . . . . . 32
4.4 Diagramme de séquence “ Modifier un utilisateur” . . . . . . . . . . . . . . 33
4.5 Diagramme de séquence “ Supprimer un utilisateur” . . . . . . . . . . . . . 34
4.6 Diagramme de séquence “ Affectation d’un projet à un rôle” . . . . . . . . 35
4.7 Diagramme de classe "Administrateur" . . . . . . . . . . . . . . . . . . . . 36
4.8 Interface "Authentification" . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
4.9 Interface "Erreur d’authentification" . . . . . . . . . . . . . . . . . . . . . . 37
4.10 Espace "Administrateur" . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
4.11 Interface "Création utilisateur" . . . . . . . . . . . . . . . . . . . . . . . . . 38
4.12 Interface "Saisie de données utilisateur" . . . . . . . . . . . . . . . . . . . . 38
4.13 Interface "Liste d’utilisateurs" . . . . . . . . . . . . . . . . . . . . . . . . . 39
4.14 Interface "Consultation et modification d’un utilisateur" . . . . . . . . . . . 39
4.15 Interface "Modification utilisateur" . . . . . . . . . . . . . . . . . . . . . . 40
4.16 Interface "Suppression d’un utilisateur" . . . . . . . . . . . . . . . . . . . . 40
4.17 Interface "Gestion de projets" . . . . . . . . . . . . . . . . . . . . . . . . . 41
4.18 Interface "Ajout d’un projet" . . . . . . . . . . . . . . . . . . . . . . . . . . 41
4.19 Interface "Suppression d’un projet" . . . . . . . . . . . . . . . . . . . . . . 42
4.20 Interface "Affectation d’un projet à un rôle" . . . . . . . . . . . . . . . . . 42
4.21 Interface "Supprimer un projet pour un rôle" . . . . . . . . . . . . . . . . . 43
5.1 Diagramme de cas d’utilisation “Equipe qualité” . . . . . . . . . . . . . . . 46
v
Table des figures Table des figures
5.2 Diagramme de séquence “Visualiser projet” . . . . . . . . . . . . . . . . . . 47

5.3 Diagramme de séquence “Exécution des tests et génération du rapport” . . 48
5.4 Diagramme de séquence “Importation des fichiers ’Feature’” . . . . . . . . 49
5.5 Diagramme de séquence “Importation des fichiers ’Steps’” . . . . . . . . . 50
5.6 Diagramme de séquence “Importation des rapports générés” . . . . . . . . 51
5.7 Diagramme de séquence “Consulter les rapports des tests exécutés” . . . . 52
5.8 Diagramme de classe "Equipe Qualité" . . . . . . . . . . . . . . . . . . . . 53
5.9 Interface "Espace Equipe Qualité" . . . . . . . . . . . . . . . . . . . . . . . 54
5.10 Interface "Sélectionner un projet" . . . . . . . . . . . . . . . . . . . . . . . 54
5.11 Interface "Page d’accueil du projet" . . . . . . . . . . . . . . . . . . . . . . 55
5.12 Interface "Scénario de test en BDD - Feature" . . . . . . . . . . . . . . . . 56
5.13 Interface "Scénario de test en java - Step1" . . . . . . . . . . . . . . . . . . 56
5.14 Interface "Scénario de test en java - Step2" . . . . . . . . . . . . . . . . . . 57
5.15 Interface "La classe d’exécution" . . . . . . . . . . . . . . . . . . . . . . . . 57
5.16 Interface "Exécution de test" . . . . . . . . . . . . . . . . . . . . . . . . . . 58
5.17 Interface "Etape 2 : Préparation de l’environnement de test automatique" . 58
5.18 Interface "Importation des fichiers "Feature"" . . . . . . . . . . . . . . . . . 59
5.19 Interface "Importation des fichiers "Steps"" . . . . . . . . . . . . . . . . . . 59
5.20 Interface "Etape 2 : Sélection des fichiers" . . . . . . . . . . . . . . . . . . . 60
5.21 Interface "Etape 3 : Imortation des rapports" . . . . . . . . . . . . . . . . . 60
5.22 Interface "Etape 3 : Insertion du schémas du rapport" . . . . . . . . . . . . 61
5.23 Interface "Etape 4" . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
5.24 Interface "Sélectionner rapport" . . . . . . . . . . . . . . . . . . . . . . . . 62
5.25 Interface "Rapport" . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
6.1 Diagramme de cas d’utilisation “Equipe Software” . . . . . . . . . . . . . . 64

6.2 Diagramme de séquence “Sélectionner un projet” . . . . . . . . . . . . . . 65
6.3 Diagramme de séquence “Consulter le test en script BDD” . . . . . . . . . 66
6.4 Diagramme de séquence “Consulter les rapports des tests exécutés” . . . . 67
6.5 Diagramme de classe "Equipe Software" . . . . . . . . . . . . . . . . . . . . 68
6.6 Interface "Etape 1 - Choix du projet" . . . . . . . . . . . . . . . . . . . . . 69
6.7 Interface "Etape 2 - Sélection du package-test et du scénario" . . . . . . . . 69
6.8 Interface "Etape 3 - Affichage du script en BDD du scénario" . . . . . . . . 70
6.9 Interface "Etape 4 - Fin de la consultation des résultats " . . . . . . . . . . 70
6.10 Interface "Sélectionner rapport" . . . . . . . . . . . . . . . . . . . . . . . . 71
6.11 Interface "Rapport des résultats de test automatique" . . . . . . . . . . . . 71
vi
Liste des tableaux
2.1 Tableau comparatif d’outils d’automatisation de test . . . . . . . . . . . . 14
3.1 Identification des acteurs . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

3.2 Backlog Produit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
4.1 Sprint Backlog 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
5.1 Sprint 2 Backlog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
6.1 Sprint 2 Backlog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
vii
Introduction Générale
Depuis la naissance de l’Internet, bien de fonctionnalités à la part la navigation, ont

été développées. Parmi elles, se trouve la possibilité d’aider un utilisateur, en satisfaisant
au mieux ses exigences, avec une solution de test automatisé pour les applications web.
Quand nous nous lançons dans le développement d’un site web ou d’une application, une
question va forcément se soumettre : comment tester notre produit final ?
Les tests de logiciels font actuellement une partie intégrante de tout projet fructueux. Ils
peuvent être classés en deux principaux types : les tests manuels et les tests automatisés.
Comme la plupart des spécialistes dans l’industrie du logiciel le savent et en se basant
sur des exemples adaptés dans les industries, tous les deux types offrent des avantages et
des inconvénients. Les tests manuels (comme son nom le désigne) sont exécutés manuel-
lement (par un humain). Le cas de test est effectué par le testeur directement qui réalise
les actions demandées (désignation, écriture et réalisation de cas de test fréquemment
à partir des spécifications) et vérifie (analyse) que ses conséquences obtenues sont bien
celles attendues. La reprise de l’exécution (le maintien et l’archivage) de cette tâche n’est
pas très enrichissante, d’ailleurs pour cela que nous passons à apercevoir le nouveau type,
celui de l’automatisation des tâches, et qui semble si attractive et intéressante.
Toutefois, les tests automatisés sont réalisés à l’aide d’outils, de scripts et de logiciels.
Ces dernières années, les tests automatisés ont renforcé les entreprises à commerciali-
ser plus rapidement et sans tarder des nouvelles fonctionnalités tout en garantissant une
expérience utilisateur optimale. Ils ont pareillement permis d’améliorer et progresser la
productivité des développeurs et des ingénieurs QA (Quality Assurance Ingénieur) en éli-
minant et excluant les tâches qui prennent trop de temps. Ces avantages nous conduisent
à ce lancer dans ce domaine. Cette opportunité nous a été offerte au sein de l’entreprise
"TriTux", vu qu’elle utilise encore la méthode classique celle des tests manuels et vise
toujours à exploiter des services en innovation.
Par conséquent, notre objectif est d’améliorer la phase de test d’un produit et consiste à
faire la conception, le développement et la mise en place d’une solution web qui lance des
tests automatisés aux applications déjà développées au sein de l’entreprise «TriTux».
Le rapport présent dépose nos recherches établies dans ce domaine et présente les diffé-
rentes étapes que nous allons suivre pour réaliser ce projet. Il s’appuie sur six chapitres.
Le premier chapitre sert à présenter l’organisme d’accueil, exposer une étude de l’existant,
pour bien comprendre le système du travail actuel au sein de l’entreprise et poser le cadre
de la problématique, et souligner notre méthodologie adoptée.
Par la suite, le deuxième chapitre consistera à présenter une étude sur l’automatisation
des tests, ces intérêts et les choix technologiques qui vont êtres utilisés pour la réalisation
de notre plateforme.
Le troisième chapitre détaillera la spécification des besoins de notre projet en identifiant
les différentes fonctionnalités de l’application. Il présentera de même ses différents scéna-
rios via le diagramme de cas d’utilisation.
1
Introduction Générale
Le quatrième, cinquième et sixième chapitre seront dédiés à la conception et la réalisation

des différents profils de notre solution. Le premier profil sera dédié pour l’administra-
teur, celui qui gère les utilisateurs et les projets relatifs à l’application. Le deuxième,
pour l’équipe qualité (Testeurs), celle qui gère le processus de test et qui rédige les dif-
férents scénarios et scripts. Et le troisième, pour l’équipe software, celle qui consulte les
scénarios déjà développés et les résultats des tests appliqués. Ces chapitres, présenteront
les différents diagrammes de cas d’utilisation pour chaque acteur, les différents scénarios
d’interactions avec la plateforme via les diagrammes de séquences et finalement les réali-
sations des différents modules.
Pour la fin, le présent rapport s’achèvera par une conclusion générale qui présentera les
résultats et les perspectives de notre projet.
2
Chapitre 1
Cadre du projet et étude de

l’existant
1.1 Introduction
Pour notre premier chapitre, nous commençons notre travail en le mettant dans son
contexte général. Nous présentons l’organisme d’accueil au sein duquel s’est déroulé notre
stage de projet de fin d’étude. Ensuite, nous donnons un aperçu sur la problématique
dont découle l’idée et la demande de ce dernier en étudiant l’existant. Ceci nous permet
d’avoir des objectifs à atteindre pour réaliser le travail demandé. Et enfin, nous proposons
la méthodologie adoptée dans notre projet.
1.2 Présentation de l’organisme d’accueil

TriTUX, présentée dans la figure 1.1, est une société internationale spécialisée dans
l’ingénierie et le conseil en informatique et l’externalisation. Avec plus de 13 ans d’ex-
périence, TriTUX est l’un des principaux fournisseurs de solutions informatiques de té-
lécommunication. Grâce à une infrastructure solide et à de multiples certifications dans
les nouvelles technologies, ils fournissent des services d’ingénierie et de conseil en innova-
tion et en agilité commerciale. Ils poursuivent cet environnement et la rentabilité de leurs
clients en proposant des solutions adaptées et personnalisées, avec un ensemble complet
de services et de la conception à la mise en œuvre. Ils sont un partenaire stratégique dans :
— IoT.
— VAS.
— Roaming.
— IT Solutions.
Leurs secteurs d’activité sont :
— Télécommunication.
— Bancaire.
— Industrielle.
— Secteur public, etc.
Leurs buts sont :
— Maintenir les normes éthiques les plus élevées.
— Assurer la satisfaction du client en fournissant des services et une valeur de qualité.
3
Chapitre 1. Cadre du projet et étude de l’existant 1.3. Etude de l’existant
— Recruter et conserver une main-d’œuvre hautement qualifiée, motivée, productive

et engagée à établir et à maintenir des relations professionnelles fondées sur l’inté-
grité et la confiance.
— Établir et entretenir de solides relations de collaboration avec des entreprises ayant
des visions, des missions et des valeurs similaires.
Tritux propose aussi un large éventail de services de conseil, d’ingénierie et d’analyse :
— Ingénierie : Tritux offre les solutions les plus flexibles et innovantes pour plusieurs
activités avec une assurance qualité professionnelle. Basée sur des ingénieurs ta-
lentueux et expérimentés, elle garantit l’application des meilleures pratiques et des
dernières technologies.
— Externalisation : Tritux est l’un des principaux fournisseurs d’externalisation in-
formatique. Il permet d’accéder à des compétences supérieures et répond au déve-
loppement technologique tout en assurant un contrôle budgétaire.
— Consulting : Tritux fournit une expertise indépendante qui répond aux besoins des
clients et se concentre sur la réussite du projet, du concept initial à la mise en
œuvre.
— L’intégration : Tritux améliore l’efficacité et l’efficience de vos services informa-
tiques. Aujourd’hui, l’intégration transparente n’est plus une valeur ajoutée. C’est
un must.
— O M : Tritux met une équipe expérimentée d’ingénieurs hautement qualifiés à la
disposition de ses clients. Elle acquiert une réputation enviable de fournir le soutien
nécessaire pour améliorer et maintenir la qualité des produits [a].
Figure 1.1 – Entreprise TRITUX
1.3 Etude de l’existant

Avant de commencer notre travail, nous devons passer par l’étape de l’étude de l’exis-
tant pour pouvoir connaître les lacunes du système présent et éclaircir nos objectifs d’amé-
lioration. Pour cette partie, nous allons présenter la méthode actuelle adoptée par la
société, ses critiques et notre solution proposée.
4
1.3.1 Solution actuelle adoptée par l’entreprise

“Tritux est l’un des principaux fournisseurs de solutions informatiques de télécommu-
nication”. Elle offre comme service essentiellement le développement des applications web.
Un projet passe généralement par plusieurs tests unitaires, fonctionnels, de non-régression,
de performance... Donc ce processus est important et présente une étape inévitable de
tout développement informatique qui a pour objectif de vérifier que le livrable est bien
conforme aux besoins demandés par le client. Bien que son utilité soit indispensable, la
phase de test se trouve souvent prise en otage suite aux retards accumulés par le projet
et aux délais très ajustés. Pratiquement, il s’agira donc non pas d’établir que le système
fonctionne correctement dans tous les cas uniquement, mais aussi de détecter chaque élé-
ment ne fonctionnant pas comme prévu sous certaines conditions.
Tritux a décidé de travailler avec des tests manuels, dont les scénarios sont déroulés par
un être humain, afin d’accomplir ce processus. Dans cette tâche, les testeurs optent pour
la solution SQUASH : suite logicielle open source édité par le producteur français Hénix.
Elle suggère un panel complet d’outils pour l’installation d’un processus de qualification
sur l’ensemble d’un système, en commençant par la recherche des spécifications, puis la
rédaction des scripts de test, ensuite leurs exécutions jusqu’à la génération des rapports.
La mise en place de cette solution permet d’assurer un bon fonctionnement des applica-
tions, et apporte d’autres avantages tels que la garantie de la traçabilité des informations
d’un bout à l’autre du processus de développement, l’assurance pour le client d’un produit
bien construit et du bon respect des spécifications de départ.
Pour répondre à ces besoins la suite Squash fournit deux solutions :
— Squash TM (Test Management) : C’est un gestionnaire des référentiels de test qui
assure la gestion des exigences, scénarios de test, campagnes d’exécution ainsi que
la création de rapports d’exécution.
— Squash TF (Test Factory) : C’est la solution qui permet l’implémentation et l’exé-
cution des tests automatisés [b].
Dans notre cas, nous trouvons que l’équipe de Tritux utilise la première solution.
Avec cette approche informelle, le testeur ne suit aucune procédure rigoureuse de test,
mais découvre plutôt le produit, l’interface utilisateur de l’application en utilisant la
majorité de ses fonctionnalités et des informations obtenues lors des tests précédents pour
dériver intuitivement des tests supplémentaires. Le succès des tests manuels est basé sur
l’expertise du domaine du testeur, car un manque de connaissances impliquera des tests
incomplets. L’un des avantages les plus importants d’une approche informelle est d’avoir
une vision intuitive de ce que l’on ressent en utilisant l’application.
1.3.2 Critiques de l’existant

Les tests manuels sont des tests effectués par un humain, assis devant une machine et
exécutant avec prudence ses étapes du cycle de vie. Elles sont très lentes ayant un temps
d’exécution élevé. Encore, les tests manuels ne sont pas aussi précis, ils ne peuvent pas
êtres répliqués et surtout l’intervention humaine pendant l’exécution peut provoquer des
erreurs vu que cette action est répétitive et peut devenir ennuyeuse. Cependant, cette
tâche, bien que coûteuse en terme de temps, est indispensable pour assurer une certaine
qualité de produit. En effet, un défaut dans une application peut avoir des conséquences
plus ou moins graves pour les clients et l’entreprise. Leur correction peut s’accompagner
d’un coût supplémentaire qui n’a pas été prévu initialement.
5
1.3.3 Objectifs du projet

Les systèmes d’information sont amenés à évoluer régulièrement la nécessité d’intégrer
de nouvelles applications, de les mettre à jour ou de mettre en œuvre les évolutions à la
demande des différentes entités métiers de l’entreprise. Grâce à l’agilité, les méthodes de
développement sont de plus en plus en évolution ce qui nécessite une réflexion vis-à-vis les
processus de test. Dans un environnement toujours plus concurrentiel, l’enjeu des tests est
fondamental. Mais les exécuter manuellement régulièrement, toutes les semaines voir tous
les jours, devient impossible sans faire exploser les coûts et perdre l’envie des testeurs.
L’automatisation des tests est la solution pour améliorer la qualité de nos livraisons, et
encore plus, pour :
— Le gain de temps dû à un allègement de la charge de travail des équipes.
— L’augmentation de la productivité.
— La fiabilité et la qualité des tests effectués.
— L’accroissement du niveau de complétude des tests réalisés.
— La démobilisation des équipes sur les tâches répétitives au profit de tâches à plus
grande valeur ajoutée (Analyse des résultats, définition des cas de tests, planifica-
tion, etc.).
— La collaboration entre les différents membres des équipes.
C’est dans ce cadre que s’inscrit ce projet de fin d’études qui vise à automatiser une pile de
tests et créer une plateforme intitulée “Automate”, dont les différents réalisateurs d’une
application web peuvent se collaborer. Dans notre étude, nous avons remarqué qu’une
fois passé le cap de la conception des premiers scripts d’automatisation, nous pouvons
avoir tendance à adopter cette pratique pour de bon. Nous avons constaté en effet que
nous pouvons continuer à l’utiliser et à faire évoluer nos scripts au fur et à mesure de
l’avancement du projet digital. Nous désirons alors offrir une plateforme multi utilisateurs
où des testeurs peuvent consulter leurs projets, écrire leurs tests, les développer et les
exécuter d’une manière automatique et encore peuvent consulter les bilans des rapports
générés. Les développeurs aussi, d’un même projet peuvent rester en courant et consulter
les différents scénarios réalisés et les rapports générés pour concevoir les erreurs et les
anomalies qu’ils doivent prendre en considération. En réalisant cette tâche, l’entreprise
ouvre ses portes pour la nouvelle tendance de l’automatisation des tests, facilite la com-
munication entre ses équipes et encore va bénéficier d’une large documentations et des
scripts réutilisables dans d’autres contextes.
1.3.4 Travail à réaliser

Le travail à réaliser au cours de notre stage consiste à :
1. Analyser la spécification du projet et comprendre les différentes fonctionnalités des
tests automatisés.
2. Réaliser un Benchmark pour choisir les outils et l’environnement d’automatisation à
mettre en place.
3. Installer et intégrer les outils d’automatisation de test choisis.
4. Définir les cas de test sur un exemple d’application web “Jumia” à automatiser.
5. Décrire les tests fonctionnels dans un style compréhensible par un non informaticien.
6. Rédiger des scripts de tests à automatiser en créant les données de tests.
7. Exécuter les tests automatiques développés sur l’application “Jumia”.
8. Développer une plateforme d’automatisation des tests “Tritux” pour différents projets
d’applications web.
6
Chapitre 1. Cadre du projet et étude de l’existant 1.4. Méthodologie adoptée
9. Intégrer les tests déjà développés dans cette plateforme.

10. Faire un reporting sur les différents cas de tests.
11. Créer un espace commun pour les équipes de test et de développement pour une bonne
collaboration.
1.4 Méthodologie adoptée

La méthodologie de gestion d’un projet nous guide tout au long de son cycle de vie.
Cela commence par nous aider à planifier, initier et mettre en oeuvre le travail demandé.
Nous pouvons utiliser ces modèles pour planifier nos tâches et atteindre nos objectifs.
Mais différentes méthodologies vont être bénéfiques à différents projets, et les modèles de
gestion de projet ne sont pas tous efficaces pour différentes tâches. En effet, notre étude
nous conduise vers la méthodologie Agile pour aboutir à un bon résultat et garantir le
déroulement de différentes phases de notre projet.
La méthode Agile recommande de se fixer des objectifs à court terme. Le projet est donc
divisé en plusieurs sous-projets. Une fois l’objectif atteint, nous passons au suivant jus-
qu’à l’accomplissement de l’objectif final. Cette approche est plus flexible. Puisqu’il est
impossible de tout prévoir et de tout anticiper, elle laisse la place aux imprévus et aux
changements [c].
En effet, au cours d’un sprint de 2 à 3 semaines, nous commençons notre travail. Nous
préparons les use-cases dans le backlog. La transition agile a fait disparaître les spécifica-
tions habituelles du cycle en V. Nous recevons généralement une première version testable
de l’application. Nous avons notre cahier de charge réalisé en préparent les différents scé-
narios de cas de tests prévisibles. Au cours de sprint, et selon l’acteur mis en question,
les nouvelles fonctionnalités sont développées en priorité. Notre cible en termes de travail
est la réalisation de chaque acteur à part. Cela n’implique pas que nos utilisateurs ne
sont pas liés. L’objectif est qu’à la fin de chaque sprint, les fonctionnalitées qui ont servi
de spécifications soient développées à un acteur bien définit. Ainsi la base de test sera
toujours actualisé en incluant les dernières fonctionnalités développées.
1.5 Conclusion
Dans ce chapitre, nous avons présenté notre organisme d’accueil, puis nous avons éla-
boré une étude de l’existant pour dégager les faiblesses de la solution actuelle et exposer
les objectifs de notre projet. Enfin, nous avons présenté notre méthodologie de cycle de
vie de notre projet à suivre. Notre chapitre suivant déterminera la notion de l’automati-
sation des tests, ses intérêts, ses critères et son importance. Il présentera aussi nos choix
techniques des différents outils de réalisation du projet et l’architecture adoptée.
7
Chapitre 2
Etat de l’art
2.1 Introduction
Pour éclaircir le contexte de notre projet et le valoriser encore, nous allons montrer
dans ce chapitre l’indisponibilité de l’automatisation des tests en la définissant, présentant
ses intérêts, sa priorité pour les entreprise, des chiffres dans le marché et en s’argument
par la certification ISTQB. Ensuite, nous allons présenter nos choix techniques pour l’au-
tomatisation des tests et la réalisation de notre plateforme web et nous allons exposer
l’architecture adoptée.
2.2 Automatisation des tests

Le test est une large discipline qui permet de s’assurer de la qualité des produits
informatiques développés. Il se présente dans un ensemble de cas à tester pour établir une
vérification partielle d’un système en visant à trouver ses erreurs. Son but principal est
de mettre le doigt sur un nombre maximal d’anomalies du logiciel pendant une courte
durée avant de livrer les produits aux clients. La qualité sera donc augmentée lorsque
les problèmes seront rectifiés. Plus généralement, il permet d’accomplir des recherches
d’informations et de tester la conformité des entités et des modèles quant à la qualité du
système et de son fonctionnement.
Dans cette partie, nous allons définir le test automatisé, son intérêt et les critères de passer
à l’automatisation. En outre, nous allons présenter la valeur de l’automatisation des tests
dans les entreprises en s’appuyant sur des chiffres concrets et la certification de ISTQB.
2.2.1 Test automatisé

Nous parlons de test automatisé lorsqu’aucune action manuelle n’est nécessaire dans
l’exécution des tests. Il reste bien claire une large part d’humain derrière ceux-ci puisque
les équipes expertes vont préalablement scripter et développer des environnements de
tests. Une fois fait, à la demande du client, nous pouvons lancer un ensemble de tests en
un temps record et sur tous les terminaux prévus. L’économie financière et temporelle est
réelle et devient un atout considérable dans les projets [d].
D’où vient la notion d’automatiser les tests qui consiste à les effectuer par un programme,
appelé aussi automate de test. Par analogie avec l’industrie, un automate de test est
programmé pour exécuter des tests préenregistrés [e].
Par conséquent, si nous voulons définir le test automatisé, nous pouvons dire qu’il est
8
Chapitre 2. Etat de l’art 2.2. Automatisation des tests
un processus dans lequel des outils logiciels exécutent des tests préprogrammés sur une
application logicielle avant sa mise en production. Un logiciel spécial est utilisé pour
contrôler l’exécution du test, les résultats réels, la comparaison des résultats estimés,
la configuration des conditions préalables, ainsi que d’autres fonctions de contrôle et de
rapport de test [f].
2.2.2 Intérêt des tests automatisés

Les systèmes d’information sont amenés à évoluer souvent, de par la nécessité d’inté-
grer de nouvelles applications, de les mettre à jour ou de mettre en œuvre les évolutions
à la demande des différentes entités métiers de l’entreprise. Les stratégies digitales accé-
lèrent encore un peu plus les besoins de transformation des systèmes informatiques qui
doivent intégrer, de plus en plus, des applications hétérogènes dans des délais de plus en
plus courts.
Pour assurer la fiabilité des systèmes d’information dans ces conditions, il faut les tester
afin de vérifier que les modifications n’ont pas apporté d’instabilité, des anomalies, ou des
conséquences parfois imprévisibles.
En informatique, un battement d’ailes d’un papillon peut provoquer une tornade. Des
exemples récents, près d’un million de clients d’un producteur d’électricité se sont vus
prélever deux fois leur facture, un organisme hospitalier perd 80 millions d’euros de fac-
tures impayés suite à un changement de système informatique, etc [g].
Ces deux exemples illustrent à quel point les tests sont critiques pour les entreprises. Pour-
tant, ils sont des fois négligées car ils sont chronophages et fastidieux pour les équipes. Et
encore, la phase de test est en bout de chaîne de tous projets menés en mode classique ou
agile, par suite, soumise aux contraintes fortes des plannings et du budget. Mais une fois
opérationnel, l’automatisation de ces derniers présente de nombreux avantages :
— Le gain de temps dû à un allègement de la charge de travail des équipes de l’en-
treprise.
— L’augmentation de la productivité.
— La cohérence et l’exactitude.
— La qualité et la fiabilité des tests développés.
— L’accroissement du niveau de complétude des tests réalisés.
— La démobilisation des équipes sur les tâches répétitives au profit de tâches à plus
grande valeur ajoutée (analyse des résultats, définition des cas de tests, planifica-
tion, etc.) [g].
2.2.3 Critères de l’automatisation

Selon des estimations, près de 80 pourcent des tests sont automatisables [h]. Avant
de mettre en place une solution, il faut bien entourer le potentiel et les limites de l’au-
tomatisation des tests, pour choisir les meilleurs cas d’usage. Les tests représentent en
moyenne 35 pourcent des coûts dans un projet de développement [h]. Par ailleurs, près de
30 pourcent du temps du projet est consacré au cahier de charge [h]. Pour cette raison,
l’automatisation des tests représente une source d’économies très importante. C’est un
gain de temps notable aussi, encore plus intéressant dans une situation où les délais de
livraison se raccourcissent de jour en jour.
9
Nous pouvons identifier quatre critères clés où l’automatisation des tests est pertinente
afin d’obtenir le meilleur retour sur investissement (ROI) :
La fréquence des tests

Une exécution manuelle est la plupart du temps suffisante pour des tests effectués une
fois par an. Toutefois, plus les tests doivent être exécutés de manière rapprochée, plus il
devient nécessaire de les automatiser.
La couverture des tests

La couverture des tests doit être de plus en plus large dû à la multiplication des
terminaux. En moyenne, les tests de non-régression pour un site web Internet doivent
ainsi être réalisés sur 2 à 3 navigateurs différents (Chrome, Firefox et IE étant les plus
répandus actuellement) et sur 2 à 3 types de machines : PC, smartphone et tablette. En
combinant ce critère à la fréquence, le nombre de tests à réaliser augmente tout de suite,
ce qui rend vite l’automatisation pertinente [h].
Les scénarios à déployer

Sur un scénario simple qui est constitué de quelques étapes, les tests manuels restent
envisageables. Contrairement, dès qu’il faut prendre en compte des parcours utilisateur
plus complets, les scénarios deviennent plus détaillés, avec de nombreuses actions succes-
sives.
Le nombre de profils à tester

Le parcours des utilisateurs diffère selon leur profil, c’est autant de cas d’usages diffé-
rents à tester (utilisateur connecté et non-connecté, client récurrent, client VIP, adminis-
trateur du site, parcours croissant ou décroissant, etc). Tous ces profils augmentent encore
le nombre de tests à développer et à exécuter [h].
Nous résumons la formule (ROI) : fréquence x nombre d’environnements x actions par
scénario x profils : nombre d’actions à reproduire.
Cela ajoute que la récurrence des actions manuelles va augmenter le pourcentage d’er-
reur. À ce stade l’automatisation des tests est une alternative pour assurer la fiabilité des
applications.
2.2.4 Automatisation des tests dans les entreprises

Nous pouvons constater un fait que plus de 51 pourcent des entreprises déclarent être
déjà équipées d’outils pour automatiser les tests selon la deuxième édition du baromètre
2013 du développement logiciel de Borland [i]. Pas étonnant vu leur importance pour
assurer la qualité d’une application et que l’automatisation des tests concerne toutes les
phases du projet( de l’analyse du code source au niveau des développeurs à l’automati-
sation des tests fonctionnels ou des tests de non régression en passant par la vérification
des performances ou de la sécurité des logiciels et des tests de montée en charge).
Pas seulement les tests sont les plus outillés, mais ils sont aussi ceux sur lesquels tra-
vaillent le plus les entreprises. Envers 54 pourcent des sociétés affirment travailler sur des
projets d’automatisation des tests, et plus de 30 pourcent sur des outils de gestion des
tests comme l’illustre la figure 2.1 [i].
10
La gestion des tests consiste à construire un référentiel centralisé où les tests sont accom-
pagnés par une grande documentation. Dans ces dernières années, la gestion de projet
était en tête des préoccupations comme le présente, et l’automatisation des tests venait
juste derrière avec 38 pourcent de réponses à égalité avec la gestion des exigences [i].
Figure 2.1 – Pourcentage d’utilisation des projets d’automatisation des tests par les
entreprises
2.2.5 Exemple d’utilisation de l’automatisation

Selon une étude préparée par Supinfo (école supérieure informatique mondiale), le
débat autour du retour sur investissement (ROI) concernant l’utilisation de plusieurs ni-
veaux de test ne date pas d’hier. Plusieurs études ont été menés sur ce sujet, exemple une
publiée en 2009 par Microsoft [j].
Cette étude s’appuie sur la comparaison des erreurs obtenues entre la V1 et la V2 d’un
projet réalisé en C, qui a duré deux années en mobilisant 32 développeurs et 15 testeurs.
La V1 a été réalisée avec des tests manuels et la V2 introduit des tests unitaires auto-
matisés (sans TDD : Test Driven Development, est une manière de développement, qui
consiste à concevoir un logiciel par petits pas, de façon itérative et incrémentale, en écri-
vant chaque test avant d’écrire son code source et en révisant le code continuellement).
Les tests étaient écrits après les développements tous les 2-3 jours.
La première constatation est la diminution du nombre de anomalies remontées par l’équipe
de tests : envers 20 pourcent des erreurs en moins pour 30 pourcent de temps de dévelop-
pements en plus [j]. L’équipe de test a eu le sentiment que les anomalies ont changées : les
grandes erreurs sont moins fréquentes. Les développeurs vérifient systématiquement leur
codes et développent des scénarios classiques d’utilisation tandis que l’équipe de test réa-
lisent des scénarios de tests plus évolués et plus réalistes. Les testeurs trouvent leur travail
moins mécanique tout en se sentant plus efficace et les développeurs ont le sentiment de
produire un code plus robuste. Encore, les développeurs jugent les erreurs remontées plus
facile à corriger quand ils se situent dans du code testé. Aussi, d’autre projets Microsoft
ont eu de meilleurs résultat en utilisant le TDD. Ces projets ont connu une diminution du
nombre d’anomalies allant de 60 pourcent à 90 pourcent pour à peu près le même temps
investi (à peu près 30 pourcent de temps de développement en plus) [j].
11
2.2.6 Certification ISTQB

Nous ne pouvons pas parler des tests sans mentionner ISTQB, la comité international
de qualification des tests logiciels, montrée dans la figure 2.2, qui décrit leur service dans le
site officiel par : des tests insuffisants ou des testeurs non qualifiés sont souvent les causes
principales d’un logiciel de mauvaise qualité. Dans l’usage, l’application systématique des
bonnes techniques de test est assez rare. L’objectif du programme ISTQB Testeur Certifié
est de changer cela. Tous les sujets importants dans le domaine des tests sont expliqués
et mis en pratique. ISTQB Testeur Certifié est un programme complet à l’échelle mondial
et peut être considéré comme indice de référence pour la certification des tests logiciels.
Plusieurs experts de plus de 40 pays travaillent en permanence à la mise à jour continuelle
de ce programme. Grâce à cette coopération internationale étroite, la compatibilité est
souvent réussite. Comme résultat, il est également possible d’obtenir la certification en
tant que testeur certifié ISTQB dans une grande variété de langues. À l’heure présente,
le GASQ offre une certification niveau fondation en anglais, français, allemand, polonais
et russe.
Plus de 500.000 testeurs de logiciels sont actuellement en possession du certificat conforme
ISTQB et ce nombre continue d’augmenter toujours. Le programme Testeur Certifié
ISTQB propose aux participants la connaissance dont ils ont besoin pour tester efficace-
ment un logiciel [k].
Figure 2.2 – ISTQB
Après avoir bien introduit l’automatisation des tests, nous devons savoir par quels
outils techniques nous pouvons réaliser notre travail.
En cas de forte volumétrie de tests à automatiser, nous recommandons d’utiliser un fra-
mework de test automatique qui remédiera au principal facteur d’échec des projets d’au-
tomatisation, à savoir la maintenabilité des scripts. Un framework de test est un ensemble
d’hypothèses, de concepts et d’outils qui supporteront l’automatisation des tests. Il en
existe plusieurs types. Nous devons choisir le framework le plus adapté au contexte de
l’entreprise et qui est assisté via des bonnes pratiques d’utilisation.
La prochaine section présentra nos choix techniques pour la tâche d’automatisation des
tests web.
12
Chapitre 2. Etat de l’art 2.3. Choix techniques pour l’automatisation des tests
2.3 Choix techniques pour l’automatisation des tests

Dans cette partie, nous présentons nos choix techniques des outils pour l’automatisa-
tion des tests réalisés sur une application web.
Le rythme de travail toujours croissant exige des outils d’automatisation qui sont déve-
loppés pour rendre nos routines faciles et efficaces. Par conséquent, nous devons faire une
étude bien détaillée pour faire les bons choix et gagner le temps. Dans la pratique, il existe
tout un arsenal d’outils adaptés, capables d’automatiser les tâches répétitives. Certains
améliorent encore la fiabilité des tests en effectuant des comparaisons de données volumi-
neuses ou en simulant des comportements de l’application. Ces derniers, qui s’interface
avec les outils d’exécution, de gestion des défauts, des exigences et de configuration, en-
registrent les résultats et génèrent des rapports d’avancement.
La demande de développement et de tests Web est énorme. En janvier 2018, il y avait
plus de 1,3 milliard de sites Web sur Internet desservant 3,8 et plus milliards d’internautes
dans le monde. En conséquence, le marché de l’outillage est désormais plus compétitif.
Par suite, et pour bien choisir notre outil, nous avons préparé une étude comparative
entre trois outils que nous avons trouvé très répandus pendant nos recherches : Selenium,
Katalon Studio et Ranorex illustrée dans le tableau 2.1.
Un point fort du Selenium et Katalon est le fait qu’ils soient open source contrairement
à Ranorex. En d’autres termes, ils sont entièrement gratuits à télécharger et à utiliser.
Mais, le plus gros point fort de Selenium qu’il est multiplateforme. Les deux autres outils
sont fonctionnels uniquement sur Windows et Mac. Selenium fournit une API appelée
WebDriver qui permet aux testeurs d’élaborer leurs tests dans de nombreux langages de
programmation, y compris Java, C, Python, PHP, JavaScript, etc. Pour Katalon, il n’uti-
lise que Java et Groovy. Ranorex utilise C, VB Net et Iron Python. Ce qui rend Selenium
un framework multi langage de programmation. Outre les navigateurs Web, nous pou-
vons également automatiser les tests des applications mobiles comme Android et iOS via
Appium (test automation framework) pour Selenium. Katalon Studio aussi peut automa-
tiser des applications web et mobile et Ranorex, web, mobile et desktop. Selenium offre
une documentation très large avec une communauté active mais elle est moyenne pour
Katalon et Ranorex.
Avec toutes ces capacités à portées de main, nous pourrions nous sentir déviés vers l’uti-
lisation de Selenium pour accomplir notre travail.
13
Table 2.1 – Tableau comparatif d’outils d’automatisation de test

Critères Selenium Katalon Studio Ranorex
Plateforme de Multiplateforme Windows / Mac Windows
test
Type d’applica- Web, mobile Web, mobile Web, mobile,
tion (avec Appium) desktop
Langage de Java, Python, Java, Groovy C, VB Net, Iron
programmation C, PHP, Ja- Python
supporté vaScript, Ruby,
Perl
Documentation Beaucoup de Documentation Documentation
documentation moyenne moyenne
et une commu-
nauté active
Type de licence Open-source Open-source Payante
2.3.1 Selenium
Selenium, dont le logo est présenté dans la figure 2.3, est un projet englobant un en-
semble d’outils et de librairies rendant possible et facile l’automatisation de navigateur
web.
Figure 2.3 – Selenium
Selenium est à la fois un enregistreur (player) de tests sur les différents navigateurs
(Chrome, Firefox, etc), un serveur de test, un driver de navigateur, un pilote de ser-
veur de test, etc.
Nous pouvons présenter le projet et les outils Selenium, comme l’indique aussi la figure
2.4, par :
— L’enregistreur de test : Il permet d’enregistrer les actions faites dans le projet
et de créer des scénarios de tests sans tarder, mais demande généralement d’être
complété pour avoir une couverture satisfaisante et globale.
— Les players de test permettent d’exécter les tests. Il existe deux grands types de
player :
— Les players locaux : ils tournent sur la machine de l’utilisateur et bloquent (au
moins partiellement) l’utilisateur (Ex : Selenium IDE, TestComplete, Katalon,
Ranorex).
— Les serveurs : ils tournent sur une machine liée ou non au projet. Ils sont
plus performants, ne bloquent pas l’utilisateur et peuvent s’intégrer dans un
workflow de développement (Ex : Selenium webdriver, IBM rational functional
tester, etc). Les actions sont les différentes commandes qui seront jouées dans
14
un test. Cela va du clic, à la gestion des variables, à la vérification des attributs

et leurs fonctionnalités.
— Les frameworks sont des outils d’écriture et de gestion des tests. Il en existe dans
de nombreux langages. Ils ont différentes approches, allant du très technique au
plus littéraire (Ex : Nightwatch (JS), Behat (PHP), CodeCeption (PHP), jBehave
(java), Specflow (c)).
— Les drivers sont les connecteurs entre le player de test et les navigateurs. Sur
les players locaux, ils sont généralement intégrés, mais dans le cadre de Selenium
webdriver, ils sont à installer indépendamment [l].
Figure 2.4 – Le projet et les outils Selenium
Selenium contrôle les navigateurs Web

Selenium est une multiplateforme, et à la base, un ensemble d’outils pour l’automa-
tisation du navigateur Web qui utilise les meilleures techniques valables pour contrôler
à distance les instances du navigateur et simuler son interaction avec un consomateur.
Il leur permet de simuler les activités courantes effectuées par les utilisateurs finaux :
saisir du texte dans les champs, sélectionner des valeurs déroulantes, cocher des cases,
cliquer sur les liens dans les documents, contrôler une image, etc. Il fournit également de
nombreux autres contrôles tels que le mouvement de la souris, l’exécution arbitraire de
JavaScript et encore plus. Bien qu’utilisé principalement pour les tests frontaux des sites
Web, Selenium est à l’origine une bibliothèque d’agent utilisateur de navigateur. Les in-
terfaces sont omniprésentes à leur application, qui encourage la composition avec d’autres
bibliothèques en fonction de but [m].
Une interface pour les gouverner tous

Un des principes directeurs du projet est de prendre en charge une interface com-
mune pour toutes les principales technologies de navigateur. Les navigateurs Web sont
des applications complexes et hautement conçues, effectuent leurs opérations de manière
complètement différente mais qui se ressemblent souvent en les faisant, même si le texte
15
est rendu dans les mêmes polices, les images sont affichées au même endroit et les liens
nous mènent à la même destination. Ce qui se passe en dessous est aussi différent. Sele-
nium résume ces différences, cache leurs détails et leurs subtilités à la personne qui écrit le
code. Cela nous permet d’écrire plusieurs lignes de code pour effectuer un flux de travail
compliqué, mais ces mêmes lignes s’exécutent sur Firefox, Internet Explorer, Chrome et
tous les autres navigateurs pris en charge [m].
Outils et supports
L’approche de conception minimaliste de Selenium lui confère polyvalence à inclure
en tant que composant dans des applications plus importantes. L’infrastructure environ-
nante fournie sous l’égide du Selenium nous donne les outils pour assembler notre grille de
navigateurs afin que les tests puissent être exécutés sur différents navigateurs et plusieurs
systèmes d’exploitation sur une gamme de machines. Grâce à une interface de program-
mation simple fournie pour les langues les plus courantes, ces tests se dérouleront sans
relâche en parallèle et nous rendent des rapports en cas d’erreur. C’est un objectif pour
nous aider, en nous fournissant des outils et de la documentation pour non seulement
contrôler les navigateurs, mais pour faciliter la mise à l’échelle et le déploiement de telles
grilles [m].
Utilisation de Selenium
Beaucoup des entreprises ont adopté Selenium pour leurs tests sur les navigateurs,
remplaçant souvent des efforts de plusieurs années impliquant d’autres outils propriétaires.
Vu qu’elle gagne en popularité, ses exigences et ses défis se multiplient. Alors que le Web
devient plus compliqué et de nouvelles technologies sont ajoutées, c’est la mission de
Selenium de les suivre autant que possible. Être un projet open source, est l’un des points
forts de cet outil [m].
2.3.2 Choix du langage de programmation

Les langages les plus populaires parmi la communauté Selenium sont Java, Python et
JavaScript. Pour décider le langage de programmation à choisir, nous tenons compte des
facteurs suivants :
— Quel langage de programmation est le plus utilisé pour développer les applications
Web que nous devons tester.
— Qui utilisera notre plateforme pour écrire des tests ou les réutiliser.
D’après notre recherche, Java, manifesté dans la figure 2.5, est le choix le plus sûr si
nous démarrons un nouveau projet à partir de zéro, car il est largement adopté par la
communauté en raison du fait qu’il fonctionne sur toutes les plateformes. De plus, nous
pouvons facilement trouver des exemples de code ou des conseils de dépannage si nous
somme bloqués. Java est également la priorité absolue pour chaque nouvelle version de
Selenium.
16
Figure 2.5 – Langage JAVA
Encore un point fort de Selenium, c’est que nous pouvons également écrire des tests
en utilisant la célèbre méthode BDD (Behavior-Driven Development).
En bref, BDD contribue à améliorer la lisibilité de nos tests en structurant un flux de test
en utilisant les instructions Given, When et Then ou And (GWT) qui n’est autre que le
langage Gherkin. En conséquence, non seulement les ingénieurs d’automatisation des tests
ayant des compétences en programmation, mais également les experts du domaine et les
testeurs d’entreprise peuvent comprendre les tests et contribuer de manière significative
au processus de création de test, de débogage des résultats de test et de leur maintenance.
Citons un exemple d’un test écrit en BDD :
Feature : Login Action

Scenario : Successful Login with Valid Credentials
Given User is on Home Page
When User Navigate to Login Page
And User enters name and password
Then Message displayed Login Successfully.
L’outil le plus répandu et le framework intégré dans le Webdriver Selenium que nous
pouvons utiliser si nous choisissons le BDD est Cucumber.
Cucumber
Cucumber, indiqué dans la figure 2.6, est une approche de test qui prend en charge le
développement basé sur le comportement BDD. Il représente la façon d’agir de l’applica-
tion dans un simple texte utilisant le langage Gherkin.
Figure 2.6 – Cucumber
Cucumber et Selenium sont deux technologies populaires. La plupart des organisations

utilisent Selenium pour les tests fonctionnels. Ces organisations qui utilisent Selenium
souhaitent intégrer Cucumber au Selenium car il facilite la lecture et la compréhension
du flux d’application.
17
Chapitre 2. Etat de l’art 2.4. Architecture de l’application
L’outil Cucumber est basé sur le cadre de développement axé sur le comportement qui
sert à lier entre les personnes suivantes :
— Ingénieur logiciel et analyste d’affaires.
— Testeur manuel et testeur d’automatisation.
— Testeur manuel et développeurs.
Cucumber permet également au client de comprendre le code de l’application car il utilise
le langage Gherkin qui est en texte brut, simple et compréhensible. N’importe qui dans
l’organisation peut comprendre le comportement du logiciel [n].
2.3.3 Framework de génération de test

Maintenant que nous avons sélectionné le langage de programmation le plus approprié,
nous devons ainsi choisir un framework de test sur lequel nous allons consulter les rapports
générés comme résultats de l’automatisation des tests. Comme nous avons déjà choisi le
langage Java pour écrire des tests, nous recommandons Junit, illustré dans la figure 2.7.
Figure 2.7 – JUnit
JUnit a joué un rôle très important dans le cadre de développement et de test pilotés.
Ce cadre de test utilise pour tester les applications écrites en Java et facilite et garantie
la conception de tests répétables. Une enquête de recherche réalisée en 2013 sur 10 000
projets Java hébergés sur GitHub a constaté que JUnit était la bibliothèque externe la plus
communément incluse. Chaque bibliothèque a été utilisée par 30,7 pourcent des projets
[m].
Après avoir bien choisi les outils dont nous allons utiliser pour la réalisation de l’au-
tomatisation des tests, nous devons passer à la mise en place de notre plateforme.
Par conséquent, il faut sélectionner une architecture sur laquelle se base notre travail. La
section prochaine présentera notre choix.
2.4 Architecture de l’application

Lors du développement de notre plateforme, nous avons souvent le choix entre diffé-
rents frameworks et architectures en fonction du langage dans lequel nous développons.
Plusieurs frameworks s’appuient désormais sur l’architecture dite MVC.
Le MVC (modèle vue contrôleur), présenté dans la figure 2.8, est une architecture de dé-
veloppement visant à séparer le code source en modules. En effet, ce modèle très répandu,
consiste à séparer distinctement l’accès aux données (bases de données), la vue affichée à
l’utilisateur et la logique métier.
18
Chapitre 2. Etat de l’art 2.4. Architecture de l’application
Cette architecture est la plus communément retrouvée au sein des applications web mais
existe également au niveau des applications lourdes, d’où vient notre choix.
Figure 2.8 – Architecture MVC
Le modèle
Le modèle définit les données utilisées par l’application. En effet, c’est ici que le lien
se fera entre notre application et notre base de données. Ces données pourront être mises
à jour dans le contrôleur et consultées au niveau de la vue.
La vue
La vue définit la façon dont les informations seront présentées à l’écran (via des compo-
sants par exemple). C’est l’interface utilisateur. Là, nous utiliserons les données récupérées
par le modèle afin de les présenter à l’utilisateur.
Le contrôleur
Dans le contrôleur, nous retrouvons toute la logique métier. Lorsque l’utilisateur inter-
agit avec la vue, la requête est traitée par le contrôleur. Il fonctionne comme un "listener",
il attend que l’utilisateur interagisse avec la vue pour en récupérer la requête. Alors, c’est
lui qui définit la logique d’affichage, et affichera la vue suivante à l’écran.
Avantages de cette architecture

L’architecture MVC a plusieurs avantages lors de la création et de la mise en place
d’un projet de développement d’une application web.
Elle facilite la maintenance et les évolutions futures. En effet, étant donné qu’il y a une
séparation entre les trois couches, il sera plus aisé de modifier uniquement la partie modèle
ou encore uniquement le traitement de la requête dans le contrôleur.
Encore, dans le cadre de structures avec des développeurs, il sera plus simple d’avoir un
développeur Front-end et un développeur Back-end travaillant sur la même application
étant donné que les fichiers sont séparés [p].
19
Chapitre 2. Etat de l’art 2.5. Choix techniques pour l’application
Vu que notre démarche nous conduit dans le développement avec Java, et pour utiliser
l’architecture présentée dans notre projet, nous trouvons que les frameworks Spring Boot
et Angular nous offrent le bon environnement pour la réalisation de notre application web.
2.5 Choix techniques pour l’application

Le développement d’une plateforme web nous permet de disposer d’une application qui
sera accessible depuis n’importe quel navigateur sur n’importe quel appareil. Dans cette
partie, nous présentons nos choix des outils de développement pour la partie Back-end et
la partie Front-end.
2.5.1 Partie back-end : Spring Boot

Le Micro Service est une architecture qui permet aux développeurs de réaliser et de
déployer des services indépendamment. Chaque service en cours d’exécution a son propre
processus, ce qui permet d’obtenir le modèle léger pour prendre en charge les applications
métier.
Les micro services offrent les avantages suivants à ses développeurs :
— Déploiement facile.
— Évolutivité simple.
— Compatible avec les conteneurs.
— Configuration minimale.
— Temps de production réduit.
Spring Boot, comme l’indique la figure 2.9, est un framework basé sur Java open source
utilisé pour créer un micro-service. Il est développé par Pivotal Team et est utilisé pour
créer des applications de Spring autonomes et prêtes pour la production.
Figure 2.9 – Spring Boot
Spring Boot fournit une bonne plateforme aux développeurs Java pour développer une ap-
plication Spring autonome et de production que nous pouvons simplement exécuter. Nous
pouvons commencer avec des configurations minimales sans avoir besoin d’une configura-
tion Spring complète.
Nous avons choisi Spring Boot en raison des fonctionnalités et des avantages qu’il offre,
comme indiqué ici :
— Il fournit un moyen flexible de configuration des beans Java et XML et les tran-
sactions de base de données.
— Il fournit un traitement par lots puissant et gère les points de terminaison REST.
— Dans Spring Boot, tout est configuré automatiquement ; aucune configuration ma-
nuelle n’est nécessaire.
— Il offre une application de ressort basée sur des annotations.
20
Chapitre 2. Etat de l’art 2.5. Choix techniques pour l’application
— Il facilite la gestion des dépendances.

— Il comprend un conteneur de servlet intégré.
Avantages
Spring Boot offre les avantages suivants à ses développeurs :
— Facile à comprendre et à développer des applications de ressort.
— Augmente la productivité.
— Réduit le temps de développement.
Buts
Spring Boot est conçu avec les objectifs suivants :
— Pour éviter une configuration XML complexe dans Spring.
— Pour développer plus facilement des applications Spring prêtes pour la production.
— Pour réduire le temps de développement et exécuter l’application indépendamment.
— Pour offrir un moyen plus simple de démarrage avec l’application [q].
2.5.2 Partie front-end : Angular8

Angular, manifesté dans la figure 2.10, est un framework Javascript côté utilisateur
client qui permet de réaliser des applications de type "Single Page Application". Il est basé
sur le concept de l’architecture MVC (Model View Controller) qui donne la possibilité de
séparer les données, les vues et les différentes actions que l’on peut effectuer.
Figure 2.10 – Angular
Depuis 2009 jusqu’à aujourd’hui, Google a sorti 3 différentes versions d’Angular : An-
gularJS (2009), Angular 2 (2016) et Angular 4 (2017).
A partir de la version 2, le framework a été complètement reformulé. AngularJS n’est
donc pas compatible avec les versions ultérieures. En contrepartie, il est possible de mi-
grer entre la version 2 et la version 4 [r].
Le code source d’Angular est écrit et développé en TypeScript. Le TypeScript est une
couche supérieur au Javascript développé par Microsoft qui se compile en JavaScript
simple. Il permet de créer des classes, des variables, des signatures de fonction et l’utili-
sation de modules, étant un langage typé. Il est important de souligner que l’utilisation
du TypeScript est optionnel, nous pouvons l’utiliser dans un fichier de ce même type.
21
Chapitre 2. Etat de l’art 2.6. Conclusion
Angular est basé sur une architecture de composants complètement indépendants les uns
des autres. Il analyse la vue HTML correspondante et détecte s’il comporte des compo-
sants imbriqués, une fois le composant principal est chargé. Si c’est le cas, Angular va
trouver toutes les correspondances et exécuter le code lié à celles-ci. Nous pouvons imbri-
quer autant de composants que nous le souhaitons.
Un composant dans ce framework alimente la génération d’une partie de code html et
fournit des fonctionnalités à celle-ci. Alors, un composant est constitué d’une classe dans
laquelle on pourra définir sa logique d’application avec des propriétés, des méthodes, etc
[r].
2.6 Conclusion
Dans ce chapitre, nous avons exposé l’importance de l’automatisation des tests. Puis,
nous avons présenté les choix technologiques pour la réalisation de notre travail.
Dans le prochain chapitre, nous allons aborder la spécification des besoins pour présenter
les besoins fonctionnels et non fonctionnels et décrire les différents cas d’utilisation en
spécifiant le Backlog Produit.
22
Chapitre 3
Spécification des besoins
3.1 Introduction
Ce chapitre décrit l’essentiel du travail effectué durant l’analyse et la spécification des
besoins. Pour l’établir, nous allons identifier les besoins fonctionnels et non fonctionnels.
Ensuite, nous décrivons l’aspect fonctionnel de notre application à travers le diagramme
de cas d’utilisations général. Et enfin, nous détaillons le Backlog Produit de notre travail.
3.2 Besoins fonctionnels

Pour une première partie, nous présentons l’ensemble des besoins fonctionnels auxquels
doit répondre notre solution. Vu que notre travail consiste à développer une plateforme
“TriTux” d’automatisation des tests, nous avons à :
— Développer des tests maintenables : Une fois écrits, nos tests peuvent être utilisés
encore et encore et maintenus, jusqu’à la fin de développement du produit. C’est
le cycle de vie de chaque projet qui implique la réalisation des tests à chaque
avancement.
— Couvrir tous les cas de test possibles : Grâce à l’automatisation, nous pouvons
rapidement couvrir un grand nombre de variantes de cas de test. Cela inclut l’in-
teraction avec plusieurs systèmes d’exploitation, navigateurs, appareils mobiles,
résolutions d’écran, vitesses de connexions, etc, ainsi que divers scénarios de com-
portement d’utilisateur.
— Détecter les anomalies en un temps limité : Grâce à l’automatisation, nous pouvons
gagner le temps.
— Vérifier la capacité de notre plateforme : Grâce aux tests automatisés développés,
nous pouvons vérifier la résilience de la solution examinée face à une armée virtuelle
innombrable de plusieurs utilisateurs actifs.
— Automatiser la génération de rapport : Nous aurons des journaux de tests prêts qui
listent précisément tous les tests effectués et les bugs trouvés dans le but de faciliter
le suivi du travail et nous donner une idée sur le succès ou l’échec de l’exécution
de nos tests automatisés. Cela peut guider et piloter les développeurs dans le cycle
de réalisation de projet.
23
Chapitre 3. Spécification des besoins 3.3. Besoins non fonctionnels
3.3 Besoins non fonctionnels

Dans cette partie, nous définissons les besoins non fonctionnels de notre travail :
— L’ergonomie : notre travail doit offrir une interface conviviale, facile à utiliser et
cohérente.
— La disponibilité : notre travail doit être accessible indépendamment des flux d’in-
formations entrés.
— La sécurité : le travail demandé nécessite une authentification pour y accéder.
— La performance : le temps de réponse doit être assez raisonnable.
3.4 Identification et structuration des cas d’utilisa-

tion
Nous présentons, dans cette partie, les acteurs et les différents cas d’utilisations qui
offrent des fonctionnalités spécifiques pour chaque utilisateur.
3.4.1 Identification des acteurs

Un acteur est une personne, un matériel ou un logiciel qui interagit avec le système
dans le but de réaliser une ou plusieurs fonctions concernant les cas d’utilisation. Les
acteurs, spécifiés dans le tableau 3.1, en interactions avec notre plateforme sont :
— Equipe qualité : Les testeurs.
— Equipe Software : Les développeurs des applications à tester, les chefs de projet et
les PO (Product Owner).
— Administrateur : Un responsable RH.
Table 3.1 – Identification des acteurs
Acteur Définition Rôle

Equipe qualité :Tes- C’est le concepteur et l’exé- Le testeur peut générer les plans,
teur cuteur des cas de tests. Il faire la configuration entre les
enregistre les exigences du scripts de tests et le code source
produit, prépare les scéna- de produit, exécuter les tests dé-
rios de tests et il enregistre veloppés et consulter les rapports.
les anomalies et les défauts
du produit dans l’outil.
Equipe software : Dé- C’est l’équipe responsable La consultation des scénarios et
veloppeurs, Chefs de de développement de pro- des rapports de tests pour avoir
projet et PO duit à tester. une idée sur les anomalies et les
défauts du produit.
Administrateur Cet utilisateur est le respon- L’administrateur gère les utilisa-
sable de gestion des comptes teurs en créant, modifiant ou sup-
utilisateurs et des projets. primant un et en plus, il est le res-
ponsable de la gestion des projets
en affectant à chaque utilisateur
un projet.
24
Chapitre 3. Spécification des besoins 3.5. Backlog Produit
3.4.2 Diagramme de cas d’utilisation globale

Les cas d’utilisation permettent de décrire sous forme d’actions et de réactions le sys-
tème du point de vue utilisateur. Ils donnent l’image d’une fonctionnalité du système
déclenché par une simulation d’acteur externe. Ils permettent de spécifier clairement et
exhaustivement les besoins relatifs à chaque type d’utilisateur.
Les diagrammes de cas d’utilisation modélisent à QUOI sert le système, en organisant les
interactions possibles avec les acteurs. Pour cela, nous décrivons les principales fonction-
nalitées de notre projet en spécifiant les actions que chaque utilisateur peut effectuer.
Figure 3.1 – Diagramme de cas d’utilisation général
La figure 3.1 représente le diagramme de cas d’utilisation général qui illustre qu’après une
authentification réalisée, un membre de l’équipe qualité peut gérer l’exécution de pro-
cessus de test automatique et les packages de tests en visualisant le projet à examiner.
Un membre de l’équipe software peut sélectionner un projet parmis ceux qu’il lui sont
attribués pour consulter ses tests déjà exécutés et ses rapports générés. L’Administrateur
gère tous les utilisateurs et les projets en les associant.
3.5 Backlog Produit

Le Backlog Produit, comme illustré dans le tableau 3.2, centralise la liste des exigences
attendues. Le Product Owner (chef de projet) s’approprie ce Backlog Produit et priorise
ses éléments en fonction de la valeur métier et du coût estimé de chacun. Le choix d’une
telle unité permet d’éviter la confusion entre le délais et le coût, souligne le caractère
estimatif (imprécis) et facilite la planification de libération et de Sprint (une période
pendant laquelle un travail spécifique doit être mené à bien avant de faire l’objet d’une
révision). Ces estimations sont réalisées dans un premier temps à partir d’un besoin peu
détaillé, il peut être révisé au cours de la planification d’itérations en cas d’écart par
rapport aux hypothèses établies lors de la première estimation [s].
25
Chapitre 3. Spécification des besoins 3.5. Backlog Produit
Table 3.2 – Backlog Produit
Sprint User Story En tant que ... Je veux ... Priorité

Conception et Authentification Administrateur M’authentifier 1
réalisation de
profil “Adminis-
trateur”
Gestion des uti- Administrateur Gérer les utilisa- 2

lisateurs teurs
Gestion des pro- Administrateur Gérer les projets 2

jets
Affectation des Administrateur Associer chaque 2

projets à des uti- projet à un rôle
lisateurs
Conception et Authentification Equipe qualité M’authentifier 1
réalisation de
profil “Equipe
qualité”
Visualisation de Equipe qualité Voir le contenu 2

projet à tester de projet à tester
Gestion de l’exé- Equipe qualité Exécuter le pro- 2

cution de test cessus de tester
automatique pour le projet
Gestion des pa- Equipe qualité Avoir la possibi- 3

ckages de tests lité de gérer les
cas de test
Conception et Authentification Equipe software M’authentifier 1
réalisation de
profil “Equipe
software“
Sélectionner un Equipe software Devoir sélec- 3

projet pour voir tionner un
les résultats de projet avant la
test consultation
Consultation des Equipe software Avoir la possibi- 3

résultats de tests lité de voir les
tests déjà exécu-
tés sur le pro-
duit et les rap-
ports générés
26
Chapitre 3. Spécification des besoins 3.6. Conclusion
3.6 Conclusion
Dans ce chapitre, nous avons présenté les besoins fonctionnels et non fonctionnels.
Puis nous avons décrit le diagramme de cas d’utilisation globale et le Backlog Produit de
notre projet.
Le chapitre suivant va entamer notre premier Sprint celui de premier profil : Administra-
teur.
27
Chapitre 4
Sprint 1 : Profil Administrateur
4.1 Introduction
Dans ce chapitre, nous commençons la mise en place des profils. En appliquant la
méthodologie Agile, notre premierSprint se présente dans une conception et une réalisation
du profil : Administrateur, en mettant en œuvre ses principales fonctionnalités. Nous
présentons le Sprint Backlog, les diagrammes de cas d’utilisations, de séquences, de classe
et finalement nous illustrons les modules réalisés relatifs à ce Sprint.
4.2 Sprint Backlog

Le Sprint Backlog est une partie des User Stories du Backlog Produit que l’équipe
s’engage à livrer dés le début à la fin du Sprint d’où les User Stories sont mises dans le
Sprint Backlog en fonction de leur valeur et de leur complexité technique.
Une User-Story arrive dans un Sprint Backlog au début du Sprint, au cours de la Sprint
Planning Meeting : le Product Owner propose l’ensemble des User-Stories qui le constitue-
ront au début du Sprint. La User-Story en sortira au moment de la réalisation complète
du Sprint avec Sprint Rétrospective. Comme ceci, le travail le plus important s’effectuera
en premier conformément à sa priorité [t].
Après la sélection des fonctionnalités présentes dans le Backlog Produit, que nous devons
réaliser durant ce premier Sprint, nous présentons le Sprint Backlog 1 détaillé dans le
tableau 4.1 avec une description affinée de chaque tâche fonctionelle et une estimation
pour sa difficulté.
28
Chapitre 4. Sprint 1 : Profil Administrateur 4.2. Sprint Backlog
Table 4.1 – Sprint Backlog 1

Id User Story Id Tâche Estimation
1 Étant un administra- 1.1 Créer un nouvel utili- 7
teur, je peux gérer les sateur.
utilisateurs.
1.2 Modifier un utilisa- 6

teur.
1.3 Consulter un utilisa- 5

teur.
1.4 Supprimer un utilisa- 5

teur.
1.5 Affecter un utilisateur 5

à un rôle.
2 Étant un administra- 2.1 Créer un nouveau pro- 7
teur, je peux gérer les jet.
projets.
2.2 Modifier un projet. 6
2.3 Consulter un projet. 5
2.4 Supprimer un projet. 5

3 Étant un administra- 3 Affectation des projets 8
teur, je peux associer à un rôle.
chaque projet avec un
rôle.
4 Étant un administra- 4.1 Entrer un login. 7
teur, je dois m’authen-
tifier.
4.2 Entrer un mot de 7

passe.
Pour mieux illustrer les différentes manières dont l’administrateur peut interagir avec
le système, les fonctionnalités mentionnées dans le Sprint Backlog 1 sont représentées
dans un diagramme de cas d’utilisation dans la figure 4.1.
Cette figure montre que l’Administrateur doit s’authentifier en saisissant son login et son
mot de passe. Encore, il est capable de gérer les utilisateurs en les créant, modifiant,
consultant, supprimant ou l’affectant à un rôle. Il peut aussi gérer les projets à tester en
appliquant le même principe. Et sa dernière fonctionnalité est d’affecter les projets que
nous voulons tester à des rôles.
29
Chapitre 4. Sprint 1 : Profil Administrateur 4.3. Conception
Figure 4.1 – Diagramme de cas d’utilisation “Administrateur”
4.3 Conception
Dans cette section, nous présenterons les différents diagrammes de séquence détaillés
et le diagramme de classe pour ce premier Sprint.
4.3.1 Diagrammes de séquences

Les diagrammes de séquences permettent de décrire COMMENT les éléments du sys-
tème interagissent entre eux et avec les acteurs :
— Les objets au coeur d’un système interagissent en s’échangent des messages.
— Les acteurs interagissent avec le système au moyen d’IHM (Interfaces Homme-
Machine).
Nous présenterons dans ce qui suit les diagrammes de séquence détaillés des principales
User Stories du premier Sprint.
Diagramme de séquence : Authentification

Ce scénario présente la procédure d’authentification. L’utilisateur saisit les informa-
tions requises et valide le formulaire. Une vérification est effectuée au niveau du contrôleur.
30
Si les données saisies sont incorrectes, un message d’erreur s’affiche pour refaire la saisie.
La figure de référence 4.2 illustre le diagramme de séquence d’authentification.
Figure 4.2 – Diagramme de séquence “Authentification”
Diagramme de séquence : Créer un utilisateur

Ce scénario présente la procédure pour ajouter un utilisateur manuellement (création
d’un utilisateur). L’administrateur saisit le nom, le prénom, le login, le mot de passe et
sélectionne le rôle : c’est à dire équipe qualité ou équipe software ou un autre adminis-
trateur. Puis, il envoie les informations au contrôleur. Une vérification est effectuée au
niveau du contrôleur pour voir si l’utilisateur existe déjà. Si ce n’est pas le cas, un nouvel
utilisateur est ajouté.
La figure 4.3 illustre le diagramme de séquence de l’ajout d’un utilisateur.
31
Figure 4.3 – Diagramme de séquence “ Créer un utilisateur”
Diagramme de séquence : Modifier un utilisateur

Ce scénario présente la procédure de modification d’un utilisateur manuellement.
L’administrateur saisit les nouvelles informations dont il souhaite modifier, le login par
exemple. Une vérification est effectuée par le contrôleur pour voir si le login n’est pas déjà
utilisé. Si ce n’est pas le cas, il est correctement mis à jour, sinon un message d’erreur est
renvoyé.
La figure 4.4 illustre le diagramme de séquence de modification des informations d’un
utilisateur.
32
Figure 4.4 – Diagramme de séquence “ Modifier un utilisateur”
Diagramme de séquence : Supprimer un utilisateur

Ce scénario présente l’administrateur qui prend en charge la suppression d’un utilisa-
teur. Il récupère la liste des utilisateurs puis il sélectionne ceux qu’il souhaite supprimer.
Il confirme ensuite son choix et envoie la liste au contrôleur. Une vérification est effectuée
au niveau du contrôleur pour voir si l’utilisateur existe ou pas. Si l’utilisateur subsiste, il
est supprimé, sinon un message indiquant que l’utilisateur n’existe plus est renvoyé.
La figure 4.5 représente le diagramme de séquence de suppression d’un utilisateur.
33
Figure 4.5 – Diagramme de séquence “ Supprimer un utilisateur”
Diagramme de séquence : Affectation d’un projet à un rôle

Ce scénario présente l’administrateur qui prend en charge l’association d’un projet à
un rôle. Ayant la liste des rôles : équipe qualité et équipe software, devant lui, il peut
choisir parmis eux celui qu’il veut lui affecter un nouveau projet, puis il sélectionne un et
termine par “Enregistrer” ou “Annuler”.
La figure 4.6 représente le diagramme de séquence d’affectation d’un utilisateur à un pro-
jet.
34
Figure 4.6 – Diagramme de séquence “ Affectation d’un projet à un rôle”
4.3.2 Diagramme de classe

Le diagramme de classes permet de spécifier la structure et les liens entre les objets
dont le système est composé : il spécifie QUI sera à l’oeuvre dans le système pour réaliser
les fonctionnalités décrites par les diagrammes de cas d’utilisation.
La figure 4.7 illustre le diagramme de classe associé à la conception de notre premier
Sprint :
— User : une classe formée par les coordonnées d’un utilisateur dont ses attributs sont
“login”, “mdp”, “nom”, et “prenom”.
— Rôle : cette classe est responsable d’identifier à chaque utilisateur un rôle : Admi-
nistrateur, Equipe qualité ou Équipe software indiqué par l’attribut “nom”.
— Projet : la classe projet réunit tous les projets à tester. Ses attributs sont “nom” et
“url”, via lequel l’utilisateur peut accéder à l’application web dans son navigateur.
— Package Test : c’est la classe où nous pouvons trouver tous les cas de tests. Chaque
package est unique ayant un attribut “nom” différent. Cette classe rassemble tous
les scénarios de tests qui peuvent être utilisés par un membre de l’Équipe qualité
pour tester le projet ou ajouter d’autres cas de test, ou bien par l’Équipe software
pour consulter les scripts en BDD et les rapports générés.
— Script : Cette classe contient les scripts développés en Java.
— BDD : Cette classe contient les scripts développés en BDD.
Cette figure montre aussi comment l’administrateur peut interagir avec les différentes
classes de ce Sprint. Il gère la classe user en appliquant les méthodes : créer, modifier,
consulter, supprimer et lui ajouter un rôle. Il gère aussi la classe projet en appliquant
les mêmes méthodes. Tandis que pour la classe rôle, il peut sélectionner un rôle pour
l’attribuer à un utilisateur.
35
Chapitre 4. Sprint 1 : Profil Administrateur 4.4. Réalisation
Figure 4.7 – Diagramme de classe "Administrateur"
4.4 Réalisation
Dans cette partie, nous présenterons les différents modules réalisés relatifs au premier
Sprint.
4.4.1 Authentification et Espace Admin

La figure 4.8 montre le module de connexion où l’utilisateur doit saisir son nom d’uti-
lisateur et son mot de passe pour pouvoir accéder à l’application.
Figure 4.8 – Interface "Authentification"
Si l’utilisateur entre le nom d’utilisateur ou le mot de passe d’une manière incorrecte,

un message d’alerte s’affiche comme le montre la figure 4.9.
36
Figure 4.9 – Interface "Erreur d’authentification"
Une fois l’utilisateur est bien identifié, et plus précisément l’administrateur, il se trouve
dans l’interface Espace admin. A travers cette interface, l’administrateur peut gérer ses
différentes fonctionnalitées comme l’illustre la figure 4.10.
Figure 4.10 – Espace "Administrateur"
4.4.2 Gestion des utilisateurs

L’une des fonctionnalitées attribuées à l’administrateur est la gestion des utilisateurs.
Par conséquent, il peut le créer, consulter, modifier, supprimer et à l’effecter à un rôle.
La figure 4.11 montre comment il peut créer un nouvel utilisateur.
37
Figure 4.11 – Interface "Création utilisateur"
La figure 4.12 montre les différentes étapes de la création d’un utilisateur : la saisie
du nom, prénom, login et mot de passe.
A partir de cette interface, l’administrateur doit aussi lui affecter un rôle (équipe qualité
ou software). Et il termine cette tâche en cliquant sur "Enregistrer" ou "Annuler".
Figure 4.12 – Interface "Saisie de données utilisateur"
Par la suite, nous pouvons trouver que l’utilisateur est bien ajouté dans la liste des
utilisateurs comme l’illustre la figure 4.13.
38
Figure 4.13 – Interface "Liste d’utilisateurs"
En gérant les utilisateurs, l’administrateur peut évidemment consulter et modifier leurs

attributs. La figure 4.14 illustre cette tâche. L’administrateur peut changer les ou l’un
des champs et il confirme ou annule par un simple clique sur "Enregistrer" ou "Annuler".
Dans cet exemple, il change le nom de l’utilisateur.
Figure 4.14 – Interface "Consultation et modification d’un utilisateur"
Par conséquent, nous pouvons également constater que les données de cet utilisateur
ont changé dans la liste comme montré dans la figure 4.15.
39
Figure 4.15 – Interface "Modification utilisateur"
La suppression d’un utilisateur est aussi possible. A travers la liste affichée des uti-
lisateurs enregistrés, l’administrateur peut choisir un ou plusieurs qu’il veut supprimer
et il clique sur l’icône de la corbeille. Une fois la procédure est terminée, un message de
confirmation s’affiche comme le montre la figure 4.16.
Figure 4.16 – Interface "Suppression d’un utilisateur"
4.4.3 Gestion des projets

L’administrateur est la seule personne responsable de la gestion des projets et de les
affecter à des utilisateurs.
La figure 4.17 présente cette espace. Là aussi, il peut consulter les projets déjà ajoutés,
les modifier, ajouter un nouveau rôle en cliquant sur l’icône plus du projet, ajouter un
nouveau projet ou bien supprimer un ou plusieurs.
40
Figure 4.17 – Interface "Gestion de projets"
La figure 4.18 montre comment un administrateur peut ajouter un nouveau projet.

Cette étape consiste à taper le nom du projet et son url. Puis, il la termine par un clique
sur "Enregistrer" ou "Annuler". Comme exemple, nous pouvons citer l’application web
“Youtube” et son url.
Figure 4.18 – Interface "Ajout d’un projet"
L’administrateur peut également supprimer un ou plusieurs projets déjà ajoutés.

Cette tâche consiste à sélectionner le nom du projet qu’il veut éliminer et la termine avec
un clique sur "Enregistrer" ou "Annuler" comme l’indique la figure 4.19.
41
Figure 4.19 – Interface "Suppression d’un projet"
La figure 4.20 indique aussi qu’à partir de l’interface de gestion des projets, l’adminis-
trateur peut affecter un projet à un rôle. Pour cette raison, il sélectionne le nom de rôle
et le nom de projet et il termine par "Enregistrer" ou "Annuler".
Figure 4.20 – Interface "Affectation d’un projet à un rôle"
L’administrateur peut aussi supprimer un projet déjà affecté pour un rôle. La figure
4.21 illustre cette tâche. Il sélectionne parmis ceux qu’ils sont déjà attribués à une équipe
bien déterminée et termine par “Enregistrer” ou “Annuler”.
42
Chapitre 4. Sprint 1 : Profil Administrateur 4.5. Conclusion
Figure 4.21 – Interface "Supprimer un projet pour un rôle"
4.5 Conclusion
Dans ce chapitre, nous avons détaillé la conception et la réalisation du premier Sprint :
administrateur.
Dans le chapitre d’après, nous allons établir le même démarche pour la mise en place du
deuxième acteur : Equipe qualité.
43
Chapitre 5
Sprint 2 : Profil Equipe qualité
5.1 Introduction
Dans ce chapitre, notre deuxième Sprint se présente dans une conception et une réa-
lisation du deuxième profil à savoir l’Équipe qualité : Testeurs, en mettant en œuvre ses
principales fonctionnalités. Nous présentons le deuxième Sprint Backlog, les diagrammes
de cas d’utilisations, de séquences, de classe et finalement nous illustrons les modules
réalisés relatifs au deuxième Sprint.
5.2 Sprint Backlog

Dans cette section, nous présentons le Sprint Backlog 2 relatif au deuxième acteur et
détaillé dans le tableau 5.1 avec une description affinée de chaque tâche et une estimation
pour sa difficulté.
44
Chapitre 5. Sprint 2 : Profil Equipe qualité 5.2. Sprint Backlog
Table 5.1 – Sprint 2 Backlog

1 Étant un testeur, je 1.1 Étant un testeur, je 7
peux visualiser le pro- peux visualiser le pro-
jet à tester. jet à tester.
1.2 Visualiser les diffé- 6

rents modules du pro-
jet à tester.
2 Étant un testeur, je 2.1 Ecrire les tests en 6
peux gérer l’exécution scripts BDD, les déve-
de processus de test lopper en Java et pré-
automatique. parer la classe d’exé-
cution.
2.2 Préparer l’environne-

ment de test sur la
plateforme d’automa-
tisation avec l’implé-
mentation des scripts
déjà développés et des
rapports.
2.3 Lancer l’exécution des 5

tests dans l’IDE.
2.4 Consulter les rapports 5

des tests déjà générés.
3 Étant un testeur, je 3.1 Ajouter un package de 8
peux gérer les pa- test selon le besoin.
ckages de test.
3.2 Consulter un package 5

de test.
3.3 Modifier un package 5

de test.
3.4 Supprimer un package 5

de test.
4 Étant un testeur, je 4.1 Entrer un login. 7
dois m’authentifier.

passe.
45
Chapitre 5. Sprint 2 : Profil Equipe qualité 5.2. Sprint Backlog
Pour mieux illustrer les différentes manières dont les testeurs peuvent interagir avec le
système, les fonctionnalités mentionnées dans le Sprint Backlog 2 sont illustrées dans un
diagramme de cas d’utilisation de la figure 5.1.
Figure 5.1 – Diagramme de cas d’utilisation “Equipe qualité”
La figure 5.1 montre qu’un testeur : équipe qualité, peut être authentifié en entrant
son login et son mot de passe pour accéder à notre plateforme et commencer son travail.
Dans un premier lieu, il peut visualiser le projet à tester en sélectionnant un qui lui est
déjà attribué et ça lui donne la possibilité de consulter ses différents modules à tester.
Puis, il passe à la gestion de l’exécution de processus de test automatique. Par conséquent,
il commence par ouvrir son IDE (dans notre cas c’est l’IntelliJ IDEA), écrire les scénarios
des tests en script BDD et les développer en Java, puis il doit développer le script d’exé-
cution et le lancer. Une fois terminé, le testeur ferme son IDE. Cela provoque la création
d’un dossier sur son terminal, portant le nom du projet, où nous pouvons trouver tous les
scripts déjà développés et stockés et les rapports déjà générés.
Dès qu’il termine cette étape, il passe à la préparation de l’environnement de test sur la
plateforme d’automatisation. Il importe le ou les fichiers dont les packages de tests et les
scénarios sont déjà développés, à partir du schéma exact. Et il importe encore les rapports
déjà générés.
Ensuite, il termine avec la consultation des résultats sous forme des rapports.
Au cours de préparation d’un projet, ce dernier peut passer par plusieurs étapes et plu-
sieurs éléments peuvent être gérés, d’où la dernière fonctionnalité d’un testeur se présente
dans la gestion des packages de tests en les créant, modifiant, consultant ou bien les sup-
primant à partir de son IDE.
46
Chapitre 5. Sprint 2 : Profil Equipe qualité 5.3. Conception
5.3 Conception
qui décrivent comment et dans quel ordre notre acteur : l’équipe qualité, et les autres objets
fonctionnent ensemble, et le diagramme de classe qui représente les différents éléments
composants de notre système et leurs relations dans ce deuxième Sprint.

Nous présenterons dans ce qui suit les diagrammes de séquence détaillés des principales
User Stories du deuxième Sprint.
Diagramme de séquence : Visualiser le projet à tester

Pour tester une application web, le testeur entame la première étape, celle de visuali-
ser le projet et de se familiariser avec ses différents modules, éléments et fonctionnalités.
Après une authentification réussie (voir figure de référence 4.2 du diagramme de séquence
"Authentification"), un testeur se trouve dans son espace. La première phase consiste à
sélectionner un projet parmis ceux qui lui sont affectés, et il clique sur visualiser. Cela lui
permet d’accéder, à travers l’url du projet, à l’application web en cours de développement
ou déjà développée dans le navigateur pour commencer son travail d’analyse des spécifi-
cations (fournies par l’équipe software).
La figure 5.2 illustre bien la première étape.
Figure 5.2 – Diagramme de séquence “Visualiser projet”
47
Diagramme de séquence : Exécuter les tests préparés et générer le rapport

Avant de passer à la deuxième étape, un testeur doit écrire les scripts en BDD des
scénarios qu’il veut tester, les développer en Java et réaliser leurs exécutions. Cela implique
qu’il doit ouvrir son IDE. Sur cette interface, il commence par créer un nouveau "feature"
(package pour les tests en BDD) là où il peut écrire le scénario de test en BDD (en utilisant
les mots clés : Given, When et Then ou And). Une fois terminé, il doit ensuite créer un
nouveau "step" (package pour les scripts de tests en Java) et traduire chaque ligne de
BDD en Java à l’aide des bibliothèques Java, Selenium et Cucumber. Et il termine par
développer la classe "runner" là où il peut exécuter son travail. Cela consiste à effectuer
l’exécution de chaque package de test à part. Pour cette raison, il doit saisir le schéma de
“Feature”, le scénario qu’il veut exécuter et clique sur “Run”MainRunner”” depuis l’IDE.
L’implémentation d’un scénario de test provoque la génération de son rapport dans la
classe “junit-xml”.
La figure 5.3 illustre la tâche d’exécution de test.
Figure 5.3 – Diagramme de séquence “Exécution des tests et génération du rapport”
Diagramme de séquence : Préparer l’environnement de test sur la plateforme

Quand il finit son travail de développement, le testeur ferme son IDE. Cela provoque
une création d’un dossier sur son terminal dont nous pouvons trouver le travail réalisé
enregistré.
Passons à la deuxième étape, dans notre processus, qui consiste à préparer l’environne-
ment de test. Le testeur doit importer, d’après son terminal et le schéma exact de stockage
du dossier, le ou les packages de tests déjà développés et qu’il a exécuté sous forme des
fichiers.
48
La figure 5.4 montre comment le testeur clique sur le bouton “BDD” d’après l’interface
de la deuxième étape pour importer les fichiers en script BDD et les ajouter à la classe
"BDD" de la base de données.
Comme ça, il peut partager son progrès du travail (les scénarios traités) avec les autres
testeurs et l’équipe software qui travaillent sur le même projet.
Figure 5.4 – Diagramme de séquence “Importation des fichiers ’Feature’”
La même procédure est établie pour l’importation des fichiers en script Java et leur
ajout dans la classe "Script" de la base de données, d’où il clique sur "Script", comme
illustrée dans la figure 5.5. Cette procédure est réalisée pour partager les script réalisés
entre les testeurs qui travaillent sur le même projet et pour les réutiliser dans le cas de
nécessité.
49
Figure 5.5 – Diagramme de séquence “Importation des fichiers ’Steps’”
Diagramme de séquence : Importer les rapports des tests exécutés

Après la préparation de l’environnement du test, le testeur se trouve dans la troisième
étape, là où il doit importer les rapports déjà générés et qu’il veut les visualiser et les
stocker dans la classe "package-test" de la base de données.
Cette importation offre aussi la possibilité de partager ces rapports avec l’autre acteur :
l’équipe software, pour les examiner aussi comme résultat. Cette importation consiste à
implémenter le schéma exact du rapport dans le dossier.
Le diagramme de séquence relatif à cette importation est illustré dans la figure 5.6.
50
Figure 5.6 – Diagramme de séquence “Importation des rapports générés”
Diagramme de séquence : Consulter les rapports des tests exécutés

Une fois l’importation des rapports de test est terminée, les résultats de ces derniers
sont stockés sous forme des rapports dans l’entité "package-test" de la base de données.
Pour consulter ces rapports, le testeur se trouve dans la dernière étape et termine son
travail par cliquer sur "terminer" comme l’indique la figure 5.7. Cette présentation se ma-
nifeste sous forme des rapports bien détailés pour être plus claire et significative. Cette
génération est possible à l’aide de la classe “Junit” ajoutée dans le paquet “pom.xml”
dans notre IDE.
51
Figure 5.7 – Diagramme de séquence “Consulter les rapports des tests exécutés”

La figure 5.8 illustre l’interaction entre les différentes classes de ce Sprint et le testeur.
Dans un premier lieu, un membre de l’équipe qualité doit visualiser le projet à tester.
Cette étape invoque les méthodes “Sélectionner” et “Consulter” dans la classe “projet”
de la base de données.
D’autre part, il gère le processus de l’exécution du test automatique sur la plateforme.
Comme il doit écrire les tests en script BDD et les développer en Java, il va “Insérer”
dans la classe “Feature” de son IDE pour rédiger des scénarios en BDD, et dans la classe
“Steps” pour les traduire en Java. En plus de l’insertion, il peut évidemment modifier,
consulter ou supprimer un ou plusieurs scripts.
L’étape de préparation de l’environnement de test consiste à importer les packages-tests
déjà développés. Il doit “Sélectionner” alors les fichiers générés à partir des classes “Steps”
et “Features”. Cette action provoque aussi l’insertion de ces données dans les champs des
attributs “Fichier” et “Script” de la classe “BDD” et "Script" dans la base de données.
Passant à l’exécution des packages, l’interprétation des ces derniers se déroule dans la
classe “runner” et amène à la génération des rapports dans la classe “junit-xml” dans
l’IDE. Les rapports sont ajoutés dans la classe “package-test” de la base de données dont
l’attribut est “rapport” après leur importation d’après l’interface de notre plateforme pen-
dant la génération de processus de test.
52
Chapitre 5. Sprint 2 : Profil Equipe qualité 5.4. Réalisation
Figure 5.8 – Diagramme de classe "Equipe Qualité"
5.4 Réalisation
Dans cette partie, nous présenterons les différents modules réalisés relatifs au deuxième
Sprint.
Un membre de l’équipe qualité : un testeur, passe par différentes étapes afin de réaliser
son travail. Par conséquent, nous avons choisis de répartir ses fonctionnalités principales
en 4 étapes. Ces dernières seront bien explicites dans les prochaines sections.
5.4.1 Espace Equipe Qualité

Après une authentification réussie, le testeur se trouve dans son espace comme l’in-
dique la figure 5.9, là où il peut réaliser ses fonctionnalités en passant par différentes
étapes jusqu’à la consultation des résultats.
53
Figure 5.9 – Interface "Espace Equipe Qualité"
5.4.2 Visualiser le projet à tester

La première étape que doit accomplir le testeur est de visualiser le projet qu’il va
travailler dessus pour se familiariser avec l’interface qu’il doit tester, ces différents com-
posants et ces différentes fonctionnalités.
Pour cette raison, l’application web dans la figure 5.10 présente comment il peut sélec-
tionner l’un des projets qui lui sont attribués afin de le consulter dans le navigateur, en
passant par son "url".
Figure 5.10 – Interface "Sélectionner un projet"
54
Juste après, le testeur se trouve dans une nouvelle interface dans le navigateur. Dans
notre exemple, le testeur a choisi de tester le projet "Jumia". D’où, la page d’accueil de
cette application est ouverte comme montré dans la figure 5.11.
Figure 5.11 – Interface "Page d’accueil du projet"
5.4.3 Préparation et gestion du processus test automatique

Développement et gestion des packages-tests
Après avoir bien consulté l’interface de l’application web à tester et en se basant sur
les différentes exigences demandées par l’équipe software, le testeur commence son déve-
loppement des tests automatisés.
La gestion des packages des tests est réellement réalisée dans l’IDE, là ou un membre
de l’équipe qualité peut créer, consulter, modifier ou supprimer un cas de test selon son
besoin.
Maintenant, il doit préparer les scénarios qu’il veut tester et développer les scripts néces-
saires.
Dans cette étape, il ouvre son IDE (IntelliJ) et entame l’écriture des scénarios des tests
en script BDD comme dans la figure 5.12.
55
Figure 5.12 – Interface "Scénario de test en BDD - Feature"
Puis, il traite les scénarios en script BDD en un code Java à l’aide de Selenium.
C’est la tâche de l’automatisation des tests, là où il fait appel à plusieurs bibliothèques
comme cucumber.api.java : lorsque Cucumber analyse les étapes, il recherche des méthodes
annotées avec des mots clés Gherkin pour localiser les définitions d’étape correspondantes,
comme dans notre exemple dans la figure 5.13, ces définitions d’étapes sont définies dans
une classe du même package avec CucumberTest. Et la bibliothèque org.openqa.selenium,
qui contient la classe WebDriver nécessaire pour instancier un nouveau navigateur chargé
avec un pilote spécifique.
Figure 5.13 – Interface "Scénario de test en java - Step1"
56
Ensuite, il transforme chaque ligne de script en BDD en un script Java bien précis en
utilisant des différentes méthodes.
La figure 5.14 montre des exemples déjà développés.
Figure 5.14 – Interface "Scénario de test en java - Step2"
Exécution des tests

Par la suite, il développe la classe “runner” chargée de lancer l’exécution des scéna-
rios voulus comme illustré dans la figure 5.15. Dans cette étape, il doit saisir le nom de
"Feature" et du scénario dans les champs "features" et "tags" respectivement.
Figure 5.15 – Interface "La classe d’exécution"
Cette exécution est possible en cliquant sur l’icône à côté du nom de cette classe et puis
sur “Run ‘Main Runner’”, et représentée dans la figure 5.16.
57
Figure 5.16 – Interface "Exécution de test"
5.4.4 Préparation de l’environnement de test automatique

La deuxième étape nous donne la possibilité d’importer notre travail réalisé dans l’IDE
sur notre plateforme. Cette action consiste à déposer des fichiers depuis le terminal géné-
rés par l’IntelliJ dans un dossier du projet. La figure 5.17 présente cette étape.
Figure 5.17 – Interface "Etape 2 : Préparation de l’environnement de test automatique"
Dans la même étape, le testeur clique sur le premier bouton “BDD” pour importer
les fichiers des “Feature” qu’il désire. Cette action provoque l’apparition d’une nouvelle
interface là où il peut sélectionner le schéma du fichier, comme indiqué dans la figure 5.18.
58
Figure 5.18 – Interface "Importation des fichiers "Feature""
Ensuite, le testeur clique sur le deuxième bouton “Script” pour importer les fichiers des
“Steps” dont leurs “Feature” sont déjà sélectionnés. Cette action provoque l’apparition
d’une nouvelle interface là où il peut sélectionner comme indiqué dans la figure 5.19.
Figure 5.19 – Interface "Importation des fichiers "Steps""
La figure 5.20 montre que tous les fichiers nécessaires sont importés avec succès. Main-
tenant le testeur doit cliquer sur “Suivant” pour passer à la prochaine étape celle de l’exé-
cution des tests d’une manière automatique sur notre plateforme.
59
Figure 5.20 – Interface "Etape 2 : Sélection des fichiers"
Passant à la troisième étape, et comme la procédure de l’importation des fichiers, le

testeur doit importer aussi les rapports nécessaires pour pouvoir les visualiser. La figure
5.21 illustre bien cette étape.
Figure 5.21 – Interface "Etape 3 : Imortation des rapports"
Alors, le testeur doit importer le schéma du rapport depuis son dossier. Pour mieux
présenter cette tâche, nous présentons la figure 5.22.
60
Figure 5.22 – Interface "Etape 3 : Insertion du schémas du rapport"
5.4.5 Consultation des rapports

La dernière étape pour un testeur est de consulter les rapports générés comme l’illustre
la figure 5.23.
Figure 5.23 – Interface "Etape 4"
Le testeur sélectionne un parmis les rapports pour le visualiser, comme l’indique la

figure 5.24.
61
Chapitre 5. Sprint 2 : Profil Equipe qualité 5.5. Conclusion
Figure 5.24 – Interface "Sélectionner rapport"
Les résultats du test sont présentés sous forme de rapport, ouvert dans le navigateur,
comme illustrés dans la figure 5.25, pour éclaircir les sorties du test pour l’équipe qualité.
Dans cet exemple, nous désirons présenter le succès des deux premières lignes du scénario
“Creer un compte methode1” d’où leur coloration en vert, l’échec de la troisième ligne en
rouge avec la description détaillée du problème et l’ignorance des autres tests en bleu.
Figure 5.25 – Interface "Rapport"
5.5 Conclusion
Dans ce chapitre, nous avons détaillé la réalisation du deuxième Sprint qui consiste à
la création du profil équipe qualité.
Dans notre suivant chapitre, nous allons établir le même travail pour le dernier acteur :
Equipe software.
62
Chapitre 6
Sprint 3 : Profil Equipe software
6.1 Introduction
Dans ce dernier chapitre, notre dernier Sprint se présente dans une conception et une
réalisation du troisième profil à savoir l’Équipe software : Les développeurs de projet, les
chefs de projet et les PO (Product Owner). Nous présentons le troisième Sprint Backlog,
les diagrammes de cas d’utilisations, de séquences, de classe et finalement nous illustrons
les modules réalisés relatifs au dernier Sprint.
6.2 Sprint Backlog

Pour ce dernier chapitre, et après la déffinition des fonctionnalités, relative à cet acteur,
présentées dans le Backlog Produit, nous présentons le Sprint Backlog 3 détaillé dans le ta-
bleau 6.1 avec une description affinée de chaque tâche et une estimation pour sa difficulté.
Table 6.1 – Sprint 2 Backlog

1 Étant un membre de 1.1 Sélectionner un projet 7
l’équipe software, je
peux sélectionner un
projet pour consulter
les résultats
2 Je peux consulter les 2.1 Consulter les BDDs 7
résultats des tests. des tests réalisés sur le
projet.
2.2 Consulter les rapports 6

des tests générés.
3 Je dois m’authentifier. 3.1 Entrer un login. 7

passe.
63
Chapitre 6. Sprint 3 : Profil Equipe software 6.3. Conception
Pour illustrer les différentes manières dont l’équipe software peut interagir avec notre
système, les fonctionnalités mentionnées dans le Backlog Sprint 3 sont bien définies dans
un diagramme de cas d’utilisation de la figure 6.1.
Figure 6.1 – Diagramme de cas d’utilisation “Equipe Software”
La figure 6.1 montre qu’un membre de l’équipe software peut être authentifié en entrant
son login et son mot de passe pour accéder à notre application et commencer son travail.
Premièrement, il doit sélectionner un projet parmis ceux qu’il lui sont attribués, pour
pouvoir consulter les résultats de processus de test établis par l’équipe qualité. Puis,
il peut consulter le ou les scénarios des tests écrits en scripts BDD pour savoir quelle
fonctionnalité ou quel élément du projet est testé et il peut aussi consulter les rapports
de tests générés pour connaître les anomalies du projet.
6.3 Conception
qui décrivent comment et dans quel ordre notre acteur : l’équipe software, et les autres ob-
jets fonctionnent ensemble, et le diagramme de classe qui représente les différents éléments
composants de notre système et leurs relations dans ce dernier Sprint.

Nous présenterons dans ce qui suit les diagrammes de séquence détaillés des troix
principales User Stories du dernier Sprint.
Diagramme de séquence : Sélectionner un projet

Une fois authentifié (voir Figure : diagramme de séquence "Authentification" de réfé-
rence 4.2), un membre de l’équipe software se trouve dans son espace de travail, là où il
passe par plusieurs étapes pour atteindre son objectif.
64
La première étape consiste à sélectionner un projet parmis ceux qu’il lui sont attribués
pour pouvoir consulter ses résultats de processus de test. Cette tâche provoque que le
contrôleur charge aussi tous les packages-test relatifs à ce projet sélectionné. La figure 6.2
illustre la démarche de cette étape.
Figure 6.2 – Diagramme de séquence “Sélectionner un projet”
Diagramme de séquence : Consulter les tests en BDD

Le scénario de consultation des tests en BDD consiste qu’un membre de l’équipe soft-
ware et depuis son espace, peut sélectionner le test en script BDD à consulter.
La figure 6.3 illustre le diagramme de séquence de consultation des tests en scripts BDD.
65
Figure 6.3 – Diagramme de séquence “Consulter le test en script BDD”
Diagramme de séquence : Consulter les rapports

Ce scénario présente la procédure de consultation des rapports de tests. L’équipe soft-
ware clique sur "terminer" depuis son espace pour passer à une nouvelle interface celle du
rapport.
La figure 6.4 illustre le diagramme de séquence de ce scénario.
66
Figure 6.4 – Diagramme de séquence “Consulter les rapports des tests exécutés”

La figure 6.5 montre le diagramme des différentes classes de ce Sprint. L’interaction
entre ces dernières et l’équipe software se présente dans les méthodes : consulter les test en
script BDD dans la classe “BDD”, consulter les rapports de tests dans la classe “package-
test” et encore dans sélectionner un projet parmis ceux qu’il lui sont attribués pour pouvoir
consulter tout le travail réalisé de la part de l’équipe qualité.
67
Chapitre 6. Sprint 3 : Profil Equipe software 6.4. Réalisation
Figure 6.5 – Diagramme de classe "Equipe Software"
6.4 Réalisation
Dans cette dernière partie, nous présenterons les différents modules réalisés relatifs au
dernier sprint.
Ainsi que l’équipe qualité, un membre de l’équipe software passe par différentes étapes
afin de réaliser son travail. Par conséquent, nous avons choisi de répartir ses troix fonc-
tionnalités principales en 4 étapes. Ces dernières seront bien explicites dans les prochaines
sections.
6.4.1 Espace Equipe Software

Suite à une authentification réussie, le membre de l’équipe software se trouve dans son
espace. La figure 6.6 présente l’interface de cet acteur, là où il peut réaliser ses besoins de
consultations des tests en scripts BDD et les rapports générés.
La première étape consiste à sélectionner l’un des projets qui lui sont attribués depuis la
liste.
68
Figure 6.6 – Interface "Etape 1 - Choix du projet"
6.4.2 Consulter les scripts BDD des tests développés

Un membre de l’équipe software peut visualiser les scripts en BDD des tests réalisés
par les testeurs, pour concevoir encore le scénario de test étape par étape, les éléments et
les fonctionnalités mises en question .
Le script en BDD est en langage bien simple et facile à comprendre même par un non
connaisseur.
Au cours de la deuxième étape, la figure 6.7 présente comment un membre peut sélec-
tionner un package de test selon son nom significatif depuis une liste. Puis comment il
sélectionne l’un des scénarios attribués à ce package.
Figure 6.7 – Interface "Etape 2 - Sélection du package-test et du scénario"
Passons à la troisième étape, et comme prévu précédemment, le membre de l’équipe

software se trouve dans l’interface d’affichage de script BDD relatif à le scénario sélec-
tionné.
La figure 6.8 illustre cette phase.
69
Figure 6.8 – Interface "Etape 3 - Affichage du script en BDD du scénario"
6.4.3 Consulter les rapports

La troisième fonctionnalité de cet acteur est de visualiser les rapports générés après
l’exécution du processus de test automatique réalisée par le testeur (l’équipe qualité).
Cette étape aide vraiment ce dernier à concevoir les anomalies commises dans les étapes
de développement des composants et des fonctionnalités du projet web.
La figure 6.9 montre comment cet acteur passe à la quatrième et la dernière étape. Pour
terminer son travail, le membre de l’équipe software clique sur le bouton "Terminer" pour
aller vers une une nouvelle vue là où il se trouve devant une sélection du rapport à
visualiser.
Figure 6.9 – Interface "Etape 4 - Fin de la consultation des résultats "
Le membre de l’équipe qualité sélectionne un parmis les rapports pour le visualiser,

comme l’indique la figure 6.10.
70
Chapitre 6. Sprint 3 : Profil Equipe software 6.5. Conclusion
Figure 6.10 – Interface "Sélectionner rapport"
6.4.4 Rapport
Dans une dernière figure (la figure 6.11), nous présenterons la vue du rapport comme
prémédité.
Cette prise nous suggère les résultats obtenus après l’exécution du processus de test au-
tomatique d’une manière simple, explicite et claire.
Figure 6.11 – Interface "Rapport des résultats de test automatique"
6.5 Conclusion
Dans ce dernier chapitre de notre rapport, nous avons présenté les différentes étapes
du dernier Sprint, à savoir l’élaboration du Sprint Backlog, la conception détaillée et la
réalisation de ses différents modules, ensuite la conception détaillée et puis la réalisation.
71
Conclusion Générale
Le début de cette nouvelle décennie sera, surement, marqué par l’automatisation des
tests pour les applications web. Les enjeux liés à la fiabilité et à la qualité des livrables sont
devenus si importants que l’automatisation est incontournable. Mais beaucoup d’équipes
de tests et d’entreprises n’en sont pas encore là et la route qui les sépare de l’automatisa-
tion est encore longue.
Afin d’assurer aux clients la bonne qualité de son livrable, notre projet de fin d’étude,
qui a été réalisé au sein de l’entreprise TriTux, consiste à concevoir et développer une
plateforme web d’automatisation des tests pour les applications web.
Pour réaliser cet objectif, nous avons commencé par une recherche approfondie sur l’auto-
matisation des tests et une présentation des différents choix technologiques adoptés. Puis,
nous nous sommes focalisés sur l’extraction des différents besoins et fonctionnalités de
l’application développée. Enfin, nous avons atteint la phase de conception et réalisation
de notre projet via les différents sprints réalisés.
Au cours de cette étape, nous avons passé par deux volets importants :
— La réalisation et le développement des scénarios de tests automatisés sur un exemple
d’application web existante dynamique en utilisant plusieurs technologies ten-
dances telles que Selenium, Cucumber et Junit. Cette approche permet de faire
gagner du temps et de la qualité dès les premières exécutions en s’assurant que les
fonctionnalités clés de l’application (et les autres) sont fonctionnelles.
— Le développement et la création d’une plateforme web, à l’aide des frameworks
Spring Boot et Angular, où nous pouvons intégrer et importer nos tests automati-
sés, visualiser les rapports générés et aussi travailler en collaboration avec d’autres
testeurs et encore l’équipe software qui s’intéresse à la réalisation de livrable. Cette
solution facilite le dialogue entre les deux équipes et surtout nous aide à gagner du
temps.
Cette plateforme aide l’entreprise à bien réviser les projets développés avant de les livrer
aux clients et augmente sa crédibilité dans le marché informatique et l’avantage majeur
de cette automatisation est le fait de pouvoir paralléliser les tests pour une maximisation
de couverture de risques.
Ce projet nous a procuré une grande opportunité pour bien appliquer nos connaissances
acquises pendant notre cursus à l’ISTIC et nous a permis d’aborder un nouveau domaine
métier pour confirmer nos potentiels dans le domaine de l’automatisation des tests.
Ce n’était pas seulement une chance pour appréhender et découvrir le milieu professionnel
mais aussi un défi pour réaliser un produit de qualité et de valeur ajoutée et d’apprendre
un ensemble de technologies très répandus dans le domaine de génie logiciel.
Pour conclure, nous espérons avoir accompli nos tâches initialement fixées et atteint nos
objectifs définis. Ce projet recèle plusieurs perspectives comme l’automatisation des tests
des applications mobile en utilisant Appium et desktop pour l’améliorer et le rendre plus
riche. Ce qui nous donne envie d’aller plus loin dans ce domaine.
72
Bibliographie
[a] Entreprise tritux, http ://www.tritux.com , 2020/02.

[b] Solution squash, https ://www.supinfo.com/articles/single/10104-squash-solution-
complete-test-logiciel , 2020/02.
[c] Présentation de la méthodologie agile, http ://www.blog.azendoo.com , 2020/02.
[d] Définition test automatisé, https ://testingdigital.com/fr/solutions-de-tests/test-
automatise , 2020/03.
[e] Définition test automatisé, https ://www.ocsigroup.fr/blog/quel’intérêt-des-tests-
automatisés , 2020/03.
[f] Définition test automatisé, https ://blog.testingdigital.com/lancer-lautomatisation-
de-vos-campagnes-de-tests-385 , 2020/03.
[g] Intérêts des tests automatisés, https ://www.ocsigroup.fr/blog/quel’intérêt-des-tests-
automatisés , 2020/03.
[h] Critères de l’automatisation, https ://itsocial.fr/enjeux-it/enjeux-
production/developpements/4-criteres-determiner-automatiser-tests/ , 2020/03.
[i] Automatisation des tests dans les entreprises, https ://bfmbusiness.bfmtv.com/01-
business-forum/l-automatisation-des-tests-une-priorite-pour-les-entreprises-
612044.html , 2020/03.
[j] Etude supnifo, https ://www.supinfo.com/articles/single/2585-tests-automatises ,
2020/03.
[k] Istqb certification, https ://www.gasq.org/fr/certification/istqb.html , 2020/03.
[l] Le projet et les outils selenium, https ://blog.clever-age.com/fr/2017/08/29/tests-
fonctionnels-automatises/ , 2020/05.
[m] Framework selenium, https ://www.selenium.dev/documentation/en/introduction/ ,
2020/03.
[n] Cucumber, https ://www.guru99.com/using-cucumber-selenium.html , 2020/03.
[p] Architecture mvc, https ://www.supinfo.com/articles/single/8729-architecture-mvc-
qu-est-ce-que-c-est, 2020/03.
[q] Spring boot, https ://www.tutorialspoint.com/springb oot/, 2020/03.
[r] Angular, https ://www.supinfo.com/articles/single/6124-introduction-angular, 2020/03.
[s] Backlog Produit, https ://www.nutcache.com/fr/blog/quest-ce-quun-backlog-scrum/,
2020/03.
[t] Sprint Backlog, https ://blog.myagilepartner.fr/index.php/tag/sprint-backlog/, 2020/03.
73

Pfe 1

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Pfe 1

Transféré par

Droits d'auteur :

Formats disponibles

République Tunisienne

Ministère de l’Enseignement Supérieur

Rapport de Projet de Fin d’Etudes

Plateforme d’automatisation des tests pour

Soutenu publiquement le 11 Juillet 2020 devant le jury composé de :

Année Universitaire : 2019-2020

Rapport de Projet de Fin d’Etudes

Plateforme d’automatisation des tests pour

Autorisation de dépôt du rapport de Projet de Fin d’Etudes :

Encadrant professionnel : Encadrant académique :

On tient à exprimer toute notre reconnaissance à notre encadreur Madame Lahbib

1 Cadre du projet et étude de l’existant 3

3 Spécification des besoins 23

3.3 Besoins non fonctionnels . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

4 Sprint 1 : Profil Administrateur 28

5 Sprint 2 : Profil Equipe qualité 44

6 Sprint 3 : Profil Equipe software 63

1.1 Entreprise TRITUX . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

3.1 Diagramme de cas d’utilisation général . . . . . . . . . . . . . . . . . . . . 25

4.1 Diagramme de cas d’utilisation “Administrateur” . . . . . . . . . . . . . . 30

5.1 Diagramme de cas d’utilisation “Equipe qualité” . . . . . . . . . . . . . . . 46

5.2 Diagramme de séquence “Visualiser projet” . . . . . . . . . . . . . . . . . . 47

6.1 Diagramme de cas d’utilisation “Equipe Software” . . . . . . . . . . . . . . 64

2.1 Tableau comparatif d’outils d’automatisation de test . . . . . . . . . . . . 14

3.1 Identification des acteurs . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

4.1 Sprint Backlog 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

5.1 Sprint 2 Backlog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

6.1 Sprint 2 Backlog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63

Depuis la naissance de l’Internet, bien de fonctionnalités à la part la navigation, ont

Le quatrième, cinquième et sixième chapitre seront dédiés à la conception et la réalisation

Cadre du projet et étude de

1.2 Présentation de l’organisme d’accueil

— Recruter et conserver une main-d’œuvre hautement qualifiée, motivée, productive

Figure 1.1 – Entreprise TRITUX

1.3 Etude de l’existant

1.3.1 Solution actuelle adoptée par l’entreprise

1.3.2 Critiques de l’existant

1.3.3 Objectifs du projet

1.3.4 Travail à réaliser

9. Intégrer les tests déjà développés dans cette plateforme.

1.4 Méthodologie adoptée

2.2 Automatisation des tests

2.2.1 Test automatisé

2.2.2 Intérêt des tests automatisés

2.2.3 Critères de l’automatisation

La fréquence des tests

La couverture des tests

Les scénarios à déployer

Le nombre de profils à tester

2.2.4 Automatisation des tests dans les entreprises

2.2.5 Exemple d’utilisation de l’automatisation

2.2.6 Certification ISTQB

Figure 2.2 – ISTQB

2.3 Choix techniques pour l’automatisation des tests

Table 2.1 – Tableau comparatif d’outils d’automatisation de test

Figure 2.3 – Selenium

un test. Cela va du clic, à la gestion des variables, à la vérification des attributs

Figure 2.4 – Le projet et les outils Selenium

Selenium contrôle les navigateurs Web

Une interface pour les gouverner tous

2.3.2 Choix du langage de programmation

Figure 2.5 – Langage JAVA

Feature : Login Action