Ci-dessous, une liste non-exhaustive des types de tests que l’on peut mettre en place sur un projet web. Tous ne sont pas indispensables, mais c’est bien de les avoir en tête pour définir une stratégie de qualité sur un projet.

Q1

Les Tests unitaires

Ce sont des tests qui vérifient le code en lui-même, morceau par morceau : on teste au niveau des fonctions ou des classes sans les faire interagir avec d’autres parties du code ou d’autres briques (base de données, services externes…). Ils sont écrits par les développeurs. Ils servent à la suite de tests automatisés.

Les Tests de composants (on d’intégration)

Ils viennent juste après les tests unitaires : ils vérifient que différentes briques du codes interagissent correctement entre elles. Ils sont écrits par les développeurs. Ils servent à la suite de tests automatisés.

Les tests d’API

Ils servent à vérifier que la communication avec les API et webservices est à jour avec la spécification de chaque API. Ils peuvent être gérés par les développeurs ou les testeurs. Ils peuvent être intégrés à la suite de tests automatisés.

Q2

Les tests fonctionnels

Ce sont des tests qui vérifient l’application d’une point de vue fonctionnel, telle qu’elle peut être utilisée par l’utilisateur final. Ils reproduisent des parcours complets (tests de bout en bout) et se basent sur les spécifications métiers. Ils sont gérés par les testeurs.

Les tests de validation

Ce sont les tests qui vérifient les fonctionnalités au fur et à mesure du développement. On se base sur des exemples (scénarios) pour valider qu’on répond correctement au besoin du métier. Ils permettent d’avoir une compréhension commune entre le métier et l’équipe technique (développeurs et testeurs) sur le besoin. On peut aussi les automatiser, dans ce cas ils peuvent être écrits par les développeurs ou les testeurs et ils peuvent être intégrés à la suite de tests automatisés.

Les tests UX

Ils vérifient que l’ergonomie du site est la meilleure possible, en se basant sur des prototypes, des wireframes, des maquettes. Si on discute ces premières versions de l’interface, on gagnera du temps par rapport au fait de modifier a posteriori des versions livrées par les développeurs. Idéalement, une enquête peut être menée par l’UX designer pour confronter des hypothèses avec un panel de volontaires, y compris sur des interfaces déjà en place.

Le pair testing

Se rapproche du test exploratoire (voir ci-dessous), mais en binômes : testeur-PO, développeur-PO, testeur-testeur. L’un des deux effectue les tests, l’autre dirige (fiexe un objectif pour la session de test) et trace les résultats. Le pair testing entre un testeur et un développeur permet de détecter les défauts plus tôt, identifier les causes plus vite, corriger et tester la correction.

Les tests de compatibilité de navigateurs

Ce sont les tests qui vérifient le rendu, le fonctionnel et la cohérences des pages selon les navigateurs et les systèmes d’exploitations utilisés. Il faut aussi prendre en compte les tailles d’écrans et les rendus tablettes et mobiles, ainsi que des actions comme redimensionner l’écran et zoomer le contenu. On se base généralement sur un choix de navigateurs supportés, d’après des statistiques utilisateurs. Ils doivent être gérés par les développeurs pendant le développement et les testeurs en phase de validation.

Les tests fil rouge

On sélectionne les fonctionnalité les plus critiques de l’application et on joue les tests les plus importants, pour vérifier que les parties critiques de l’application fonctionnent toujours. Cela permet de savoir s’il faut aller plus en détail dans les tests où s’il faut s’occuper tout de suite de corriger le plus important. On peut aussi les automatiser, dans ce cas ils peuvent être écrits par les développeurs ou les testeurs et ils peuvent être intégrés à la suite de tests automatisés.

Q3

A/B Testing

C’est une forme de test qui permet de mettre en production deux versions graphiques du site en parallèle et de vérifier laquelle est la plus adaptée aux utilisateurs, via des statistiques en temps réel.

Les tests exploratoires

