Recap de la semaine du 13 [Year]

Daryl Noupik

Formation tests

Zenity |
Contents
Objectifs des tests :..............................................................................................................................2
Déboguer vs tester :............................................................................................................................2
Origine des défauts logiciels.............................................................................................................2
Tests et Assurance Qualité................................................................................................................2
Les 7 principes généraux des tests :.............................................................................................2
PlayWright...............................................................................................................................................7
1. Définitions de playwright.......................................................................................................7
2. Fonctionnalités Clés de Playwright.....................................................................................7
a) Navigation et Interactions avec la Page............................................................................7
b) Prise de Captures d'Écran et Enregistrement de Traces Réseau..............................7
c) Prise en Charge Multi-Navigateurs......................................................................................7
d) Scénarios Complexes...............................................................................................................7
Installation...........................................................................................................................................8
Ecrivez vos premiers tests :...................................................................................................................11
Objectifs des tests :
 Trouver des défauts et des défaillances
 Acquérir de la confiance
 Fournir de l’information utile aux prises de décisions
 Prévenir des défauts.

Déboguer vs tester :
Déboguer : le processus de trouver, analyser et éliminer les causes de défaillance dans les
logiciels.

Origine des défauts logiciels

Erreur (méprise) :
Défaut (BUG) : dans le code ou la documentation
Défaillance : résultat de l’exécution d’un défaut dans le code, le système ne fait pas ou fait
différemment.

Tests et Assurance Qualité

Le test doit faire partie des activités d’assurance qualité
 L’assurance qualité et le test ne sont pas les mêmes, mais ils sont lies
 L’assurance qualité concerne l’exécution correcte du processus global de
développement ou de maintenance du logiciel afin de donner l’assurance que le niveau
de la qualité sera atteint
 Les activités de tests font partie de ce processus
Le test contribue à améliorer la qualité.

Les 7 principes généraux des tests :

- Principe 1 – les tests montrent la présence de défauts
- Principe 2 – Les tests exhaustifs sont impossibles
- Principes 3 – Tester tôt
- Principe 4 : regroupement des défauts
- Principe 5 - Paradoxe du pesticide
- Principe 6 – Les tests dépendent du contexte.
- Principe 7 – L’illusion de l’absence d’erreurs

Voici les sept principes généraux du test à avoir à l’esprit :

 Les tests montrent la présence de défauts, mais ils ne peuvent pas garantir l’absence de
défauts.
  Les tests exhaustifs sont impossibles. On aura beau faire tous les tests qu’on imagine, il
y en aura toujours auxquels on n’aura pas pensé.
 Tester au plus tôt.
 Le regroupement de défauts. Cela peut sembler étonnant, mais bien souvent, quand il y
a une anomalie sur une fonctionnalité, alors il y a de fortes chances d’en trouver d’autres
à proximité.
 Le paradoxe du pesticide.
Le paradoxe du pesticide nous indique que si nous faisons toujours les mêmes tests, au bout
d’un moment il n’y aura plus de défauts sur ces tests, mais il pourrait y en avoir ailleurs ou des
défauts différents sur les mêmes fonctionnalités. Il est donc important d’adapter les tests
pour chaque campagne de test. Ce principe est appelé “paradoxe du pesticide” en référence
à l’utilisation d’un même pesticide qui devient moins efficace avec le temps.
 Les tests dépendent du contexte. On ne testera pas de la même façon une application
bancaire avec des exigences élevées de sécurité qu’une application pour consulter la
météo.
 L’illusion d’absence d’erreur. Il est important de comprendre que l'absence apparente
d'erreurs lors des tests ne garantit pas l'absence réelle d'erreurs. Il est possible que les
tests effectués ne couvrent pas tous les scénarios possibles.

La principale mission d’un testeur est de contrôler si un nouveau produit informatique (logiciel,
équipement, système, etc.) est conforme au besoin. Pour vérifier la conformité d’un produit, le
testeur doit :
 Prendre connaissance des spécifications du produit et des normes qui lui sont imposées
;
 Créer différents outils de test afin de préciser et définir tous les points à vérifier ;
 Effectuer des tests jusqu’à ce que chaque point soit validé et conforme ;
 Reporter avec précision les résultats une fois tous les tests effectués.
Tester c’est faire trois choses essentielles :
 Vérifier : s’assurer que les choses sont faites conformément à ce qui a été défini.
