Qu'est-ce que le test de fonctionnalités ?
Le test de fonctionnalités (feature testing) consiste à vérifier qu'une fonction précise d'un produit logiciel, comme la recherche, le paiement ou un nouveau bouton d'export, fait ce que ses exigences prévoient, de bout en bout, avant et après la mise en production. Il couvre le cas nominal, les saisies invalides, les droits d'accès et l'interaction avec le reste du produit. Il est plus ciblé qu'un test de toute l'application et plus large qu'un test unitaire.
Comment ça se passe
- Notez ce que la fonction doit faire : critères d'acceptation, entrées, sorties, rôles autorisés.
- Déduisez des cas de test : usage normal, valeurs limites, saisies erronées, droits manquants, actions interrompues.
- Exécutez-les sur une version dans un environnement de test, d'abord à la main, puis automatisés pour ceux qui se répètent.
- Vérifiez les voisines : les autres fonctions qui partagent des données ou des écrans avec elle.
- Corrigez, retestez et gardez les cas utiles sous forme de suite automatisée.
Ce que couvre un test de fonctionnalité
- Fonctionnement : elle se comporte comme spécifié, y compris messages d'erreur et états vides.
- Intégration : elle fonctionne avec la base de données, le prestataire de paiement ou les autres services appelés. Pour les interfaces HTTP, voir les tests d'API.
- Utilisabilité et accessibilité : on peut l'utiliser, aussi au clavier et avec des technologies d'assistance. Voir les tests d'accessibilité automatisés et les tests manuels d'accessibilité.
- Performance : elle reste acceptable sous une charge réaliste. Une fonction qui réussit les tests fonctionnels peut être trop lente avec beaucoup d'utilisateurs simultanés.
- Bases de sécurité : contrôles d'autorisation et traitement des saisies pour cette fonction.
Un exemple simple
Une équipe ajoute « exporter les résultats en CSV ». Les tests vérifient que le fichier s'ouvre avec les bonnes colonnes, qu'un résultat vide affiche un message clair, qu'un utilisateur en lecture seule ne peut pas exporter ce qu'il ne peut pas voir, que les caractères spéciaux sont préservés et qu'un export de 100 000 lignes aboutit au lieu d'expirer. L'export est ensuite retesté à chaque modification de la page de résultats : c'est le test de non-régression.
Tests de fonctionnalités, mise en production et suivi
Les équipes livrent souvent une fonction derrière un interrupteur pour la tester sans risque avec du trafic réel : voir les feature flags et le déploiement progressif de fonctionnalités. Après la mise en ligne, des contrôles automatiques continuent de la surveiller. La surveillance d'API de LoadFocus peut appeler les points d'accès de la fonction à intervalle régulier et alerter en cas d'échec, et les tests de charge montrent son comportement avec beaucoup d'utilisateurs simultanés. Pour un exemple de ralentissement repéré entre deux versions, lisez détecter une régression de performance avec des tests automatisés (en anglais).
Erreurs courantes
- Ne tester que le cas nominal.
- Ne pas écrire de critères d'acceptation : personne ne peut dire ce que « ça marche » veut dire.
- Tester la fonction seule et manquer ce qu'elle casse ailleurs.
- Laisser performance et accessibilité pour après le lancement.
- Compter sur des retests manuels pour ce qui change à chaque version.
Questions fréquentes
Quelle différence entre test de fonctionnalités et test fonctionnel ?
Le test fonctionnel vérifie que le logiciel fait ce que prévoient les exigences. Le test de fonctionnalités l'applique à une fonction nommée à la fois. En pratique, les deux termes se recoupent largement.
Le test de fonctionnalités est-il la même chose que le test de non-régression ?
Non. Le premier vérifie qu'une fonction marche comme spécifié. Le second rejoue des tests existants après une modification pour confirmer que rien de ce qui marchait n'est cassé.
Faut-il des tests manuels ou automatisés ?
Les deux. Explorez à la main tant que la fonction est nouvelle et floue, puis automatisez les cas que vous rejouerez à chaque version.
Qui écrit les tests de fonctionnalités ?
Cela varie : les développeurs écrivent les tests unitaires et d'intégration, l'assurance qualité les cas de bout en bout, et le responsable produit fournit les critères d'acceptation. L'essentiel est que les critères existent avant de tester.
Est-ce la même chose que l'A/B testing ?
Non. Le test de fonctionnalités vérifie qu'une fonction marche. L'A/B testing compare deux variantes auprès de vrais utilisateurs pour voir laquelle performe le mieux sur une métrique.
Termes associés
Outils LoadFocus connexes
Mettez ce concept en pratique avec LoadFocus, la plateforme même qui propulse tout ce que vous venez de lire.