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 de tests

Par
Gdara Hazem
Bayoudh Emna

Réalisé au sein de Tritux

Soutenu publiquement le ? mai 2020 devant le jury composé de :

Président : Prénom NOM, University Relations Leader, IBM
Rapporteur : Prénom NOM, Enseignant, ISTIC
Examinateur : Prénom NOM, Enseignant, ISTIC
Encadrant professionnel : Prénom NOM, Ingénieur, VERMEG
Encadrant académique : Prénom NOM, Enseignant, 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

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 :

Le : Le :

Signature : Signature :

2
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 questions durant nos études, nos recherches et notre stage. . . « Merci ». On remer-
cie également notre encadreur Madame Trabelsi Zayneb, pour son aimable encadrement
et toutes ses consignes et recommandations. . . « Merci ». Nos sincères remerciements
s’adressent à Dieu, nos parents et nos amis pour leur encouragement, 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 2

1.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.2 Présentation de l’organisme d’accueil . . . . . . . . . . . . . . . . . . . . . 2
1.3 Etude de l’existant . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.3.1 Solution actuelle adoptée par l’entreprise . . . . . . . . . . . . . . . 3
1.3.2 Critiques de l’existant . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.3.3 Objectifs du projet . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.3.4 Travail à réaliser . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.4 Méthodologie adoptée . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.5 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

2 Etat de l’art 7
2.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.2 Automatisation des tests . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.2.1 Test automatisé . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.2.2 Intérêt des tests automatisés . . . . . . . . . . . . . . . . . . . . . . 8
2.2.3 Les critères de l’automatisation . . . . . . . . . . . . . . . . . . . . 8
2.2.4 L’automatisation des tests dans les entreprises . . . . . . . . . . . . 9
2.2.5 Exemple d’utilisation de l’automatisation . . . . . . . . . . . . . . . 10
2.2.6 La certification ISTQB . . . . . . . . . . . . . . . . . . . . . . . . 11
2.3 Choix techniques pour l’automatisation des tests . . . . . . . . . . . . . . . 11
2.3.1 Selenium . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.3.2 Choix du langage de programmation . . . . . . . . . . . . . . . . . 14
2.3.3 Framework de génération de test . . . . . . . . . . . . . . . . . . . 15
2.4 Architecture de l’application . . . . . . . . . . . . . . . . . . . . . . . . . 16
2.5 Choix techniques pour l’application . . . . . . . . . . . . . . . . . . . . . . 17
2.5.1 La partie back-end : Spring Boot . . . . . . . . . . . . . . . . . . . 17
2.5.2 La partie front-end : Angular7 . . . . . . . . . . . . . . . . . . . . 18
2.6 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

3 Spécification des besoins 20

3.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
3.2 Besoins fonctionnels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

iii
Table des matières Table des matières

3.3 Besoins non fonctionnels . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

3.4 Identification et structuration des cas d’utilisation . . . . . . . . . . . . . 21
3.4.1 Identification des acteurs . . . . . . . . . . . . . . . . . . . . . . . . 21
3.4.2 Diagramme de cas d’utilisation globale . . . . . . . . . . . . . . . . 22
3.5 Le Backlog Produit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
3.6 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

4 Sprint 1 : Profil Administrateur 25

4.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
4.2 Sprint Backlog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
4.3 Conception . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
4.3.1 Diagrammes de séquences . . . . . . . . . . . . . . . . . . . . . . . 27
4.3.2 Diagramme de classe . . . . . . . . . . . . . . . . . . . . . . . . . . 32
4.4 Réalisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
4.4.1 Authentification et Espace Admin . . . . . . . . . . . . . . . . . . . 33
4.4.2 Gestion des utilisateurs . . . . . . . . . . . . . . . . . . . . . . . . . 34
4.4.3 Gestion des projets . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
4.5 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

5 Sprint 2 : Profil Equipe qualité 40

5.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
5.2 Sprint Backlog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
5.3 Conception . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
5.3.1 Diagrammes de séquences . . . . . . . . . . . . . . . . . . . . . . . 42
5.3.2 Diagramme de classe . . . . . . . . . . . . . . . . . . . . . . . . . . 47
5.4 Réalisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
5.4.1 Espace Equipe Qualité . . . . . . . . . . . . . . . . . . . . . . . . . 48
5.4.2 Visualiser le projet à tester . . . . . . . . . . . . . . . . . . . . . . . 49
5.4.3 Développement des tests et gestion des packages-tests . . . . . . . . 50
5.4.4 Préparation de l’environnement de test et lancement de l’exécution 52
5.4.5 Consultation des Dashboards . . . . . . . . . . . . . . . . . . . . . 54
5.5 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55

6 Sprint 3 : Profil Equipe software 56

6.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
6.2 Sprint Backlog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
6.3 Conception . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
6.3.1 Diagrammes de séquences . . . . . . . . . . . . . . . . . . . . . . . 57
6.3.2 Diagramme de classe . . . . . . . . . . . . . . . . . . . . . . . . . . 59
6.4 Réalisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
6.4.1 Espace Equipe Software . . . . . . . . . . . . . . . . . . . . . . . . 60
6.4.2 Consulter les BDDs des tests développés . . . . . . . . . . . . . . . 61
6.4.3 Consulter les Dashboards . . . . . . . . . . . . . . . . . . . . . . . . 61
6.5 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62

Conclusion Générale 63

Bibliographie 64

iv
Table des matières Table des matières

Annexe 1, Les candidats classés par ordre alphabétique 65

v
Table des figures

1.1 Solution Squatsh . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

2.1 Les domaines de projets dans le marché . . . . . . . . . . . . . . . . . . . . 10

2.2 ISTQB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.3 Selenium . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.4 Selenium Webdriver . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.5 Langage JAVA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.6 Cucumber . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.7 TestNG . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
2.8 Architecture MVC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
2.9 Spring Boot . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
2.10 Angular . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

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

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

4.2 Diagramme de séquence “Authentification” . . . . . . . . . . . . . . . . . . 28
4.3 Diagramme de séquence “ Créer un utilisateur” . . . . . . . . . . . . . . . 29
4.4 Diagramme de séquence “ Modifier un utilisateur” . . . . . . . . . . . . . . 30
4.5 Diagramme de séquence “ Supprimer un utilisateur” . . . . . . . . . . . . . 31
4.6 Diagramme de séquence “ Affectation d’un projet à un rôle” . . . . . . . . 32
4.7 Diagramme de classe "Administrateur" . . . . . . . . . . . . . . . . . . . . 33
4.8 Interface "Authentification" . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
4.9 Interface "Fausse connexion" . . . . . . . . . . . . . . . . . . . . . . . . . . 34
4.10 Espace "Administrateur" . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
4.11 Interface "Création utilisateur" . . . . . . . . . . . . . . . . . . . . . . . . . 35
4.12 Interface "Saisie de données utilisateur" . . . . . . . . . . . . . . . . . . . . 35
4.13 Interface "Liste d’utilisateurs" . . . . . . . . . . . . . . . . . . . . . . . . . 36
4.14 Interface "Consultation et modification d’un utilisateur" . . . . . . . . . . . 36
4.15 Interface "Nouveau utilisateur" . . . . . . . . . . . . . . . . . . . . . . . . . 37
4.16 Interface "Suppression d’un utilisateur" . . . . . . . . . . . . . . . . . . . . 37
4.17 Interface "Gestion de projets" . . . . . . . . . . . . . . . . . . . . . . . . . 38
4.18 Interface "Ajout d’un projet" . . . . . . . . . . . . . . . . . . . . . . . . . . 38
4.19 Interface "Suppression d’un projet" . . . . . . . . . . . . . . . . . . . . . . 39
4.20 Interface "Affectation d’un projet à un rôle" . . . . . . . . . . . . . . . . . 39

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

