• Projets

Tests fonctionnels, réussissez la recette de votre projet !

La phase de tests fonctionnels d’un projet web, aussi appelée recette, est la période la plus délicate d’un projet. En effet, il est difficile de mettre tout le monde d’accord !

Trop d’anomalies (de bugs) ? Le client, donc les futurs utilisateurs, pourrait penser que la qualité de la solution est mauvaise donc rejeter la solution.

Pas assez d’anomalies ? L’équipe de développement, qui sait bien qu’une solution n’est jamais parfaite, va se dire que les utilisateurs ne testent pas et que la mise en production risque d’être catastrophique ! 

… Alors, qui a raison ? Un peu les deux ! En fait, cela dépend :

• Si l’application répond aux besoins (spécifications) et qu’elle fonctionne correctement en termes de performances, j’ai tendance à penser que c’est très bien de trouver de nombreux bugs ! 

• Si une application a de très mauvaises performances, si les bugs ne sont pas résolus rapidement, alors cela peut cacher des problèmes structurels… Ce qui peut devenir très embêtant. 

Dans cet article, nous proposons de faire un tour d’horizon des bonnes pratiques pour réussir votre phase de tests fonctionnels.

Quelle est la différence entre les tests d’intégration et les tests fonctionnels ?

Les tests d’intégration se concentrent sur les interactions entre les composants de l’application, tandis que les tests fonctionnels se concentrent sur le comportement global de l’application du point de vue de l’utilisateur. 

Tests d’intégration :

La première étape est déjà de bien implémenter vos tests unitaires.

Les tests d’intégration examinent ensuite la manière dont les modules, les classes ou les composants interagissent les uns avec les autres. Ils peuvent impliquer plusieurs unités de code, mais ils ne s’étendent pas nécessairement à l’ensemble de l’application.

Imaginons un site web de commerce électronique. Un test d’intégration pourrait vérifier que le panier d’achat, le processus de paiement, et la gestion des produits fonctionnent ensemble correctement. Le test pourrait vérifier que les produits sont ajoutés au panier, que le total est calculé correctement, et que le paiement est effectué sans problème.

Tests fonctionnels :

Les tests fonctionnels vérifient si le logiciel fonctionne conformément à ses spécifications et aux attentes de l’utilisateur. Ils se concentrent sur le comportement fonctionnel de l’application. Ils couvrent l’ensemble de l’application ou d’une fonctionnalité spécifique du début à la fin. Ils examinent les scénarios d’utilisation, les flux de travail et les interactions avec l’utilisateur.

Reprenons l’exemple du site web de commerce électronique. Un test fonctionnel pourrait vérifier l’ensemble du processus d’achat, de la navigation sur le site, en passant par la sélection d’un produit, l’ajout au panier, la création d’un compte client, le paiement, et enfin la confirmation de la commande. Le test s’assurerait que chaque étape se déroule correctement, que les pages s’affichent correctement, que les formulaires fonctionnent, etc.

Comment faire des tests fonctionnels ? 

Il faut d’abord créez une liste de scénarios de test et identifiez les critères de réussite.

Identifiez les scénarios de test qui couvrent toutes les fonctionnalités et les cas d’utilisation critique de votre projet web.

Nous vous recommandons de commencer par le  “happy path”, c’est-à-dire le chemin complet qui permet de faire le tour de l’ensemble des fonctionnalités de l’application sans erreur. 

Par exemple, imaginons un scénario de l’envoi d’un message, le test fonctionnel pourrait prendre la forme suivante (assez simple) : 

Il est intéressant d’identifier les tests prioritaires car cela vous permet de vous concentrer sur les tests les plus critiques en premier.

Est-il possible d’automatiser les tests fonctionnels ? 

Il est possible d’utiliser des outils pour automatiser les tests fonctionnels comme Selenium ou Cypress.

Attention cependant, automatiser de trop nombreux tests pendant le développement est souvent une erreur. Durant cette phase, l’application peut changer et maintenir ces tests peut se révéler très coûteux.

En revanche, construire un set de tests qui permet de vérifier les fonctionnalités clés de l’application (par exemple la création d’un client, etc.) permet d’éviter de nombreuses régressions. En plus, on intègre alors ces scripts dans le pipeline et on vérifie que les tests se sont bien exécutés. 

