Périmètre et limites du système
Objectifs pédagogiques
À la fin de cette section, vous serez capable de :
- définir le périmètre de test
- distinguer ce qui est inclus et exclu
- comprendre l’impact des limites sur la stratégie de test
Qu’est-ce que le périmètre de test ?
Le périmètre de test définit ce qui sera testé dans l’application.
Il permet de :
- cadrer les efforts de test
- éviter les malentendus
- gérer les attentes des parties prenantes
Les objets à tester ou périmètre de test sont souvent les composants individuels de l'application qui doivent être évalués pour s'assurer de leur bon fonctionnement. Cela peut inclure des fonctionnalités spécifiques, des modules de code, des interfaces utilisateur, etc.
Éléments inclus dans le périmètre
Exemples :
- fonctionnalités principales
- modules critiques
- interfaces utilisateur
- API internes ou externes
- scénarios utilisateurs clés
Autres exemples :
- La fonction de recherche dans une application de commerce électronique.
- Le processus d'inscription des utilisateurs dans une application de réseautage social
Éléments exclus du périmètre
Exemples :
- fonctionnalités non terminées
- modules en cours de développement
- systèmes tiers hors responsabilité
- configurations matérielles non supportées
👉 Les exclusions doivent toujours être justifiées.
Pourquoi définir les limites ?
Sans limites claires :
- les tests deviennent infinis
- les priorités sont floues
- les ressources sont mal utilisées
Avec des limites définies :
- les tests sont ciblés
- les risques sont maîtrisés
- les décisions sont explicites
Exemple concret – Périmètre de test pour MyEvents
Reprenons notre application fil rouge MyEvents
, une plateforme web et mobile permettant :
- la création et la gestion d’événements
- l’achat et la réservation de billets
- l’envoi de notifications (e-mail / SMS)
- l’intégration avec des services externes (paiement, géolocalisation)
➡️ Voir la description détaillée de l’application MyEvents
Objectif du périmètre dans ce contexte
L’objectif est de délimiter clairement ce qui sera testé dans MyEvents
afin de concentrer les efforts sur les fonctionnalités critiques pour les utilisateurs et le métier.
Éléments inclus dans le périmètre – MyEvents
Dans le cadre de ce projet, les éléments inclus dans le périmètre de test sont :
Fonctionnalités principales
- création, modification et suppression d’événements
- affichage de la liste des événements
- achat et réservation de billets
- gestion du compte utilisateur
- affichage des billets dans l’espace personnel
Intégrations critiques
- intégration avec l’API de paiement (paiement accepté / refusé)
- envoi d’e-mails de confirmation
- communication avec la base de données utilisateur
Interfaces testées
- interface web (navigateurs récents)
- API backend (tests fonctionnels et d’intégration)
👉 Ces éléments sont essentiels au bon fonctionnement de l’application
et présentent un fort risque métier en cas de défaut.
Éléments exclus du périmètre – MyEvents
Les éléments suivants sont explicitement exclus du périmètre de test :
- fonctionnement interne des services tiers
(ex. : Stripe, PayPal, Twilio) - tests de performance extrême (millions d’utilisateurs simultanés)
- compatibilité avec des navigateurs obsolètes
- aspects graphiques très fins (alignement pixel-perfect)
- infrastructure serveur (configuration réseau, firewall, etc.)
👉 Ces exclusions sont faites car : - elles ne sont pas sous la responsabilité directe de l’équipe - ou leur coût de test est disproportionné par rapport au risque
Impact des limites sur la stratégie de test
Le périmètre défini pour MyEvents a un impact direct sur :
- les priorités de test
(paiement > création d’événement > design) - les types de test choisis
(tests fonctionnels, tests d’intégration API) - le niveau d’automatisation
(automatisation prioritaire des paiements et API) - la gestion des risques
(perte financière, données incohérentes, insatisfaction utilisateur)
👉 Le périmètre oriente la stratégie de test
et permet de faire des choix réalistes et assumés.
À retenir avec MyEvents
- le périmètre définit où s’arrête la responsabilité de test
- tout ce qui n’est pas explicitement inclus est considéré comme hors périmètre
- un périmètre clair évite les conflits et les malentendus
- il est toujours lié au contexte du projet