5.2 Diagramme de séquence “Visualiser projet” . . . . . . . . . . . . . . . . . . 43
5.3 Diagramme de séquence “ Écrire le BDD d’un test et le développer en Java” 44

vi
Table des figures Table des figures

5.4 Diagramme de séquence “Préparer l’environnement de test” . . . . . . . . 45

5.5 Diagramme de séquence “Exécution des packages des tests” . . . . . . . . . 46
5.6 Diagramme de séquence “Consulter les rapports” . . . . . . . . . . . . . . 47
5.7 Diagramme de classe "Equipe Qualité" . . . . . . . . . . . . . . . . . . . . 48
5.8 Interface "Espace Equipe Qualité" . . . . . . . . . . . . . . . . . . . . . . . 49
5.9 Interface "Step1" . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
5.10 Interface "Sélectionner un projet" . . . . . . . . . . . . . . . . . . . . . . . 50
5.11 Interface "Page d’accueil du projet" . . . . . . . . . . . . . . . . . . . . . . 50
5.12 Interface "Step2" . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
5.13 Interface "Tests en BDD" . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
5.14 Interface "Code test" . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
5.15 Interface "Code test" . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
5.16 Interface "Step3" . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
5.17 Interface "Sélection des packages de tests" . . . . . . . . . . . . . . . . . . 53
5.18 Interface "Exécution des packages de tests" . . . . . . . . . . . . . . . . . . 54
5.19 Interface "Step 4" . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
5.20 Interface "Dashboards" . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55

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

6.2 Diagramme de séquence “Consulter le test en BDD” . . . . . . . . . . . . . 58
6.3 Diagramme de séquence “Consulter les rapport” . . . . . . . . . . . . . . . 59
6.4 Diagramme de classe "Equipe Software" . . . . . . . . . . . . . . . . . . . . 60
6.5 Interface "Step1 Equipe Software" . . . . . . . . . . . . . . . . . . . . . . . 60
6.6 Interface "Step2 Equipe Software" . . . . . . . . . . . . . . . . . . . . . . . 61
6.7 Interface "Step3 Equipe Software" . . . . . . . . . . . . . . . . . . . . . . . 61
6.8 Interface "Step4 Equipe Software" . . . . . . . . . . . . . . . . . . . . . . . 62

vii
Liste des tableaux

Tableau comparatif d’outil d’automatisation de test . . . . . . . . . . . . . . . . 12

Tableau d’identification des acteurs . . . . . . . . . . . . . . . . . . . . . . . . . 21

Tableau Backlog Produit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

Tableau Sprint 1 Backlog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

Tableau Sprint 2 Backlog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

Tableau Sprint 2 Backlog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56

viii
Introduction Générale

Le Projet de Fin d’études est obligatoire pour tous les étudiants de l’ISTIC (Institut
Supérieur des Technologies de l’Informatique et de la Communication). Il a pour objectif
premier de nous immerger dans le monde professionnel pour une durée plus importante
que les stages précédents. Le second est de mener une mission concrète venant d’un be-
soin exprimé par l’entreprise accueillante. Notre projet permet d’acquérir une formation
professionnelle demandant de la rigueur, de la méthode et de l’organisation.
Depuis l’apparition de l’Internet, bien de fonctionnalités hormis la navigation ont été of-
fertes. Parmi elles, se trouve la possibilité d’aider l‘utilisateur en satisfaisant au mieux sa
requête grâce à une plateforme de test automatisé. De ce fait, toute entité professionnelle
telle que les grandes entreprises, cherche à faciliter divers tâches de tests dans le but d’une
contribution à une meilleure rentabilité et afin de gagner de temps et de ressources.
C’est dans ce cadre que se situe notre travail qui consiste à faire la conception, déve-
loppement 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», qui souffre pendant des
périodes des problèmes liés à la lenteur et au retard au niveau de tester ces produits.
Dans ce rapport, nous allons présenter les différentes étapes que nous allons suivre pour
réaliser ce projet. Il s’appuis sur six chapitres. Le premier chapitre sert à présenter l’orga-
nisme d’accueil, exposer une étude de l’existant pour bien comprendre le système actuel
et poser le cadre de la problématique et souligner notre méthodologie adopté. 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 pla-
teforme. Le troisième chapitre détaillera la spécifications 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énarios via le diagramme de cas d’utilisation. 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 so-
lution. Ils 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éalisations via quelques interfaces. 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.

1
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 utilisée dans notre projet.

1.2 Présentation de l’organisme d’accueil

TriTUX est une société internationale spécialisée dans l’ingénierie informatique, le
conseil en informatique et l’externalisation. Avec plus de 13 ans d’expé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 innovation et en agilité commerciale.
Ils poursuivent l’environnement commercial et la rentabilité de leurs clients en proposant
des solutions adaptées et personnalisées, avec un ensemble complet de services, de la
conception à la mise en œuvre. Ils sont un partenaire stratégique dans :
— IoT.
— VAS.
— Roaming.
— IT Solutions.
Leurs secteurs d’activité :
— Télécommunication.
— Bancaire.
— Industrielle.
— Secteur public, etc.
Leurs buts :
— Maintenir les normes éthiques les plus élevées.
— Assurer la satisfaction du client en fournissant des services et une valeur de qualité.
— Recruter et conserver une main-d’œuvre hautement qualifiée, motivée et productive

2
Chapitre 1. Cadre du projet et étude de l’existant 1.3. Etude de l’existant

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 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, Tritux 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 : Améliore l’efficacité et l’efficience de vos services informatiques. Au-
jourd’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. Il acquiert une réputation enviable de fournir le soutien
nécessaire pour améliorer et maintenir la qualité des produits.

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 la solution proposée.

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”. Parmis ses services, on trouve essentiellement le développement des applications

3
Chapitre 1. Cadre du projet et étude de l’existant 1.3. Etude de l’existant