Dans cet exemple, le script Selenium remplit un champ et clique sur un bouton.  (Vous aurez besoin de l’extension PHP WebDriver, ainsi que d’un pilote (WebDriver) approprié pour le navigateur que vous souhaitez utiliser (par exemple, Chrome WebDriver).

<?php

require_once('vendor/autoload.php');

use Facebook\WebDriver\Remote\RemoteWebDriver;

use Facebook\WebDriver\WebDriverBy;

// URL du serveur Selenium WebDriver

$host = 'http://localhost:4444/wd/hub';

// Configuration du pilote (dans cet exemple, Chrome)

$capabilities = ['platform' => 'LINUX', 'browserName' => 'chrome'];

// Création d'une instance du navigateur

$driver = RemoteWebDriver::create($host, $capabilities);

//Evidemment, il faut mettre l’URL que vous souhaitez tester

$driver->get("https://www.example.com");

// Identifier un champ de saisie par son ID

$inputField = $driver->findElement(WebDriverBy::id("input_id"));

// Saisir du texte dans le champ

$inputField->sendKeys("Texte à saisir");

// Identifier le bouton de validation

$button = $driver->findElement(WebDriverBy::id("button_id")); 

// Effectuer une action de clic sur le bouton

$button->click();

// c’est juste pour voir le résultat que l’on attend 3s. 

sleep(3);

$driver->quit();

A vous de jouer ! 

Mettez en place l’organisation et outillez la gestion des tickets 

L’organisation de la recette est critique pour le succès du projet.

Planifiez au plus tôt les périodes où vous allez mobiliser les utilisateurs et les livraisons des corrections. Ne tentez pas de faire une recette trop courte même si la mise en production est urgente. C’est un temps incompressible !  

Par ailleurs, oubliez la feuille Excel que l’on s’échange par e-mail… Impossible de travailler avec cela. Il vous faudra nécessairement éduquer un peu vos utilisateurs. Un outil de gestion des anomalies va vous permettre de documenter soigneusement tous les problèmes identifiés, y compris les étapes pour les reproduire et les informations de contexte.

Un bon outil (comme par exemple Jira, Asana ou même des outils un peu plus ancien comme Mantis) va vous permettre de gérer des données comme : 

• Auteur de l’anomalie : le testeur à l’origine du ticket.
• Description de l’anomalie : une description détaillée du problème ou de l’anomalie, y compris les étapes pour la reproduire, les résultats attendus et les résultats observés.
• Le statut de l’anomalie : le statut actuel de l’anomalie, qui peut inclure des états tels que Ouvert, Assigné, En cours de résolution, Résolu ou Fermé. 
• Le niveau de gravité : la gravité de l’anomalie, qui peut être basée sur l’impact sur l’utilisateur ou sur le système. Les niveaux de gravité sont généralement évalués de  Bloquant, Majeur et Mineur.
• Développeur assigné à l’anomalie.
• Historique et gestion des dates : la date de création, la date de dernière modification, …
• Autres fichiers : captures d’écran ou pièces jointes,… 

Un système simple de suivi devra permettre surveiller des indicateurs clés tels que : 

• Suivre le nombre des anomalies par statut par semaine par exemple, 
• D’évaluer le nombre d’anomalie fermée ou ouverte sur la même période, 
• De connaître le nombre de corrections apportées à l’application…

Conclusion : pas de recette miracle pour vos tests fonctionnels

Sans vouloir vous décourager, des études ont montré que, en moyenne, environ 15 à 50 % des bugs sont détectés lors de la phase de tests fonctionels. Cela signifie que même avec des tests fonctionnels rigoureux, de nombreux bugs peuvent passer inaperçus jusqu’à ce que l’application soit utilisée en production.

Est-ce que cela veut dire qu’il faut s’en passer ? Certainement pas ! Les risques potentiels qu’implique une mauvaise gestion de la phase de recette sont nombreux : régressions en production, difficulté de maintenir l’outil à terme. 

Pour finir, j’ai envie de donner quelques conseils aux équipes de développement qui doivent faire tester leur application et livrer leur application : 

• Accompagnez les utilisateurs dans la rédaction des cahiers de tests, c’est souvent la première fois qu’ils doivent rédiger un tel document ; 
• Pour ne pas paniquer les utilisateurs, soyez physiquement là lors des premiers tests surtout si l’environnement est installé pour la première fois, cela vous évitera de vous fâcher avec eux si votre application rencontre des problèmes d’environnement. 

Alors, pour conclure sur un mauvais jeu de mot, il n’y a pas de recette miracle pour faire une recette parfaite ! Mais si vous souhaitez en discuter avec nous, n’hésitez pas à me contacter sur LinkedIn.

par TheCodM
Publié le 12 février 2024