Vérifier ou valider : faire la bonne app, et la faire bien

Imaginez : le développeur a livré à temps. Chaque ligne du cahier des charges est cochée, la recette est signée, aucun bug bloquant. Trois mois plus tard, l’app compte quelques dizaines d’utilisateurs actifs, dont la moitié travaille dans l’entreprise.

Rien n’est cassé. L’app fait exactement ce qu’on lui a demandé. Le problème, c’est qu’on ne lui a pas demandé la bonne chose.

Dans le métier, on dit qu’on a vérifié sans valider. Dans un article de 1984, l’ingénieur Barry Boehm résume la différence en deux questions restées célèbres : construisons-nous le produit correctement ? Construisons-nous le bon produit ?

Vous allez apprendre à distinguer les deux, à écrire des exigences et des critères d’acceptation qui se testent, et à organiser vérification et validation tout au long de votre projet.

Quelle est la différence entre vérifier et valider ?

La vérification compare l’app à un document. La validation la compare à la réalité. Un document peut se tromper ; la réalité, jamais.

Le tableau suivant compare les deux activités point par point.

Les deux ne demandent pas forcément de faire tourner l’app. Relire un cahier des charges pour y chercher des contradictions, c’est vérifier. Le relire avec de futurs utilisateurs pour savoir s’il décrit vraiment leur besoin, c’est déjà valider.

Pourquoi une app conforme peut-elle rater ses utilisateurs ?

Entre le besoin d’un utilisateur et le code, il y a une longue chaîne de traductions :

1. Ce dont l’utilisateur a réellement besoin.
2. Ce que le client en a compris.
3. Ce qui est écrit dans le cahier des charges.
4. Ce que le développeur a compris de ce texte.
5. Ce qui est réellement codé.

La vérification contrôle surtout le passage de l’étape 3 à l’étape 5. Si l’erreur s’est glissée entre les étapes 1 et 3, tous les tests de vérification passeront, et l’app ratera quand même sa cible. C’est le septième des principes du test logiciel : l’illusion de l’absence de défaut. Voici trois situations typiques.

Le code qui expire avant d’arriver

Le cahier des charges d’une app de paiement exige, pour la sécurité, qu’un code à usage unique (OTP, pour One-Time Password) envoyé par SMS expire au bout de 60 secondes. L’équipe le vérifie : à la 61e seconde, le code est bien refusé. Mais quand le réseau est encombré, un SMS peut mettre plus d’une minute à arriver. L’utilisateur saisit un code déjà expiré, en redemande un, se trompe, et finit bloqué. L’exigence est respectée ; le client, lui, n’a pas pu payer.

Le nom refusé à l’inscription

La règle écrite dit : « le nom contient uniquement des lettres, de 2 à 30 caractères ». Elle est codée et vérifiée à la perfection. Puis arrivent les vrais utilisateurs : un nom avec une apostrophe, un nom composé avec un trait d’union, un nom de famille en plusieurs mots qui dépasse 30 caractères. Ils ne peuvent pas s’inscrire. Personne n’avait vérifié que la règle elle-même correspondait aux noms réels.

Qu’est-ce qu’une bonne exigence ?

Une exigence décrit ce que le système doit faire, ou la façon dont il doit le faire. On en distingue deux familles :

• Les exigences fonctionnelles disent ce que fait l’app : « le client peut annuler une commande tant qu’elle n’est pas préparée ».
• Les exigences non fonctionnelles disent comment elle le fait. L’ISTQB reprend la classification de la norme ISO/IEC 25010 : performance, compatibilité, utilisabilité, fiabilité, sécurité, maintenabilité, portabilité et sûreté.

En méthode agile, on écrit souvent les exigences sous forme de user stories : « En tant que [rôle], je veux [objectif], afin de [bénéfice] ». Chaque user story est complétée par ses critères d’acceptation, que nous verrons plus bas.

Une bonne exigence est claire, sans ambiguïté et, surtout, testable. Le tableau suivant transforme des exigences vagues en exigences que l’on peut vérifier.

Les chiffres de ce tableau sont des exemples : c’est à vous de les fixer, avec vos utilisateurs et selon leurs conditions réelles.

Comment écrire des critères d’acceptation testables ?

Les critères d’acceptation sont les conditions qu’une fonctionnalité doit remplir pour être acceptée par le client et les autres parties prenantes. Ils fixent le périmètre, mettent tout le monde d’accord avant le code, décrivent les cas qui réussissent comme ceux qui échouent, et servent de base aux tests d’acceptation.

Deux formats dominent. Le premier décrit des scénarios avec la structure « Étant donné… Quand… Alors… », issue du BDD (Behaviour-Driven Development, le développement guidé par le comportement). Voici deux critères pour un transfert d’argent :