web pour ces clients. Le cycle de vie d’un projet passe par plusieurs tests unitaires, fonc-
tionnels, de non-régression, de performance, etc. D’où ce processus est très important et
présente une étape incontournable de tout développement informatique dont l’objectif est
de vérifier que le livrable répond bien aux besoins exprimés par l’utilisateur. Bien que son
utilité soit essentielle, la phase de test se trouve, hélas, souvent prise en otage suite aux
retards accumulés par le projet et sert de variable d’ajustement pour tenir les délais. En
pratique, il s’agira donc non pas d’établir que le système fonctionne correctement dans
tous les cas, mais plutôt de détecter que tel ou tel élément ne fonctionne pas comme prévu
sous certaines conditions.
TriTUX a opté pour le travail avec des tests manuels, dont leurs scénarios sont déroulés
par un être humain, pour accomplir ce processus.Pour cette tâche, les testeurs utilisent la
solution SQUASH suite logicielle open source produite par l’éditeur français Hénix. Elle
propose un panel complet d’outils pour la mise en place d’un processus de qualification
sur l’ensemble d’un système, dès la collecte des spécifications, à la rédaction des scripts de
test, à leurs exécutions jusqu’à la génération des rapports. La mise en place de cette so-
lution permet d’assurer un bon fonctionnement des applications, et apporte de nombreux
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 de référentiel 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.
Dans notre cas, nous trouvons que l’équipe Tritux travaille avec la première solution.
Avec cette approche informelle, le testeur ne suit aucune procédure de test rigoureuse,
mais explore plutôt l’interface utilisateur de l’application en utilisant autant de ses fonc-
tionnalités que possible, en utilisant les informations obtenues lors des tests précédents
pour dériver intuitivement des tests supplémentaires. Le succès des tests manuels repose
en grande partie sur l’expertise du domaine du testeur, car un manque de connaissances
entraînera une incomplétude des tests. L’un des principaux avantages d’une approche
informelle est d’avoir un aperçu intuitif de ce que l’on ressent en utilisant l’application.

Figure 1.1 – Solution Squatsh

4
Chapitre 1. Cadre du projet et étude de l’existant 1.3. Etude de l’existant

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 les étapes du test. Ils sont très lents ayant un temps d’exécution
élevé. Aussi, ils ne sont pas aussi précis, ils ne peuvents 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 utilisateurs et l’entreprise. Leur correction peut s’accompagner d’un coût pour cette
dernière qui n’a pas été prévu initialement.

1.3.3 Objectifs du projet

Les systèmes d’information sont amenés à évoluer régulièrement de par la nécessité
d’intégrer de nouvelles applications, de les mettre à jour ou de mettre en œuvre les évo-
lutions à 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 des 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 se-
maines 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. . . ).
C’est dans ce cadre que s’inscrit ce projet de fin d’étude qui vise à automatiser une pile
de test pour créer une plateforme de tests automatisés “Tritux”. Nous remarquons qu’une
fois passé le cap de la conception des premiers scripts d’automatisation, les professionnels
du test ont tendance à adopter cette pratique pour de bon. Nous constatons en effet qu’ils
continuent à l’utiliser et à faire évoluer leurs scripts au fur et à mesure de l’avancement
de leur projet digital. Donc, nous désirons 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.
En réalisant cette tâche, l’entreprise ouvre ses portes pour la nouvelle tendance de l’au-
tomatisation des tests 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 est :
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.

5
Chapitre 1. Cadre du projet et étude de l’existant 1.4. Méthodologie adoptée

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.
9. Intégrer les tests déjà développés dans cette plateforme.
10. Exécuter les scripts développés à partir de cette plateforme.
11. Faire un reporting sur les différents cas de tests.
12. Générer des dashboards de statistiques.

1.4 Méthodologie adoptée

La méthodologie de gestion d’un projet nous guide tout au long du cycle de vie de ce
dernier. Cela commence par nous aider à planifier, initier et mettre en oeuvre le travail.
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
jusqu’à 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.[1]
En effet, au cours d’un sprint de 2 à 3 semaines, nous commençons notre travail. Nous
travaillons sur les use-cases dans le backlog. La transition agile a fait disparaître les
spécifications habituelles du cycle en V. Nous recevons généralement une première version
testable de l’application. Nous avons notre cahier de test 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 tests
est le “Zéro non-régression”. Cela n’implique pas qu’il ne faut pas faire de tests de non-
régression mais que la non régression devrait être totalement automatisée. 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
élaboré 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 à suivre.
Notre suivant chapitre présentera l’importance de l’automatisation des tests et explicitera
nos choix techniques pour l’automatisation des tests et notre architecture et nos choix
techniques pour la réalisation de notre plateforme.

6
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, en pré-
sentant ses intérêts, sa priorité pour les entreprise, quelques chiffres dans le marché et
en s’argument par la certification ISTQB . Ensuite, nous allons présenter nos choix tech-
niques pour l’automatisation des tests et l’architecture et nos choix techniques pour la
réalisation de notre plateforme web.

2.2 Automatisation des tests

Le test est une discipline vaste 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 ces erreurs. Son but principal est
de mettre le doigt sur un nombre maximum 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. Encore, nous allons présenter la valeur de l’automatisation des tests
dans les entreprises en s’appuyant sur des chiffres et la certification de ISTQB.

2.2.1 Test automatisé

Nous parlons de test automatisé lorsqu’aucune action manuelle n’est entreprise 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.[2]
D’où vient la notion d’automatiser les tests qui consiste à faire les effectuer par un robot,
appelé aussi automate de test. Par analogie avec l’industrie, un robot de test est pro-
grammé pour exécuter des tests préenregistrés.[3]
Donc, si nous voulons définir le test automatisé, nous pouvons dire qu’il est un processus

7
Chapitre 2. Etat de l’art 2.2. Automatisation des tests

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 et la comparaison des résultats estimés, la configuration
des conditions préalables du test, ainsi que d’autres fonctions de contrôle de test et de
rapport de test.[4]

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.
Ces deux exemples illustrent à quel point les tests sont critiques pour les entreprises. Pour-
tant, ils sont des fois négligés 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, donc 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é.
— Test Automatisé permet de tester avec une grande cohérence et 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,
planification,etc.).[5]

2.2.3 Les critères de l’automatisation

Selon des estimations, près de 80 pourcent des tests sont automatisables. Avant de
mettre en place une solution, il faut bien entourer le potentiel et les limites de l’auto-
matisation des tests, pour choisir les meilleurs cas d’usage. Selon CloudNetCare, les tests
représentent en moyenne 35 pourcent des coûts dans un projet de développement. Par
ailleurs, près de 30 pourcent du temps du projet est consacré au cahier de charge. Donc,
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. Nous pouvons identifier quatres critères clés
où l’automatisation des tests est pertinente afin d’obtenir le meilleur retour sur investis-
sement (ROI) :

8
Chapitre 2. Etat de l’art 2.2. Automatisation des tests

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.

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.[6]
Nous résumons la formule (ROI) : fréquence x nombre d’environnements x actions par
scénario x profils : nombre d’actions à reproduire.
Cela s’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 L’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. Pas étonnant vu leur importance pour assu-
rer la qualité d’une application. Et encore l’automatisation des tests concernent 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. La gestion des tests consiste à construire un référentiel
centralisé où les tests sont accompagnés par une grande documentation. Dans ces der-
nières années, la gestion de projet était en tête des préoccupations comme le présente,

9
Chapitre 2. Etat de l’art 2.2. Automatisation des tests

