1.
PLATEFORME DE
GESTION COLLABORATIVE
Et si mon test était la spécification de mon application ?
Soirée du test logiciel 17/10/2019

2.
QUI SOMMES-NOUS ?

3.
3
Notre histoire
Juillet 2013
Création d’iWE à
Sophia antipolis
2015
Déploiement pour gérer
des sinistres corporels
2016
Levée de fonds de 3M€
2019
Forte croissance du
nombre de projets clients

4.
4
Nous construisons des applications SaaS de gestion collaborative
iWE, plateforme de gestion collaborative

5.
5
Chaque dossier est un espace de travail
collaboratif intégrant l’ensemble des
fonctionnalités de gestion.
Avec iWE, un espace de travail collaboratif unique

6.
6
Le fonctionnement de la collaboration

7.
7
Illustration d’une collaboration sur une application de gestion de sinistre

8.
8
● Design Low Code => Uniquement
du paramétrage
● La construction d’une application
iWE est réalisée en quelques
semaines
Une méthode de construction agile

9.
9
Debut test app
client
L’architecture d’iWE de 2013 à aujourd’hui
Testé par notre
CEO !
Cahier de test
sur excel,
chaque
release est
testée par un
dev + CEO
Jenkins
Automatisatio
n du cahier
de test (2
mois plein)
iWE sur
kubernetes
Démarche
spec = test
Toutes les app
testé (objectif)
Serveurs chez
un client
Architecture
monolithique
Dockecompos
e sur AWS
Enrichissement
des tests auto
Rancher
Microservice
Test sur
plateforme
dédiée K8S
(pulumi, helm,
job)
2014 2016 2019
> 95% de couverture pour test unitaire sur module serveur
Pas de tests unitaires ui (très peu)
Tests End To End 0 300 500 900 1000

10.
QUELLES SONT LES ACTIVITÉS QA CHEZ IWE ?

11.
11
TESTS AUTOMATIQUES DES FONCTIONNALITÉS DE LA PLATE-FORME
● Unit Test : 95% de couverture sur les modules serveur
● Tests automatiques des fonctionnalités de la plate-forme intégrés à une application standard
dédiée aux tests
● Tests enrichis au fur et à mesure de l’ajout de nouvelles fonctionnalités
● Tests de performances
L’ensemble de ces tests constitue une partie de notre référentiel de tests de régression

12.
12
TESTS MANUELS DES APPLICATIONS
● Toute évolution ou nouvelle application fait l’objet de tests manuels de conformité
● Les tests manuels sont décrits en français sous forme de scénarios
L’ensemble de ces scénarios enrichit le référentiel de tests applicatifs

13.
13
TESTS AUTOMATIQUES DES APPLICATIONS
● 1 scénario Sanity automatisé par application
● N tests avancés par application
Le référentiel des tests applicatifs construit par la validation manuelle est un entrant pour
l’automatisation des tests
Les tests applicatifs automatisés font partie du référentiel des tests de régression

14.
ET SI MON TEST ÉTAIT LA SPÉCIFICATION DE
MON APPLICATION ?

15.
15
DE L’EXIGENCE À LA SPÉCIFICATION
● Recensement des Exigences
● Couverture de chaque exigence par 1 ou N scénarios de tests
● Les scénarios de tests spécifient le comportement attendu de l’application
● LE TEST EST LA SPÉCIFICATION DE L’APPLICATION
Dans le cycle de développement, cette phase intervient idéalement avant le développement de
l’évolution répondant à l’exigence

16.
16
DE LA SPÉCIFICATION AU TEST AUTOMATIQUE
● LE TEST AUTOMATIQUE EST LA SPÉCIFICATION DE L’APPLICATION
● Grâce à l’utilisation de RobotFramework
ILLUSTRATION

17.
17
EXEMPLE DE CAHIER DE TEST

18.
18
COUVERTURE
Liste des exigences que couvrent les tests
Liste des exigences complète et indication de la couverture

19.
19
FONCTIONNEMENT DE ROBOTFRAMEWORK
● Framework Open Source d’automatisation de tests d’acceptance
● Surcouche de Sélénium
● Basé sur Python ou Java
● Utilise des Librairies Publiques ou des Librairies Privées

20.
20
FONCTIONNEMENT DE ROBOTFRAMEWORK
Scénario
Test
Keyword
Keyword
Keyword
Test
Keyword
Keyword
Keyword
Librairie publique
Selenium
Mongo
Rest
Excel
Librairie privée
Gestion document
Communications
Notifications
Rendez-vous