o C’est se demander “est-ce que ça marche ?”, “est-ce que ça fonctionne ?” par
rapport à ce qu’on a défini au préalable de manière explicite (dans un cahier des
charges technique ou une user story).
 Valider : s’assurer que l’objectif initial est atteint.
o C’est se demander “est-ce que ça convient à mon utilisateur ?”, “est-ce que cette
solution répond correctement à un besoin de mon utilisateur ?”
 Explorer : s’assurer que les spécifications implicites sont prises en compte dans
l’activité de test.
 o C’est se demander “est-ce que le système est robuste ?”, “est-ce qu’il est
performant ?”, “est-ce qu’il y a des anomalies cachées ?”

Ils consistent à :
 Évaluer un produit, c’est-à-dire donner de l’information sur un niveau de qualité ;
 Vérifier la conformité du produit aux exigences, spécifications ou User Stories, c’est-à-
dire donner de l’information sur un niveau de complétude ;
 Prévenir les défauts ;
 Construire la confiance dans le niveau de qualité du logiciel ;
 Réduire les coûts : cela coûte moins cher de corriger au plus tôt ;
 Assurer la satisfaction client car si un logiciel arrive en production avec plusieurs
anomalies, les utilisateurs ne seront pas satisfaits et risquent de ne plus utiliser ce
produit même si ces anomalies sont corrigées par la suite.

Un cahier de recette (ou “cahier de test”) est un document qui décrit les étapes à suivre pour
tester un système. Il est utilisé pour s’assurer que le système fonctionne correctement et répond
aux exigences

Les tests exploratoires permettent d’aller au-delà des tests du cahier de recette. Ils
correspondent à une approche de test de logiciel qui consiste à explorer le système de manière
informelle et à identifier les problèmes et les anomalies.
Les tests exploratoires permettent de trouver les défauts :

- Trouver des défauts

- Identifier des problèmes inattendus
- Améliorer l’utilisabilité et la stabilité
- Trouver des anomalies sur les exigences et la conception
- S’adapter à tous les cycles de vie
- Eviter le paradoxe du pesticide
- Diminuer fortement le temps alloue à l’écriture et à la conception des tests
- Exécuter un plus grand nombre de tests

L’organisation d’une session de tests exploratoires répond aux principes suivants :

 Organisation en sessions minutées et limitées par la charte ;
 Pilotage par les chartes de test, une charte = une guideline à respecter ;
 Exécution et description sont faites en même temps ;
 Documentation de toutes les actions ;
 Capture des résultats de test ;
 Les résultats du test précédent guident le test suivant ;
 Utilisation d’outils : heuristiques, persona… ;
 Création d’un rapport permettant de partager les résultats (observations, commentaires,
anomalies).

Quelques exemples d’heuristiques de test :

 Heuristique de comparaison : comparer les résultats obtenus avec les résultats

attendus pour s’assurer que les fonctions du logiciel sont correctes.
 Heuristique de configuration : tester différentes configurations système pour
s’assurer que le logiciel fonctionne correctement dans toutes les situations.
 Heuristique de détection : chercher des signes d’erreurs ou de défauts dans le
comportement du logiciel pour trouver les bugs.
 Heuristique de diversité : tester une grande variété de scénarios pour s’assurer
que le logiciel fonctionne correctement dans toutes les situations possibles.
 Heuristique de l’expérience utilisateur : tester le logiciel du point de vue de
l’utilisateur pour s’assurer qu’il est convivial et facile à utiliser.
 Heuristique de la fiabilité : tester le logiciel pour s’assurer qu’il est fiable et qu’il
ne tombe pas en panne.
 Heuristique de la performance : tester les performances du logiciel pour
s’assurer qu’il est réactif et qu’il ne ralentit pas avec l’utilisation.
  Heuristique de la sécurité : tester le logiciel pour s’assurer qu’il est sécurisé et
qu’il ne présente pas de risques pour les utilisateurs.

Un testeur doit être bon communiquant.

Les niveaux de tests :

- Tests de composants (tests unitaires)

- Tests d’intégration
- Tests système
- Tests d’acceptation

Types de tests :

- Tests fonctionnels
- Tests non fonctionnels
- Tests structurels
- Tests lies au changement

Processus de revue :
Les 6 phases selon le syllabus ISTQB :

- Planification
- Lancement
-
PlayWright

1. Définitions de playwright
Playwright est un outil open source conçu pour automatiser les tests de navigateurs web, ainsi
que pour effectuer des interactions programmées avec des applications web. Développé par
Microsoft, Playwright offre une approche multi-navigateurs, prenant en charge des navigateurs
populaires tels que Chrome, Firefox et Safari.