et l’automatisation des tests venait juste derrière avec 38 pourcent de réponses à égalité
avec la gestion des exigences.[7]

Figure 2.1 – Les domaines de projets dans le marché

2.2.5 Exemple d’utilisation de l’automatisation

Selon une étude préparée par Supinfo (ecole 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. Cette étude s’appuie sur la comparaison des erreurs obte-
nues 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 automatisé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 écrivant 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. 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énarii de tests plus évolués et plus réalistes. Les testeurs trouvent leur travail
moins mécanique tout en se sentent 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).[8]

10
Chapitre 2. Etat de l’art 2.3. Choix techniques pour l’automatisation des tests

2.2.6 La certification ISTQB

Nous ne pouvons pas parler des tests sans mentionner ISTQB, la comité international
de qualification des tests logiciels, 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 consi-
dé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.[9]

Figure 2.2 – ISTQB

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.
Le rythme de travail toujours croissant exige des outils d’automatisation qui sont déve-
loppés pour rendre nos routines faciles et efficaces. Donc, 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 volumineuses ou
en simulant des comportements de l’application. Ces derniers, qui s’interface avec les ou-
tils d’exécution, de gestion des défauts, des exigences et de configuration, enregistrent 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.

11
Chapitre 2. Etat de l’art 2.3. Choix techniques pour l’automatisation des tests

Donc, et pour bien choisir notre outil, nous avons préparé une étude comparative entre
trois outils que nous avons les trouvé très répondus 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, pour 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 utilise
que Java et Groovy et 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 des appareils mobiles comme Android et iOS via Appium
(test automation framework) pour Selenium. Katalon Studio aussi peut automatisé des
application web et mobile et pour 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ée de main, nous pourrions nous sentir déviés vers l’utili-
sation de Selenium pour accomplir notre travail.

Tableau comparatif d’outil 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 est un projet englobant un ensemble d’outils et de librairies rendant possible
et facile l’automatisation de navigateur web.

Selenium contrôle les navigateurs Web

Selenium est une multiplateforme, mais à la base, c’est un ensemble d’outils pour
l’automatisation du navigateur Web qui utilise les meilleures techniques disponibles pour
contrôler à distance les instances du navigateur et simuler l’interaction d’un utilisateur
avec le navigateur. 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

12
Chapitre 2. Etat de l’art 2.3. Choix techniques pour l’automatisation des tests

Figure 2.3 – Selenium

et cocher des cases et cliquer sur les liens dans les documents. Il fournit également de
nombreux autres contrôles tels que le mouvement de la souris, l’exécution arbitraire de
JavaScript et plus encore. Bien qu’utilisé principalement pour les tests frontaux des sites
Web, Selenium est à la base une bibliothèque d’agent utilisateur de navigateur. Les inter-
faces sont omniprésentes à leur application, qui encourage la composition avec d’autres
bibliothèques en fonction de l’objectif.

Une interface pour les gouverner tous

Un des principes directeurs du projet est de prendre en charge une interface commune
pour toutes les, principales, technologies de navigateur. Les navigateurs Web sont des
applications complexes et hautement conçues, effectuer leurs opérations de manière com-
plètement différente mais qui se ressemblent souvent en le faisant. Même si le texte 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. Le Selenium
résume ces différences, cacher 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.

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 fourni pour les langues les plus courantes, ces tests se dérouleront sans
relâche en parallèle, nous faire des rapports en cas d’erreur. C’est un objectif pour nous
aider, en fournissant aux testeurs 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.

L’utilisation de Selenium
Beaucoup des entreprises ont adopté Selenium pour leurs tests sur navigateur, rem-
plaç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 Se-
lenium de les suivre autant que possible. Être un projet open source, est l’un des points

13
Chapitre 2. Etat de l’art 2.3. Choix techniques pour l’automatisation des tests

forts de cet outil.[10]

Figure 2.4 – Selenium Webdriver

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 est le choix le plus sûr si nous démarrons un nouveau pro-
jet à 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.

Figure 2.5 – Langage JAVA

Encore un point fort est que nous pouvons également écrire des tests Selenium 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

14
Chapitre 2. Etat de l’art 2.3. Choix techniques pour l’automatisation des tests

test en 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 tes-
teurs 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 maintenance des
tests.
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épondue et le framework intégré dans le Webdriver Selenium que nous
pouvons utiliser si nous choisissons le BDD est Cucumber.

Cucumber
Cucumber est une approche de test qui prend en charge le développement basé sur le
comportement BDD. Il représente le comportement de l’application dans un simple texte
utilisant le langage Gherkin.
Cuncumbre 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 Cucumber facilite la lecture et la compré-
hension du flux d’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. N’importe qui dans l’organisation peut com-
prendre le comportement du logiciel. La syntaxe de Gherkin est dans un texte simple qui
est lisible et compréhensible.[11]

Figure 2.6 – Cucumber

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

15
Chapitre 2. Etat de l’art 2.4. Architecture de l’application

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 TestNG car c’est le framework
qui fonctionne avec ce choix. Il offre aussi plusieurs avantages importants, tels que :
— TestNG est similaire à JUnit, mais il est beaucoup plus puissant que JUnit, no-
tamment en termes de test de classes intégrées. Et mieux encore, TestNG hérite
de tous les avantages que JUnit a à offrir.
— TestNG élimine la plupart des limitations des anciens frameworks et nous donne
la possibilité d’écrire des tests plus flexibles et puissants. Certaines des fonction-
nalités de mise en évidence sont les suivantes : annotations faciles, regroupement,
séquencement et paramétrage.[12]

Figure 2.7 – TestNG

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) 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. Cette ar-
chitecture est le plus communément retrouvée au sein des applications web mais existe
également au niveau des applications lourdes, d’où vient notre choix.

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",

16
Chapitre 2. Etat de l’art 2.5. Choix techniques pour l’application

Figure 2.8 – Architecture MVC

il attend que l’utilisateur interagisse avec la vue pour en récupérer la requête. Donc, c’est
lui qui définit la logique d’affichage, et affichera la vue suivante à l’écran.

Les 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 [14].
Vus que notre démarche nous conduit dans le développement avec Java, et pour utili-
ser cette architecture 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.[13]

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 La partie back-end : Spring Boot

Le Micro Service est une architecture qui permet aux développeurs de développer et de
déployer des services indépendamment. Chaque service en cours d’exécution a son propre

17
Chapitre 2. Etat de l’art 2.5. Choix techniques pour l’application

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 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.
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 configurer les beans Java, les configurations XML
et les transactions 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.
— 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.
— Offrez un moyen plus simple de démarrer avec l’application.[14]

2.5.2 La partie front-end : Angular7

Angular 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.
Depuis 2009 jusqu’à aujourd’hui, Google a sorti 3 différentes versions d’Angular : Angu-
larJS (2009), Angular 2 (2016) et Angular 4 (2017). A partir de la version 2, le framework

18
Chapitre 2. Etat de l’art 2.6. Conclusion

Figure 2.9 – Spring Boot