21.
21
FONCTIONNEMENT DE ROBOTFRAMEWORK
Connecte moi et donne l’heure
Connexion
Connecte moi
Quelle heure est-il ?
Donne moi l’heure
Librairie privée
Connecte moi
Input Text css=.login Toto
Donne moi l’heure
Get Current Date
Input Text Library “Selenium2Library”
Get Current Date Library “DateTime”

22.
22
*** Settings ***
Documentation Test simple
Suite Setup Setup
Resource ../../resources/common.robot
*** Variables ***
${document} fichier.pdf
*** Test Cases ***
Connexion
Connecte moi avec le login Julienb et le mot
de passe MonMotDePasse
*** Keywords ***
Setup
Go To ${url}
FONCTIONNEMENT DE ROBOTFRAMEWORK
Description du test, Resources
pour l'exécution, Tags...
Déclaration des variables
Tests
Keywords pour le test
Structure d’un fichier de tests :

23.
23
Connecte moi avec le login ${login} et le mot de
passe ${mdp}
Input text css=.login ${login}
Input text css=.mdp ${mdp}
FONCTIONNEMENT DE ROBOTFRAMEWORK
2 possibilités pour construire vos keywords :
Connecte moi
[Arguments] ${login} ${mdp}
Input text css=.login ${login}
Input text css=.mdp ${mdp}
Connecte moi Julienb MonMotDePasse
Keyword ${login} ${mdp}
2 espaces minimum
Connecte moi avec le login Julienb et le mot
de passe MonMotDePasse
Pas de double espace

24.
24
FONCTIONNEMENT DE ROBOTFRAMEWORK
Utilisation des keywords “techniques” :
Connecte moi
[Arguments] ${login} ${mdp}
Input text css=.login ${login}
Input text css=.mdp ${mdp}
Connecte moi Julienb MonMotDePasse
Connecte moi login=Julienb mdp=MonMotDePasse
Connecte moi
[Arguments] ${login}=test ${mdp}=mdptest
Input text css=.login ${login}
Input text css=.mdp ${mdp}

25.
25
FONCTIONNEMENT DE ROBOTFRAMEWORK
Commande pour lancer le test concerné par l’atelier :
robot -A tests/config/staging-preview tests/test-
suites/02_Gestion_d_une_anomalie/01_Scenario_anomalie_corrigee.robot
Option à ajouter pour voir votre test s'exécuter :
-v BROWSER_DISPLAY_MODE:
robot -A tests/config/staging-preview -v BROWSER_DISPLAY_MODE: tests/test-
suites/02_Gestion_d_une_anomalie/01_Scenario_anomalie_corrigee.robot

26.
MISE EN PRATIQUE

27.
27
L’APPLICATION IWE BUG TRACKER MY
Une application iWE de gestion d’anomalies
destinée aux clients de iWE
pour remonter leurs demandes d’évolutions et déclarer des anomalies

28.
28
EXERCICES
1e EXERCICE
Le client exprime un nouveau besoin pour pouvoir avoir accès rapidement à la liste des anomalies
abandonnées.
- Ajouter cette exigence au référentiel des exigences,
- Constater que la couverture de tests ne couvre pas encore cette exigence,
- Ajouter un scénario de test qui couvre cette exigence,
- Constater que la couverture de tests couvre désormais cette exigence
- Exécuter le scénario et constater qu’il échoue car la fonctionnalité n’est pas encore développée
- (Nous déployons la version de l’application dans laquelle la demande est implémentée)
- Exécuter le scénario et constater qu’il fonctionne désormais
2e EXERCICE
Couvrir l’exigence client non couverte qui consiste à permettre au client de rejeter une anomalie.
- Ajouter au scénario de gestion de l’anomalie existant une variante dans laquelle le client rejette
l’anomalie, ensuite une nouvelle correction est apportée avant que le client accepte la
correction
- Constater que la couverture de tests couvre désormais cette exigence,
- Exécuter le scénario de tests
- Générer le cahier de tests
SUIVEZ LE GUIDE ! Sur chaque poste ouvrez workshop/app-issue-tracker/tests/readme.md

29.
Merci aux Sponsors !
Nicolas Jacob
nicolas.jacob@iwecloud.com
i-we.io SAS au capital de 290 225 euros - SIRET : 79457663700035 - Immeuble les templiers, 950 routes des Colles, 06410 BIOT
Lindsay Verdat
lindsay.verdat@iwecloud.com
Julien Besace
julien.besace@iwecloud.com