Le rôle de cet article est de montrer, par une analogie éprouvée, l’importance des tests d’acceptation mais surtout la différence entre les tests système et les tests d’acceptation.
Pour rappel, tests système et tests d’acceptation sont des niveaux de test.
Le contexte:
Le client, un commerçant spécialisé dans la vente de souvenirs aux touristes. Dans ce cadre je souhaite étoffer mon offre et proposer des puzzles dont voici les caractéristiques:
- Il veut un puzzle représentant une pyramide car c’est le monument qui a le plus de succès auprès des touristes
- Le puzzle doit être constitué de 100 pièces
- Le puzzle doit être en couleur
- L’image doit être nette (résolution supérieure ou égale à 2048*1536)
- La longueur du puzzle doit être de 70 cm
- Le puzzle doit être en carton renforcé par du plastique pour assurer une résistance des pièces
Les tests de composants (souvent unitaires):
- Les pièces du puzzle sont-elles:
- De la bonne taille
- Avec le bon dpi (bon nombre de pixels)
- Avec le bon matériau
Les tests d’intégrations:
- Chaque pièce a-t-elle sa place
- Chaque pièce s’emboite t-elle correctement avec ses voisines
- L’image est-elle bien continue entre chaque pièce?
Les tests systèmes (vérification des spécifications):
- L’image représente t-elle bien une pyramide ?
- Le nombre de pièces est-il le bon ?
- La taille totale du puzzle est-elle la bonne ?
- Le puzzle est-il en couleur ?
Tests d’acceptation:
Le puzzle proposé ne satisfait aucunement le client. En effet, le client n’est pas localisé en Égypte mais au Mexique!
Le puzzle n’est donc pas vendable et ne correspond pas au besoin du client
Conclusion:
Comme nous venons de le voir avec cet exemple, répondre aux spécifications ne veut pas dire répondre au besoin. Il y a une nette différence entre tests d’acceptation et tests systèmes et j’espère que cet exemple vous permettra de ne plus les confondre mais aussi de bien expliquer leurs différences à des non-testeurs.
N’hésitez pas à rejoindre le groupe Le métier du test
N’hésitez pas à me suivre et lire mes autres articles si vous voulez en apprendre plus sur le test ou venir partager vos connaissances
Merci à tous ceux qui mettent « j’aime », partagent ou commentent mes articles.
5 réponses
1- Comment en tant que testeur, peut-on se rassurer de la conformités des tests unitaires et d’intégration ou c’est juste une question de confiance??
2- Dans l’illustration présenté dans l’article, est-ce que le client ne devait pas spécifier la Piramide du mexique pour éviter la confusion?? (Ceci dit, très bon article qui permet de bien comprendre les choses)
Bonjour Jerry,
1- oui la plupart du temps il faut faire confiance au développeur même si certains testeurs arrivent à aller jusqu’au test d’intégration voir les tests unitaire
2- Il y a eu une incompréhension. Le client aurait du spécifier le type de pyramide mais le prestataire aurait également dû demander une confirmation. En fait, le vrai problème ici est le manque de communication… Un problème auquel l’agilité est censé répondre
Bonjour,
Je trouve l’exemple sur les niveaux de tests très bien illustré. Cependant, j’ai une question qui me revient régulièrement à l’esprit : Si les testeurs se basent sur les exigences mentionnés dans les spécifications fonctionnelles « SFDT » (stroy, cas d’usage, …) pour concevoir leurs cas de tests fonctionnels et vérifier l’exactitude et la complétudes des différentes fonctionnalités, sur quoi se basent, les gens de la recette/métier pour concevoir et dérouler leurs tests d’acceptance ? Autrement dit, une fonctionnalité/un cas d’usage peut être vérifié à la fois par un test système de bout-en bout (pour s’assurer de la bonne communication et interaction entre les différents composants/sous système entrant en jeu lors du déroulement du cas d’usage), comme il peut être vérifié par un test d’acceptance.
Est-ce les personnes de la recette/métier, ont un référentiel des exigences différent de celui auquel les testeurs ont accès pour vérifier le produit ?
J’ai l’impression que les tests d’acceptance se concentrent uniquement sur l’aspect visuel/graphique uniquement (tailles des composants, responsivité de l’écran) ou parfois de l’expérience utilisateur (car souvent, on découvre des aspects à améliorer lors de la phase de la recette métier qui font l’objet d’une demande de changement au cours des prochains developpement) et donc les tests d’acceptance ne se basent pas forcément sur les exigences/spécifications fonctionnelles, sinon ça sera une réexécution des tests systèmes autrement dit.
Bonjour Wassim,
merci pour ce retour.
Pour les tests d’acceptation les métiers se basent sur leur besoin (ou le besoin des personnes qu’ils représentent). Cela peut être documenté en partie mais la majorité des besoins restent implicites. C’est d’ailleurs pour cela qu’il est si compliqué d’automatiser des tests d’acceptation.
Ces tests vont en effet avoir beaucoup de retours sur l’interface utilisateur (avec de l’UX par exemple) mais pas seulement. Il peut avoir des retours sur la performance (trop lent), la robustesse (des problèmes suite à des erreurs), une mauvaise gestion des erreurs ou encore des incohérences fonctionnelles. Dans la très grande majorité des cas, on est sur des tests boîte noire ou basés sur l’expérience.