a été complètement reformulé. AngularJS n’est donc pas compatible avec les versions ul-
térieures. En contrepartie, il est possible de migrer entre la version 2 et la version 4.
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’utilisa-
tion de modules, étant un langage typé. Il est important de souligner que l’utilisation du
TypeScript est optionnel, nous pouvons utiliser du JavaScript dans un fichier TypeScript.
Angular est basé sur une architecture de composants complètement indépendants les uns
des autres. Il analyse la vue html correspondant et détecte si il comporte des composants
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 imbriquer au-
tant de composants que nous le souhaite.
Un composant dans ce framework alimente la génération d’une partie de code html et
fournir des fonctionnalités à celle-ci. Donc, un composant est constitué d’une classe dans
laquelle on pourra définir la logique d’application pour ce composant avec des propriétés,
des méthodes, etc.[15]

Figure 2.10 – Angular

2.6 Conclusion
Dans ce chapitre, nous avons détaillé l’importance de l’automatisation des tests. Puis,
nous avons présenté les choix technologique choisis pour la réalisation de notre travail.
Dans le prochain chapitre, nous allons aborder le chapitre de 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.

19
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é.
— Vérifier la capacité de notre plateforme : Grâce aux tests automatisés développés,
nous pouvons vérifier la résilience de notre solution 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.
— Générer des dashboards : De plus la génération des rapports, nous pouvons générer
des dashboards qui nous donne une idée sur des statistiques de réussite ou d’é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.

20
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 en interactions avec notre plateforme sont :
— Equipe qualité : Testeur.
— Equipe Software : Les développeurs, les chefs de projet et les PO (Product Owner).
— Administrateur.

Description détaillée des acteurs

Tableau d’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 de tests, faire la configuration
enregistre les exigences du entre les scripts de tests et
produit, prépare les scéna- le script de produit, exécuter
rios de tests et il enregistre les tests qui lui sont attribués,
les anomalies et les défauts consulter les rapports et encore
du produit dans l’outil. ajouter d’autres tests.
Equipe software : Dé- C’est l’équipe responsable La consultation des tests et des
veloppeurs, Chefs de de développement de pro- rapports de tests pour avoir une
projet et PO duit à tester. 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 utilisateur et en plus
il est le responsable de la gestion
des projets en affectant à chaque
utilisateur un projet.

21
Chapitre 3. Spécification des besoins 3.5. Le 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
systè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 fonctionnalité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 par chaque acteur, le Testeur peut gérer l’exécution de test,
ajouter d’autres en visualisant le projet à tester et consulter les rapports de test générés.
L’équipe software peut seulement consulter les tests déjà exécutés et les rapports générés.
L’Administrateur gère tous les utilisateurs et les projets en les associant.

3.5 Le Backlog Produit