Est un logiciel de tests de bout en bout / end to end. Playwright prend en charge tous les
moteurs de rendu modernes notamment :

- Chromium
- Webkit
- Firefox

Playwright se distingue par sa capacité à gérer des scénarios complexes, tels que l'émulation
de dispositifs mobiles, la géolocalisation, et la capture de performances. Son API unifiée et sa
prise en charge de plusieurs langages de programmation, tels que JavaScript, TypeScript,
Python et C#, en font un choix attrayant pour les développeurs.

2. Fonctionnalités Clés de Playwright

a) Navigation et Interactions avec la Page

Playwright permet de naviguer à travers les pages web et d'interagir avec les éléments de
manière intuitive. Il offre des méthodes simples pour cliquer, remplir des formulaires, et
manipuler le DOM, simplifiant ainsi l'écriture de scripts de test.

b) Prise de Captures d'Écran et Enregistrement de Traces Réseau

La capacité de capturer des captures d'écran à des moments spécifiques dans le test et
d'enregistrer des traces réseau permet aux développeurs de diagnostiquer rapidement les
problèmes et d'améliorer les performances de leurs applications.

c) Prise en Charge Multi-Navigateurs

Playwright se distingue par sa prise en charge de plusieurs navigateurs, réduisant ainsi les
contraintes liées à un navigateur spécifique. Cela garantit une plus grande portabilité des tests
sur différentes plates-formes.
 d) Scénarios Complexes
Des fonctionnalités avancées, telles que l'émulation de dispositifs mobiles, la gestion des
cookies, et la simulation de conditions réseau variées, font de Playwright un choix idéal pour
automatiser des scénarios de test complexes

Installation

Playwright s’installe via l’utilitaire npm ou fil avec la commande :

 npm init playwright@latest ou yarn create playwright

Une fois que la commande est run :

 Choisissez entre TypeScript ou Javascript
 Ensuite vous insérez le nom du dossier Tests (la valeur par défaut est tests ou e2e si
vous avez déjà un dossier tests dans votre projet)
 Ajoutez un Workflow GitHub Actions pour facilement exécuter vos tests sur CI
 Installer les navigateurs Playwright (la valeur par défaut est vraie)

Figure 1: Installation de playwright

Une fois l’installation terminer playwright créera les fichiers suivants :

Figure 2: Structure de l'installation playwright

Le fichier playwright.config.ts est l'endroit où vous pouvez ajouter une configuration pour
Playwright, notamment en modifiant les navigateurs sur lesquels vous souhaitez exécuter
Playwright. Si vous exécutez des tests dans un projet déjà existant, les dépendances seront
ajoutées directement à votre fichier package.json.
 Le dossier tests contient un exemple de test de base pour vous aider à démarrer les tests.
Le dossier tests-examples est un dossier qui contient des tests écrits pour tester une
application Todo.

Par défaut tous les tests seront exécutés sur les 3 navigateurs en utilisant 3 workers.
Nb : les workers (ou travailleurs en français) font référence à des scripts exécutés dans des
contextes de travailleurs dédiés, tels que les Web Workers en JavaScript. Les travailleurs
sont des threads séparés qui s'exécutent en parallèle avec le thread principal de la page. Ils
sont utilisés pour effectuer des tâches en arrière-plan sans bloquer l'interface utilisateur.
Cela pouvant être configurer dans le fichier playwright.config.

Les tests sont exécutés en mode sans tête signifiant qu’aucun navigateur ne s’ouvrira lors de
l’exécution de ces derniers.
Pour exécuter les tests l’on procède en lançant la commande suivante : npx playwright test
dans le terminal

Si vous souhaitez exécuter vous tests en mode UI pour une meilleure expérience de
développement où vous pouvez facilement parcourir chaque étape du test et voir visuellement
ce qui se passait avant, pendant et après chaque étape, vous pouvez utiliser la commande :

npx playwright test --ui

Figure 3: Playwright test UI

Le mode UI est également livré avec de nombreuses autres fonctionnalités telles que le
sélecteur de localisateur, le mode montre et bien plus encore.

Vous pouvez également les exécuter en mode dirige en utilisant le flag –headed, qui vous
donnera la possibilité de voir visuellement comment playwright interagit avec le site web

npx playwright test --headed