C’est un type de tests informels (dans le sens où ils ne suivent pas un script ou un cahier de recette pré-établi), qui permet de chercher des erreurs non couvertes par les tests habituels, notamment les tests automatisés. On se donne un objectif donné en un temps limité, et on essaye d’en apprendre le maximum sur la manière dont réagit l’application dans ce cadre donné. Ils sont habituellement menés par les testeurs.

Les tests d’ergonomie (ou d’utilisabilité)

C’est un type de test qui permet de savoir si l’application est convivial, simple à utiliser (user-friendly). On observe le comportement des utilisateurs et on étudie leur réponse émotionnelle : sont-ils content d’utiliser le produit? est-ce que certaines étapes les stressent? etc.). Cette collecte de données permet d’améliorer l’expérience utilisateur en incorporant des changements qui rendront l’utilisation plus simple.

Les tests d’intégration (des services externes)

Ce sont des tests qui vérifient la communication avec des applications externes (webservices GRDF) ou des dépendances externes (Google APIs…). Ils incluent généralement des tests fonctionnels gérés par les testeurs.

Les tests utilisateurs de validation (Beta Tests)

Ce sont des tests réalisés par une sélection d’utilisateurs “experts”, pour valider que l’application répond à leurs besoins métiers et correspond à des scénarios d’utilisation réelle.

Les tests d’accessibilité

Ce sont des tests qui vérifient que le contenu de l’application est facilement accessible pour les personnes à handicap. Ont-elles des difficultés à visualiser les couleurs? les contrastes? les boutons? les textes trop petits?

Q4

Les tests d’évolutivité

Ce sont des tests non-fonctionnels qui vérifient comment réagit l’application quand les utilisateurs inscrits, les transactions ou la base de données augmentent. Continuera-t-elle à répondre correctement si son utilisation habituelle devient beaucoup plus importante qu’aujourd’hui? Ces tests sont gérés par les opérateurs système.

Les stress tests

Ce sont des tests qui vérifient comment l’application réagit quand elle est soumise à des pics de charge, y compris quand on dépasse sa capacité. On doit aussi tester les ressources insuffisantes comme le CPU, la mémoire, l’espace disque, etc. Cela permet de vérifier la robustesse et la fiabilité du système. Ces tests sont gérés par les opérateurs système.

Les tests de charge

Ce sont des tests qui permettent de connaitre le comportement de l’application en situation de charge normale et en pic de charge (par rapport aux statistiques d’utilisation). Ils sont habituellement

Les tests de sécurité

Ce sont des tests qui ont pour but de sécuriser l’application contre des menaces (externes ou internes) humaines ou de programmes malveillants. On teste l’authentification, la confidentialité des données, des attaques par des hackers ou des programmes. Ils sont gérés par des testeurs spécialisés.

Les tests de récupération

Si le système tombe, s’il est corrompu, s’il est attaqué, existe-t-il des procédures pour le rétablir et le remettre dans un état utilisable rapidement? Si c’est le cas, il faut relancer et tester ces procédures régulièrement pour ne pas avoir de mauvaise surprise quand un gravve problème arrivera. Ces tests sont gérés par les opérateurs système.

Les quadrants du test agile

C’est quoi Q1, Q2, Q3 et Q4 ? Cela fait référence à une classification des tests selon leur prise en charge (équipe métier ou équipe technique, sachant qu’il doivent être discutés et partagés par tout le monde) et selon le moment où ils interviennent (en cours de développement d’une story ou indépendamment des stories). Ces distinctions n’introduisent en aucune manière une notion d’ordre, par exemple les scénarios de validation sont souvent écrits avant les tests unitaires, et les tests de charge peuvent être réalisés tout au long du projet.

Les 4 types de tests sont donc:

• Quadrant 1 : Les tests qui guident le développement d’un point de vue technique
• Quadrant 2 : Les tests qui guident le développement d’un point de vue métier
• Quadrant 3 : Les tests qui critiquent le produit d’un point de vue métier
• Quadrant 2 : Les tests qui critiquent le produit d’un point de vue technique