Le Backlog Produit comme illustré dans le tableau 3.1 centralise la liste des exigences
attendues (fonctionnalités, exigences non fonctionnelles, défauts à corriger). 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. L’unité de coût est le point. Le choix
d’une telle unité permet d’éviter la confusion entre délais et coût, souligne le caractère
estimatif (imprécis) et facilite la planification de libération et de sprint (une période

22
Chapitre 3. Spécification des besoins 3.5. Le Backlog Produit

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.

Tableau 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
Exécuter le pro-
Gestion de l’exé- Equipe qualité cessus de tester 2
cution de test pour le projet
automatique
Equipe qualité
Gestion des pa- Avoir la possi- 3
ckages de tests bilité d’ajouter,
consulter, modi-
fier ou suppri-
mer un cas de
test
Conception et Authentification Equipe software M’authentifier 1
réalisation de
profil “Equipe
software“

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

23
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 globale de
notre projet.
Le chapitre suivant va entamer notre premier sprint au sein du première libération.

24
Chapitre 4

Sprint 1 : Profil Administrateur

4.1 Introduction
Dans ce chapitre, nous commençons réellement à réaliser notre projet. En appliquant
la méthodologie Agile, notre premier Sprint se présente dans une conception et une réalisa-
tion du premier profil : Administrateur, en mettant en œuvre les principales fonctionnalités
de l’application.

4.2 Sprint Backlog

Le sprint backlog est une partie des user stories du backlog produit que l’équipe
s’engage à livrer d’ici 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. Ainsi, le travail le plus
important s’effectuera en premier. Le backlog du sprint 1 est détaillé dans le tableau 4.1
avec la difficulté estimée pour chaque tâche.

25
Chapitre 4. Sprint 1 : Profil Administrateur 4.2. Sprint Backlog

Tableau Sprint 1 Backlog

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.
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 Backlog Sprint 1 sont représentées dans
un diagramme de cas d’utilisation de 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 ou supprimant. 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.

26
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 de quelques 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.
Si les données saisies sont incorrectes, un message s’affiche pour refaire la saisie.
La figure de référence 4.2 illustre le diagramme de séquence d’authentification.

27
Chapitre 4. Sprint 1 : Profil Administrateur 4.3. Conception

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. L’admi-
nistrateur saisit le nom, le prénom, le login, le mot de passe et le rôle c’est à dire équipe
qualité ou équipe software ou un autre administrateur. 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.

28
Chapitre 4. Sprint 1 : Profil Administrateur 4.3. Conception

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 pour modifier un utilisateur manuellement. L’admi-
nistrateur saisit les nouvelles informations dont il souhaite modifier le login par exemple.
Une vérification est effectuée sur le contrôleur pour voir si le login n’est pas déjà utilisé.
Si ce n’est pas le cas, le login 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.

29
Chapitre 4. Sprint 1 : Profil Administrateur 4.3. Conception

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 utili-
sateur. L’administrateur 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 encore. Si
l’utilisateur existe, il est supprimé, sinon un message indiquant que l’utilisateur est déjà
supprimé est renvoyé.
La figure 4.5 représente le diagramme de séquence de suppression d’un utilisateur.

30
Chapitre 4. Sprint 1 : Profil Administrateur 4.3. Conception

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 : administrateur, équipe qualité et équipe software, il peut
sélectionner un projet pour l’affecter à un rôle voulus et termine par save ou cancel.
La figure 4.6 représente le diagramme de séquence d’affectation d’un utilisateur à un pro-
jet.

31
Chapitre 4. Sprint 1 : Profil Administrateur 4.3. Conception

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 plateforme.
— User : une classe formée par les coordonnées d’un utilisateur dont ces attributs
sont “login”, “mdp”, “nom”, et “prenom”.
— Role : cette classe est responsable d’identifier à chaque utilisateur un rôle : Admi-
nistrateur, Testeur ou Équipe software indiqué par l’attribut “nom”.
— Projet : la classe projet réunit les projet à tester. Ces attributs sont “nom” et “url”.
— Package Test : c’est la classe où nous pouvons trouver tous les scénarios et les
cas de test qui peuvent être utilisés par le testeur pour tester le projet ou ajouter
d’autres cas de tests ou bien par l’Equipe software pour consulter les tests et les
rapports. Ces attributs sont “bdd”, “nom”,”script” et “rapport”.
Cette figure montre aussi comment l’administrateur peut interagir avec la base de donnée.
Il gère la classe user en appliquant les méthodes : créer, modifier, consulter, supprimer et
l’ajout de rôle. Il gère aussi la classe projet en appliquant les mêmes méthodes. Tant que
pour la classe rôle, il peut sélectionner un rôle pour l’attribuer à un utilisateur.

32
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érentes interfaces liées au travail effectué.
Voici les captures d’écran des interfaces du premier Sprint.

4.4.1 Authentification et Espace Admin

La figure 4.8 montre l’interface de connexion où l’utilisateur doit saisir son nom d’uti-
lisateur et mot de passe pour avoir accès à l’application.

Figure 4.8 – Interface "Authentification"

33
Chapitre 4. Sprint 1 : Profil Administrateur 4.4. Réalisation

Si l’utilisateur entre le nom d’utilisateur ou le mot de passe incorrectement, un message

d’alerte s’affiche comme le montre la figure 4.9.

Figure 4.9 – Interface "Fausse connexion"

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 et la gestion des utilisateurs.
La figure 4.11 montre comment il peut créer un nouveau utilisateur.

34
Chapitre 4. Sprint 1 : Profil Administrateur 4.4. Réalisation

Figure 4.11 – Interface "Création utilisateur"

La figure 4.12 montre la saisie du nom, prénom, login et mot de passe. A partir de cette
interface, il peut aussi lui affecter un rôle et un projet pour le tester. Et il termine cette
tâche en cliquant sur save ou cancel.

Figure 4.12 – Interface "Saisie de données utilisateur"

Et après, nous pouvons trouver que l’utilisateur est bien ajouté dans la liste des utilisa-
teurs comme l’illustre la figure 4.13.

35
Chapitre 4. Sprint 1 : Profil Administrateur 4.4. Réalisation

Figure 4.13 – Interface "Liste d’utilisateurs"

En gérant les utilisateurs, l’administrateur peut évidemment consulter et modifier les

attributs d’un utilisateur.
La figure 4.14 illustre cette tâche. L’administrateur peut changer les ou l’un des champs
et enfin il clique sur save ou cancel.

Figure 4.14 – Interface "Consultation et modification d’un utilisateur"

Donc, nous pouvons egalement constater que les données de cet utilisateur ont changé
dans la liste comme dans la figure 4.15.

36
Chapitre 4. Sprint 1 : Profil Administrateur 4.4. Réalisation

Figure 4.15 – Interface "Nouveau utilisateur"

La suppression d’un utilisateur est aussi possible. Comme la liste des utilisateurs enregis-
trés est affichée, l’administrateur peut choisir le ou les utilisateurs qu’il veut supprimer et
il clique sur l’icône de la corbeille de côté. 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 à côté du projet, ajouter
un nouveau projet ou bien supprimer un ou plusieurs.

37
Chapitre 4. Sprint 1 : Profil Administrateur 4.4. Réalisation

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 lien. Puis, il la termine par un clique sur
save ou cancel.

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 save ou cancel comme l’indique la figure 4.19.

38
Chapitre 4. Sprint 1 : Profil Administrateur 4.5. Conclusion

Figure 4.19 – Interface "Suppression d’un projet"

La figure 4.20 indique aussi qu’à partir l’interface de gestion des projets l’administra-
teur peut affecter un projet à un rôle. Donc il sélectionne le nom de rôle et le nom de
projet et il termine par save ou cancel.

Figure 4.20 – Interface "Affectation d’un projet à un rôle"

4.5 Conclusion
Dans ce chapitre, nous avons détaillé la réalisation du premier Sprint qui consiste à la
création du premier acteur l’administrateur.
Dans notre suivant chapitre, nous allons établir le même travail pour le deuxième acteur :
Equipe qualité.

39
Chapitre 5

Sprint 2 : Profil Equipe qualité

5.1 Introduction
Dans ce chapitre et toujours en appliquant la méthodologie Agile, notre deuxième
Sprint se présente dans une conception et une réalisation du deuxième profil : Equipe
qualité : Testeur, en mettant en œuvre ses principales fonctionnalités de l’application.

5.2 Sprint Backlog

Le backlog du sprint 2 est détaillé dans le tableau 5.1 avec la difficulté estimée pour
chaque tâche.

40
Chapitre 5. Sprint 2 : Profil Equipe qualité 5.2. Sprint Backlog

Tableau Sprint 2 Backlog

Id User Story Id Tâche Estimation
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 BDD et les dévelop-
de processus de test per en Java avec Sele-
automatique. nium.

2.2 Préparer l’environne-

ment de test sur la
plateforme d’automa-
tisation.

2.3 Lancer l’exécution des 5

tests sur la plate-
forme.

2.4 Consulter les rapports 5

des tests.
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.

4.2 Entrer un mot de 7

passe.

Pour mieux illustrer les différentes manières dont les testeurs peuvent interagir avec le
système, les fonctionnalités mentionnées dans le Backlog Sprint 2 sont illustrées dans un
diagramme de cas d’utilisation de la figure 5.1.

41
Chapitre 5. Sprint 2 : Profil Equipe qualité 5.3. Conception

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 les différents modules du projet à tes-
ter. Ensuite, il gère l’exécution de processus de test automatique. Donc, il commence par
écrire les scénarios des tests en BDD et il les développe en Java avec Selenium dans l’IDE
(dans notre cas c’est l’Intellig). Dès qu’il finit avec cette étape, il prépare l’environnement
de test sur la plateforme d’automatisation, il choisit et il lance l’exécution des tests sur
notre plateforme pour terminer avec la consultation des rapports générés sous forme des
dashboards.
Au cours de préparation d’un projet, ce dernier peut passer par plusieurs étapes et en-
core plusieurs éléments peuvent être gérer, 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 supprimant.

5.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 Sprint.

5.3.1 Diagrammes de séquences

Nous présenterons dans ce qui suit les diagrammes de séquence détaillés de quelques
User Stories du deuxième Sprint.

42
Chapitre 5. Sprint 2 : Profil Equipe qualité 5.3. Conception

Diagramme de séquence : Authentification

Ce scénario présente, comme l’indique la figure de référence 4.2, la procédure d’authen-
tification. Le testeur saisit les informations requises et valide le formulaire. Une vérification
est effectuée au niveau du contrôleur. Si les données saisies sont incorrectes, un message
s’affiche pour l’utilisateur et refait la saisie.

Diagramme de séquence : Visualiser le projet à tester

Pour tester une application web, le testeur entame la première étape, celle de visualiser
le projet et de se familiariser avec ses différents modules, éléments et fonctionnalités.
Après une authentification réussie, un testeur se trouve dans son espace. La première
phase lui consiste de 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écifications (les besoins de l’équipe software).
La figure 5.3 montre cette étape.

Figure 5.2 – Diagramme de séquence “Visualiser projet”

Diagramme de séquence : Écrire le BDD d’un test et le développer en Java

La figure 5.4 montre comment un testeur peut écrire le BDD d’un test et le développer
en Java. Cela implique qu’à partir de l’interface des steps, l’utilisateur choisit d’ouvrir son
IDE. Sur la nouvelle interface, il commence par créer un nouveau feature (package pour
les tests en BDD) là oui 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

43
Chapitre 5. Sprint 2 : Profil Equipe qualité 5.3. Conception

step (package pour les scripts de tests) et traduire chaque ligne de BDD en Java à l’aide
des bibliothèques Java, Selenium et Cucumber. Quand il finit son travail, le testeur ferme
son IDE et le nouveau cas de test s’ajoute dans l’interface de l’application.

Figure 5.3 – Diagramme de séquence “ Écrire le BDD d’un test et le développer en

Java”

Diagramme de séquence : Préparer l’environnement de test sur la plateforme

La deuxième étape dans notre processus consiste à préparer l’environnement de test.
Donc le testeur doit sélectionner, d’après l’interface des steps, les packages de test déjà
développés qu’il veut exécuter. La figure 5.5 montre comment tous les packages sont char-
gés depuis la base de données sur l’interface dans un premier lieu, et comment le testeur
peut sélectionner parmis eux ceux qu’il veut lancer leurs exécutions dans l’étape suivante.

44
Chapitre 5. Sprint 2 : Profil Equipe qualité 5.3. Conception

Figure 5.4 – Diagramme de séquence “Préparer l’environnement de test”

Diagramme de séquence : Lancer l’exécution des tests sur la plateforme

Après la préparation de l’environnement de test et la sélection des packages de tests
qu’il veut réaliser, le testeur clique sur exécuter. Cette étape consiste à effectuer l’exécu-
tion de chaque package de test à part. Donc, le contrôleur de l’IDE s’occupe de mettre les
résultats sous forme de rapports dans la base de données de chaque test exécuté comme
l’illustre la figure 5.6, et ne sort de cette boucle que lorsque tous les packages de test
sélectionnés sont interprétés.

45
Chapitre 5. Sprint 2 : Profil Equipe qualité 5.3. Conception

Figure 5.5 – Diagramme de séquence “Exécution des packages des tests”

Diagramme de séquence : Consulter les rapports des tests

Une fois l’exécution des packages de test est terminée, les résultats de ces tests sont
stockés sous forme des rapports de test dans l’entité package-test de la base de données.
Pour consulter ces rapports, le testeur les sélectionne comme l’indique la figure 5.7. La
présentation de ces rapports est sous forme d’un dashboard pour être plus claire et signi-
ficative.

46
Chapitre 5. Sprint 2 : Profil Equipe qualité 5.3. Conception

Figure 5.6 – Diagramme de séquence “Consulter les rapports”

5.3.2 Diagramme de classe

La figure 5. illustre l’interaction entre notre base de donnée et le testeur. Ce diagramme
montre qu’un membre de l’équipe qualité peut gérer l’entité de package-test. Il peut créer,
modifier, consulter ou supprimer un package de test. Cette gestion implique qu’il peut
gérer chaque attribut de cette table c’est à dire le BDD d’un cas de test, le script ou le
rapport. Sans oublier qu’il peut aussi sélectionner un projet qui lui est attribué pour le
visualiser à travers l’url.

47
Chapitre 5. Sprint 2 : Profil Equipe qualité 5.4. Réalisation

Figure 5.7 – Diagramme de classe "Equipe Qualité"

5.4 Réalisation
Dans cette partie, nous présenterons les différentes interfaces liées au travail effectué.
Voici les captures d’écran des interfaces du deuxième Sprint.

5.4.1 Espace Equipe Qualité

Apès une authentification correcte, le testeur se trouve dans son espace comme l’in-
dique la figure 5.8.

48
Chapitre 5. Sprint 2 : Profil Equipe qualité 5.4. Réalisation

Figure 5.8 – 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 tra-
vailler sur, comme l’illustre la figure 5.9, pour se familiariser avec l’interface qu’il doit
tester et ces différents composants.

Figure 5.9 – Interface "Step1"

Donc, l’interface dans la figure 5.10 présente comment il peut sélectionner l’un des projets
qui lui sont attribués afin de le voir dans le navigateur en passant par son url.

49
Chapitre 5. Sprint 2 : Profil Equipe qualité 5.4. Réalisation

Figure 5.10 – Interface "Sélectionner un projet"

Et 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 dans la figure 5.11.

Figure 5.11 – Interface "Page d’accueil du projet"

5.4.3 Développement des tests et gestion des packages-tests

La deuxième étape se manifeste dans la gestion des packages tests déjà existants en
les consultant, modifiant, supprimant ou ajoutant un nouveau cas de test. La figure 5.12
montre cette étape clairement.
La modification d’un package consiste à cliquer sur l’icône action2 qui permet d’ouvrir
l’IDE. La suppression se manipule dans la même interface. Et pour pour ajouter un nou-
veau cas de test, le testeur clique sur le bouton et ensuite il se dirige vers l’IDE aussi.

50
Chapitre 5. Sprint 2 : Profil Equipe qualité 5.4. Réalisation

Figure 5.12 – Interface "Step2"

En ouvrant l’IDE, dans notre cas c’est IntelliJ, le testeur commence par écrire les scéna-
rios des tests en BDD comme dans la figure 5.13.

Figure 5.13 – Interface "Tests en BDD"

Puis, il développe les scénarios de BDD en code java à l’aide de Selenium.

C’est la tâche de l’automatisation des tests, là où il fait l’appelle pour plusieurs biblio-
thèques comme cucumber.api.java et org.openqa.selenium, et chaque ligne de BDD se
transforme en un script bien précis.
Les deux figure 5.14 et 5.15 montrent des exemples déjà développés.

51
Chapitre 5. Sprint 2 : Profil Equipe qualité 5.4. Réalisation

Figure 5.14 – Interface "Code test"

Figure 5.15 – Interface "Code test"

5.4.4 Préparation de l’environnement de test et lancement de

l’exécution
La troisième étape nous offre le possibilité de sélectionner les packages de tests déjà
développés que nous voulons exécuter comme l’illustre la figure 5.16.

52
Chapitre 5. Sprint 2 : Profil Equipe qualité 5.4. Réalisation

Figure 5.16 – Interface "Step3"

Cette étapes nous offre la possibilité de choisir des packages bien déterminés comme
dans la figure 5.17.

Figure 5.17 – Interface "Sélection des packages de tests"

Et pour terminer cette étape, le testeur clique sur exécuter comme dans la figure 5.18.
L’exécution des tests se déroule en arrière plan dans l’IDE, d’une manière que les résultats
se stockent dans notre base de données sous forme des rapports.

53
Chapitre 5. Sprint 2 : Profil Equipe qualité 5.4. Réalisation

Figure 5.18 – Interface "Exécution des packages de tests"

5.4.5 Consultation des Dashboards

La dernière étape pour un testeur est de consulter les rapports générés comme l’illustre
la figure 5.19.

Figure 5.19 – Interface "Step 4"

Les rapports sont présentés sous forme des dashboards, illustrés dans la figure 5.20, pour
éclaircir les résultats de test pour l’équipe qualité.

54
Chapitre 5. Sprint 2 : Profil Equipe qualité 5.5. Conclusion

Figure 5.20 – Interface "Dashboards"

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.

55
Chapitre 6

Sprint 3 : Profil Equipe software

6.1 Introduction
Dans ce dernier chapitre et en poursuivant l’application du méthodologie Agile, notre
dernier Sprint se présente dans une conception et une réalisation du troisième profil :
Equipe software : Les développeurs de projet, les chefs de projet et les PO (Product
Owner), en mettant en œuvre ses principales fonctionnalités de l’application.

6.2 Sprint Backlog

Le backlog du sprint 3 est détaillé dans le tableau 6.1 avec la difficulté estimée pour
chaque tâche

Tableau Sprint 2 Backlog

Id User Story Id Tâche Estimation
1 Étant un membre de 1.1 Consulter les BDDs 7
l’équipe software, je des tests réalisés sur le
peux consulter les ré- projet.
sultats des tests.

1.2 Consulter les rapports 6

des tests générés.
2 Étant un membre de 2.1 Entrer un login. 7
l’équipe software, je
dois m’authentifier.

2.2 Entrer un mot de 7

passe.

Nous illustrons 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 définies dans un
diagramme de cas d’utilisation de la figure 6.1.

56
Chapitre 6. Sprint 3 : Profil Equipe software 6.3. Conception

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.
Il peut visualiser les résultats des tests effectués sur le projet. Donc, il peut consulter les
scénarios des tests écrits en 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
Dans cette section, nous présenterons les différents diagrammes de séquence détaillés
et le diagramme de classe pour ce dernier Sprint.

6.3.1 Diagrammes de séquences

Nous présenterons dans ce qui suit les diagrammes de séquence détaillés des deux User
Stories du dernier Sprint.

Diagramme de séquence : Authentification

Ce scénario présente la procédure d’authentification comme l’indique la figure de ré-
férence 4.2. Un membre de l’équipe software saisit les informations requises et valide le
formulaire. Une vérification est effectuée au niveau du contrôleur. Si les données saisies
sont incorrectes, un message s’affiche pour l’utilisateur et refait la saisie.

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
software et depuis son espace, il peut sélectionner le test en BDD pour le voir.

57
Chapitre 6. Sprint 3 : Profil Equipe software 6.3. Conception

La figure 6.3 illustre le diagramme de séquence de consultation des tests en BDD.

Figure 6.2 – Diagramme de séquence “Consulter le test en BDD”

Diagramme de séquence : Consulter les rapport

Ce scénario présente la procédure pour consulter les rapport de tests. L’équipe soft-
ware sélectionne le rapport qu’il veut visualiser d’après son espace. La figure 6.4 illustre
ce diagramme.

58
Chapitre 6. Sprint 3 : Profil Equipe software 6.3. Conception

Figure 6.3 – Diagramme de séquence “Consulter les rapport”

6.3.2 Diagramme de classe

La figure 6.4 montre le diagramme de classe de notre application. L’interaction entre
la base de donnée et l’équipe software se présente dans les deux méthodes consulter les
test en BDD et consulter les rapports de tests.

59
Chapitre 6. Sprint 3 : Profil Equipe software 6.4. Réalisation

Figure 6.4 – Diagramme de classe "Equipe Software"

6.4 Réalisation
Dans cette dernière partie, nous présenterons les différentes interfaces liées au travail
effectué. Voici les captures d’écran des interfaces du dernier Sprint.

6.4.1 Espace Equipe Software

La figure 6.5 présente l’interface d’un membre de l’équipe software, là où il peut réaliser
ses besoins de consultations des BDDs et des Dashboards.
Mais avant tout, il doit sélectionner un projet.

Figure 6.5 – Interface "Step1 Equipe Software"

60
Chapitre 6. Sprint 3 : Profil Equipe software 6.4. Réalisation

6.4.2 Consulter les BDDs des tests développés

Un membre de l’équipe software peut visualiser les BDDs des tests pour concevoir
encore le scénario de test étape par étape.
Le BDD est un langage bien claire et facile à comprendre même par un non connaisseur.
La figure 6.6 donne un exemple pour la sélection d’un package afin de voir son BDD.

Figure 6.6 – Interface "Step2 Equipe Software"

La figure 6.7 montre le BDD de ce package sélectionné.

Figure 6.7 – Interface "Step3 Equipe Software"

6.4.3 Consulter les Dashboards

La deuxième fonctionnalité de cet acteur est de visualiser les dashboards générés après
l’exécution du processus de test réalisée par le testeur.
Cette étape aide vraiment ce dernier de concevoir les anomalies commises dans l’étape de
développement des composants du projet.
La figure 6.8 montre comment cet acteur termine son travail avec la dernière étape.

61
Chapitre 6. Sprint 3 : Profil Equipe software 6.5. Conclusion

Figure 6.8 – Interface "Step4 Equipe Software"

6.5 Conclusion
Dans ce dernier chapitre de notre rapport, nous avons présenté les différents étapes de
la réalisation du dernier sprint en passant de la réalisation du sprint backlog, ensuite la
conception détaillée et puis la réalisation.

62
Conclusion Générale

Le début de cette nouvelle décennie sera, surement, marqué par l’automatisation des
tests. Les enjeux liés à la fiabilité et à la qualité des livrables sont devenus si importants
que l’automatisation et 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’automatisation 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 réaliser cet objectif, nous avons commencé par une recherche approfondie sur l’auto-
matisation des tests et de préciser les différents choix technologiques adoptés. Puis, nous
nous sommes focalisés sur l’extraction des différents besoins et fonctionnalités de l’ap-
plication 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.
— Le développement et la création d’une plateforme web où nous pouvons intégrer nos
tests automatisés, visualiser des dashboards des 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 le 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.
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 domaine métier
pour confirmer nos potentiels dans le domaine de l’automatisation des tests.
Il a été 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é à un temps
critique et d’apprendre un ensemble de technologies très répandus dans le domaine de
génie logiciel.
Pour conclure, nous espérons avoir accomplir nos tâches initialement fixées et atteint nos
objectifs définis. Ce projet recèle plusieurs perspectives comme l’automatisation des tests
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.

63
Bibliographie

[1] Présentation de la méthodologie agile, http ://www.blog.azendoo.com.

[10] Selenium, https ://selenium.dev.
[11] Cucumber, https ://logigear.com.
[12] Testng, https ://logigear.com.
[13] Architecture mvc, https ://supinfo.com.
[14] Spring boot, https ://www.tutorialspoint.com.
[15] Angular, https ://www.supinfo.com.
[2] Définition test automatisé, https ://testingdigital.com.
[3] Définition test automatisé, https ://oscigroup.fr.
[4] Définition test automatisé, https ://blog.testingdigital.com.
[5] Intérêts des tests automatisés, https ://oscigroup.fr.
[6] Critères de l’automatisation, https ://itsocial.fr.
[7] Automatisation des tests dans les entreprises, https ://bfmbusiness.bfmtv.com.
[8] Etude supnifo, https ://supnifo.com.
[9] Istqb, https ://gasq.org.

64
Annexe 1

65