Les tests fonctionnels
Tester en boîte noire ce que la spécification promet : cas de test, table de décision, matrice de traçabilité, cahier de recette et test d'acceptation.
- 25 cartes
- 4 thèmes
- Gratuit
Le programme, thème par thème
Le poids de chaque thème suit celui que lui donne l'examen.
- Notions
- Questions
- Ranger et relier
- Mises en situation
Quelques cartes du deck
Test fonctionnel : de quoi s'agit-il ?
Voir la réponse
Test qui vérifie qu'une fonction de l'application fait ce que la spécification promet, vu de l'extérieur.
Il part de l'exigence (« un client bloqué ne peut plus se connecter »), pas de la structure du code. Il peut donc être écrit avant le code.
Règle : remise si le client est fidèle et que le panier dépasse 100 €. Combien de colonnes compte la table de décision complète ?
- 4
- 2
- 3
- 8
Voir la réponse
4
Deux conditions vrai ou faux donnent 2 × 2 = 4 combinaisons : fidèle et grand panier, fidèle et petit panier, non fidèle et grand panier, ni l'un ni l'autre. On teste les quatre.
Un cas de test précise une …, des étapes avec leurs …, et un résultat … écrit avant l'exécution.
Voir la réponse
Un cas de test précise une précondition, des étapes avec leurs données, et un résultat attendu écrit avant l'exécution.
La précondition fixe l'état de départ (compte actif, panier vide). Les données rendent les étapes rejouables. Le résultat attendu permet de conclure.
Test en boîte noire : de quoi s'agit-il ?
Voir la réponse
Test conçu d'après la spécification seule, sans regarder le code ni sa structure interne.
Il choisit des entrées et un résultat attendu à partir des exigences. Il ne dépend pas de la façon dont le code est écrit, donc survit à un refactoring.
À la recette, le client refuse une fonction que tous les tests verts de l'équipe couvraient. Quelle est la cause la plus probable ?
- Le client a refusé sans raison, car les tests verts suffisent à prouver la conformité
- Les tests suivaient la compréhension de l'équipe, pas la spécification du client
- Il manquait des tests unitaires : il suffit d'en ajouter jusqu'à 100 % de couverture
- Les tests étaient trop lents et le client n'a pas eu le temps de les relire
Voir la réponse
Les tests suivaient la compréhension de l'équipe, pas la spécification du client
Des tests écrits d'après le code ou d'après une interprétation de l'équipe valident cette interprétation. Seuls des cas dérivés de la spécification, traçables exigence par exigence et validés avec le client, évitent l'écart.