Pour spécifier sur quel navigateur vous souhaitez exécuter vos tests vous pouvez utiliser le flag
–project :

npx playwright test --project webkit

Pour spécifier plusieurs navigateurs

npx playwright test --project webkit --project firefox

Pour exécuter un ensemble de fichiers de test à partir de différents répertoires, indiquez-les

npx playwright test tests/todo-page/ tests/landing-page/

Pour exécuter des fichiers qui ont landing ou login dans le nom de fichier, transmettez
simplement ces mots-clés à la CLI.

npx playwright test landing login

Pour lancer un test avec un titre spécifique utilisez le flag -g suivi du titre du test.

npx playwright test -g "add a todo item"

Pour déboguer tous les tests , exécutez la commande playwright test suivie du flag –debug

npx playwright test --debug

Figure 4: Execution du playwright test --debug

Cette commande ouvrira une fenêtre de navigateur ainsi que l'inspecteur Playwright. Vous
pouvez utiliser le bouton de passage en haut de l'inspecteur pour parcourir votre test. Ou
appuyez sur le bouton de lecture pour exécuter votre test du début à la fin. Une fois le test
terminé, la fenêtre du navigateur se fermera.
Pour déboguer un fichier de test, exécutez la commande Playwright test avec le nom du fichier
de test que vous souhaitez déboguer suivi de --debug

npx playwright test example.spec.ts --debug

Pour déboguer un test spécifique à partir du numéro de ligne où est défini, ajoutez deux points
suivis du numéro de ligne à la fin du nom du fichier de test, suivis de l’indicateur –debug

npx playwright test example.spec.ts:10 --debug

Pour mettre ajour playwright exécutez la commande suivante :

npm install -D @playwright/test@latest

Vous pouvez toujours vérifier quelle version de Playwright vous possédez en exécutant la
commande suivante :

npx playwright --version

Ecrivez vos premiers tests :

Pour commencer l’on commence d’abord par la navigation vers l’url ensuite le test pourra interagir avec
les éléments de la page :

await page.goto('https://playwright.dev/');

Ensuite playwright continue l’exécutions d’actions par la localisation des éléments. Pour ce faire il utilise
L’API Locators .

Les interactions

L'exécution d'actions commence par la localisation des éléments. Playwright utilise l'API Locators pour
cela. Les localisateurs représentent un moyen de retrouver des éléments sur la page à tout moment,
découvrez les différents types de localisateurs disponibles. Playwright attendra que l'élément
soit exploitable avant d'effectuer l'action, il n'est donc pas nécessaire d'attendre qu'il soit disponible.

// Create a locator.
const getStarted = page.getByRole('link', { name: 'Get started' });
// Click it.
await getStarted.click();

On peut raccourcir en utilisant la syntaxe :

await page.getByRole('link', { name: 'Get started' }).click();

Action Description
localisateur.check() Cochez la case de saisie
localisateur.click() Cliquez sur l'élément
localisateur.uncheck( Décochez la case de saisie
)
localisateur.hover() Passez la souris sur l'élément
localisateur.fill() Remplissez le champ du formulaire, saisissez
le texte
localisateur.focus() Concentrez l'élément
localisateur.press() Appuyez sur une seule touche
localisateur.setInput Choisissez les fichiers à télécharger
Files()
localisateur.selectOp Sélectionnez l'option dans la liste déroulante
tion()
Playwright inclut des assertions de test sous forme de fonction expect. Pour faire une affirmation,
appelez expect(value) et choisissez un correspondant qui reflète l'attente.

Il existe de nombreux comparateurs génériques comme toEqual, toContain, toBeTruthyqui peuvent être
utilisés pour affirmer n'importe quelle condition.

expect(success).toBeTruthy();

Playwright inclut également des matchers asynchrones qui attendront que la condition attendue soit
remplie. L'utilisation de ces matchers permet de rendre les tests non floconneux et résilients. Par
exemple, ce code attendra que la page obtienne le titre contenant « Playwright » :

await expect(page).toHaveTitle(/Playwright/);

Playwright Test est basé sur le concept de montages de test tels que le montage de page intégré , qui est
transmis à votre test. Les pages sont isolées entre les tests en raison du Browser Context , qui équivaut à
un tout nouveau profil de navigateur, dans lequel chaque test bénéficie d'un nouvel environnement,
même lorsque plusieurs tests sont exécutés dans un seul navigateur.

tests/exemple.spec.ts

import { test } from '@playwright/test';