Fonctionnalité : envoyer de l'argent à un contact

  Scénario : transfert réussi
    Étant donné que mon solde est de 20 000 FCFA
    Quand j'envoie 15 000 FCFA à un contact et que je confirme avec mon code
    Alors mon solde diminue de 15 000 FCFA plus les frais affichés avant confirmation
    Et je reçois un reçu dans l'app et par SMS

  Scénario : coupure de réseau pendant la confirmation
    Étant donné que j'ai confirmé un transfert de 15 000 FCFA
    Quand le réseau coupe avant la réponse du serveur
    Alors l'app affiche « Transfert en cours de vérification »
    Et elle ne propose pas de renvoyer l'argent tant que le statut est inconnu

Ce format a un avantage : des outils comme Cucumber savent l’exécuter automatiquement, et ses mots-clés existent en français.

Le second format liste des règles :

• Le montant d’un transfert va de 100 à 500 000 FCFA.
• Les frais sont affichés avant la confirmation.
• Un transfert n’est jamais débité deux fois, même après une coupure.

Quel que soit le format, n’oubliez pas les scénarios négatifs (saisie invalide, solde insuffisant, coupure) ni les conditions réelles de vos utilisateurs : petit écran, réseau lent, interruption par un appel.

Comment vérifier, étape par étape ?

La vérification est un travail méthodique. Voici la démarche, de l’exigence à la version publiée :

1. Relisez les exigences avant le code. Cherchez les mots flous (« rapide », « simple », « etc. »), les contradictions entre deux règles et les cas oubliés : que se passe-t-il si… ?
2. Reliez chaque exigence à au moins un test. Un tableur suffit : une ligne par exigence, une colonne pour les tests qui la couvrent, une autre pour le dernier résultat. Une exigence sans test est une exigence non vérifiée.
3. Écrivez les cas de test à partir des critères d’acceptation : les cas qui réussissent, ceux qui doivent échouer, et les valeurs limites (99, 100, 500 000, 500 001 FCFA).
4. Exécutez-les et consignez chaque écart dans un rapport de bug précis.
5. Après chaque correction, vérifiez qu’elle fonctionne, puis relancez les tests de non-régression pour vous assurer que rien d’autre n’a cassé (voir smoke test, régression et recette).
6. Automatisez ce qui se répète à chaque version ; notre guide test manuel ou automatisé vous aide à choisir.

Comment valider en mettant l’app face à la réalité ?

La validation ne se fait pas en une fois, à la fin. Elle accompagne tout le projet.

• Avant le code, parlez à de futurs utilisateurs et observez-les. Comment un commerçant prend-il ses commandes aujourd’hui ? Sur un cahier, par WhatsApp, au téléphone ? Votre app doit faire mieux que ça, pas seulement autrement.
• Sur les maquettes, faites parcourir un prototype cliquable à cinq personnes. Selon le modèle de Jakob Nielsen (Nielsen Norman Group), cinq utilisateurs révèlent environ 85 % des problèmes d’utilisabilité d’une version ; il recommande plusieurs petites séries de tests plutôt qu’une grande.
• Sur l’app, menez un test d’acceptation. L’ISTQB rappelle qu’il porte sur la validation et qu’il devrait idéalement être réalisé par les utilisateurs visés. Faites-le donc sur leurs propres téléphones, avec leur réseau et dans leur langue. Un test fermé sur Google Play ou une bêta prolonge cet effort.
• Après la publication, écoutez : avis sur le store, messages au support, et surtout les étapes où les utilisateurs abandonnent.

Pour structurer ces séances, suivez notre guide pour organiser un test utilisateur, puis mesurez le résultat avec le questionnaire SUS. C’est aussi là que des testeurs extérieurs, comme ceux de GeekTest, apportent le plus : ils découvrent l’app sans contexte, sur leurs propres appareils et leur propre réseau.

Comment organiser vérification et validation dans votre projet ?

Le tableau suivant montre, phase par phase, ce que vous pouvez vérifier et ce que vous pouvez valider.

Avant de déclarer une fonctionnalité « terminée », passez cette liste.

Vérifier, votre équipe sait souvent le faire. Valider demande des yeux neufs et de vrais appareils : c’est souvent l’étape que l’on saute, et c’est pourtant elle qui fait la différence le jour de la publication. Nos tarifs vous montrent comment la confier à des testeurs réels.

Pour aller plus loin

• Syllabus ISTQB Niveau Fondation v4.0, en français (CFTL) (nouvel onglet) : vérification et validation (section 1.1), l’illusion de l’absence de défaut (section 1.3), le test d’acceptation (section 2.2.1) et les critères d’acceptation (section 4.5.2).
• Barry W. Boehm, « Verifying and Validating Software Requirements and Design Specifications », IEEE Software, 1984 (nouvel onglet) (en anglais) : l’article qui oppose « le bon produit » et « le produit fait correctement ».
• Référence Gherkin de Cucumber (nouvel onglet) (en anglais) : la syntaxe Étant donné / Quand / Alors et sa traduction dans de nombreuses langues, dont le français.
• Nielsen Norman Group : pourquoi tester avec 5 utilisateurs (nouvel onglet) (en anglais) : le modèle de Jakob Nielsen et ses limites.