test('example test', async ({ page }) => {

// "page" belongs to an isolated BrowserContext, created for this specific test.
});

test('another test', async ({ page }) => {

// "page" in this second test is completely isolated from the first test.
});

Utilisations des hooks :

Nous pouvons utiliser différents hooks de test tels que test.describe pour déclarer un groupe de tests
et test.beforeEach ,test.afterEachsont qui sont exécutés avant/après chaque test. D'autres hooks
incluent le test.beforeAll et test.afterAllqui sont exécutés une fois par worker avant/après tous les tests.

import { test, expect } from '@playwright/test';

test.describe('navigation', () => {

test.beforeEach(async ({ page }) => {

// Go to the starting url before each test.

await page.goto('https://playwright.dev/');

});

test('main navigation', async ({ page }) => {

// Assertions use the expect API.

await expect(page).toHaveURL('https://playwright.dev/');

});

});

Generation de tests

Utilisez la comande codegen pour executer le generateur de tests suivie de l’url du site web pour lequel
vous souhaitez generer des tests.L'URL est facultative et vous pouvez toujours exécuter la commande
sans elle, puis ajouter l'URL directement dans la fenêtre du navigateur.

npx playwright codegen demo.playwright.dev/todomvc

Formations
Jour 08/01/2024

Méthode agile :

L’agilité : Développer de manière itérative et incrémentale une application.

On requiert une organisation stricte (Daily meeting)
La méthodologie agile préconise la fixation d’objectifs à court terme en les réajustant.
On distingue 3 méthodes agiles :

- Scrum
- Kanban
- XP :eXtreme Programming

Au sprint 0 : le testeur fait ce que l’on appelle le test statique .Relire les exigences du product
owner dans la phase 0.
La plupart des bugs proviennent d’une exigence .
Préparation de l’environnement de tests.
Le 3 amigos qui va réunir le product owner , le testeur et développeur.
Le but recherché est le minimum value product (MVP).

4 valeurs du manifeste Agile :

- Accorder de l’importance aux individus et interactions plutôt qu’aux processus et aux

outils
- Accorder aux fonctionnalités operationnelles plutôt qu’a la documentation exhaustive
- A la collaboration avec le client plutôt qu’a la contractualisation des relations .
- L’acception du changement plutôt qu’a la conformité aux plans

Phases d’analyse des risques .

Les 12 principes du manifeste Agile :

- Satisfaire le client en priorité

- Accueillir favorablement les demandes de changement
- Livrer en permanence un produit opérationnel
- Assurer une collaboration client -Equipe
- Collaborer avec des équipes motivées
- Favoriser le dialogue direct
- Mesurer l’avancement du projet sur le plan opérationnel
- Avoir un rythme constant et soutenable
- Contrôler la conception et l’excellence technique
- La simplicité
- Responsabiliser les équipes
- L’efficacité

XP : Extreme programming rôle : client

Principes de XP :

- La communication
- Simplicité
- Feedback
- Respect
- Courage

Les phases de tests trouvent leur place lors de chaque sprint.

Test statique => revue / relecture us
Préparations des outils Xray et Jira
Préparations des campagnes de tests et rédaction des cas de test qui seront exécutés au sprint
1.

Les TNR : les tests de non régression.

Si la cellule de tests relève des ambiguïtés dans les Us , elle les remonte au(x) product owner
(s) afin de les lever et d’expliciter le besoin.

- Faux positif
- Faux négatif

Les tests statiques :

Les tests dynamiques : tests bases sur l’exécution d’un programme afin d’en vérifier.

Les tests Manuels : tests exécutés manuellement par un testeur avec l’appui d’un outil de
centralisation du référentiel de tests afin de décrire les étapes de test.

Les tests automatiques : tests exécutés automatiquement par un robot. Script exécute est le
fruit du travail d’un expert en automatisation des tests .la charge de conception des tests
automatiques est de 5 à 7 fois plus couteuse . Il est conseillé d’automatiser un test lorsqu’il est
exécuté 7 fois .

Tests vitaux âpres une Mise en production

Tests dynamiques fonctionnalites : verifier si les fonctionnalites livre

Une anomalie a un identifiant unique

La gestion des risques :

Le plan de test contient :

- Une introduction ou fiche descriptive

- Une description du scope et du out of scope
- Une analyse des risques que permettent de couvrir les tests exécutés
- Les ressources matérielles et les horaires
- Outils et environnements nécessaire pour faire les tests