🧪 5.1 Vérifier les exigences fonctionnelles d'une application mobile

Une application mobile ne peut pas être considérée comme "terminée" uniquement parce qu'elle se lance ou qu'elle fonctionne sur le téléphone du développeur.

Avant toute publication (et même tout au long du développement), il est indispensable de vérifier que les fonctionnalités répondent réellement aux besoins attendus.

Ce chapitre se concentre sur la vérification des exigences fonctionnelles, c'est-à-dire sur la question essentielle :

Est-ce que l'application fait correctement ce qu'elle est censée faire ?

🎯 Objectifs d'apprentissage

À la fin de ce chapitre, vous serez capables de :

• expliquer pourquoi les tests fonctionnels sont indispensables dans un projet mobile ;
• définir ce qu'est une exigence fonctionnelle ;
• distinguer les principaux types de tests fonctionnels sur mobile ;
• rédiger un cas de test fonctionnel clair et reproductible ;
• exécuter un test et analyser son résultat ;
• identifier et décrire un bug fonctionnel de manière structurée ;
• comprendre le rôle des tests de régression dans la qualité d'une application mobile.

🤔 5.1.1 Pourquoi tester les exigences fonctionnelles ?

Dans un contexte de développement mobile, il est très courant d'entendre des phrases comme :

"Bah moi ça marche sur mon téléphone ! ☝️🤓"

Mais ce constat est largement insuffisant.

Une application mobile est utilisée :

• sur des appareils différents (tailles, performances, OS...) ;
• dans des conditions variées (déplacement, luminosité, réseau...) ;
• par des utilisateurs qui n'ont pas participé au développement (attentes et expertises diverses).

Conséquences d’un bug fonctionnel

Un bug fonctionnel peut avoir des conséquences immédiates :

• frustration de l'utilisateur ;
• abandon de l'application ;
• avis négatif sur le store ;
• perte de crédibilité ;
• risque de rejet par les stores lors de la validation.

Sur mobile, ces effets sont amplifiés :

• les utilisateurs désinstallent rapidement une application qui ne fonctionne pas comme prévu.

Tester les exigences fonctionnelles permet donc de :

• détecter les erreurs avant qu'elles n'atteignent les utilisateurs finaux ;
• réduire fortement les risques après publication.

🧾 5.1.2 Qu'est-ce qu'une exigence fonctionnelle ?

Une exigence fonctionnelle décrit une action que l'utilisateur doit pouvoir réaliser dans l'application.

Elle exprime un besoin concret, du point de vue de l'utilisateur, et non du développeur.

Exemples :

• l'utilisateur peut créer un compte ;
• l'utilisateur peut se connecter ;
• l'utilisateur peut ajouter un élément à une liste ;
• l'utilisateur peut supprimer une donnée ;
• l'utilisateur peut consulter une information.

Exigence fonctionnelle = testable

🚨 Important :

Chaque exigence fonctionnelle doit pouvoir être :

• comprise clairement ;
• testée ;
• validée ou refusée.

Il existe un lien direct entre :

• une exigence fonctionnelle (ce que l'application doit faire) ;
• la fonctionnalité correspondante dans l'application (le code) ;
• un ou plusieurs tests fonctionnels (les vérifications associées).

Sans exigence clairement identifiée, il est impossible de tester correctement.

🧪 5.1.3 Types de tests fonctionnels sur mobile

Dans le cadre de ce module, les tests fonctionnels sont principalement manuels.

Ils consistent à utiliser l'application comme le ferait un utilisateur, en suivant des scénarios précis.

On distingue notamment :

• Tests manuels dirigés → on suit un cas de test précis.

• Tests exploratoires → on explore l'application de manière plus libre, pour détecter des comportements inattendus.

• Tests de régression → réalisés après une correction pour vérifier que les fonctionnalités existantes fonctionnent toujours.

Où tester ? Émulateur vs appareil réel

Les tests peuvent être réalisés :

• sur un émulateur

  • rapide et pratique ;
  • utile pour les premiers tests ;
  • certaines limites (capteurs, performances, ressenti).

• sur un appareil réel

  • indispensable pour valider le comportement réel ;
  • nécessaire pour les APIs natives et les conditions d’usage réelles.

👉 Sur mobile, tester sur un appareil réel est toujours recommandé avant publication.

📝 5.1.4 Rédiger un cas de test fonctionnel

Un cas de test décrit précisément comment vérifier une exigence fonctionnelle.

Il doit être suffisamment clair pour que n'importe quelle personne puisse l'exécuter et obtenir le même résultat.

Un cas de test fonctionnel contient généralement :

• un identifiant unique ou un titre ;
• des préconditions (état initial de l'application) ;
• une suite d'étapes à effectuer ;
• un résultat attendu.

Exemple simplifié – Test de connexion

Exigence : l’utilisateur peut se connecter avec un compte valide.

Préconditions :

• l'utilisateur possède un compte valide.

Étapes :

1. ouvrir l'application ;
2. saisir l'email et le mot de passe ;
3. appuyer sur "Se connecter".

Résultat attendu :

• l'utilisateur accède à l'écran principal.

Caractéristiques d’un bon cas de test

Un bon cas de test est :

• précis

  • pas d’ambiguïté dans les actions à effectuer ;

• compréhensible

  • toute personne non développeuse peut l'exécuter ;

• reproductible

  • deux personnes différentes obtiennent le même résultat dans les mêmes conditions.

▶️ 5.1.5 Exécuter les tests et observer les résultats

Exécuter un test = suivre exactement les étapes décrites dans le cas de test, puis observer le comportement réel.

À l’issue de l’exécution, le résultat peut être :

• ✅ Conforme

  • le résultat observé correspond au résultat attendu.

• ❌ Non conforme

  • le comportement diffère de ce qui est attendu.

Il est important de noter les observations, même si le test est réussi.

En cas d’échec : collecter des éléments

En cas de test non conforme, il est utile de collecter :

• une description du problème ;
• une capture d'écran (ou vidéo courte) ;
• le contexte d’utilisation (appareil, version, réseau, etc.).

👉 Ces informations seront précieuses pour :

• comprendre le bug ;
• le reproduire ;
• le corriger.

🐞 5.1.6 Identifier, décrire et corriger un bug fonctionnel

Un bug fonctionnel apparaît lorsqu'une exigence n'est pas respectée.

Pour qu'un bug puisse être corrigé efficacement, il doit être décrit clairement.

Exemple de mauvais rapport de bug

⛔ "L'app ne marche pas quand je clique sur le bouton de connexion."

Problèmes :

• pas de contexte (appareil, version...) ;

• pas d'étapes précises → impossible de reproduire ;

• pas de résultat attendu exprimé ;

• "ne marche pas" peut vouloir dire :

  • crash,
  • message d'erreur,
  • rien ne se passe,
  • ou autre chose.

(et en plus, elle n'a pas de jambes)

Exemple de bon rapport de bug

☝️🤓 "Sur un iPhone 12 avec la version 1.0.0 de l'application, lorsque je clique sur le bouton de connexion après avoir saisi mes identifiants, rien ne se passe : la page reste statique. J'attendais à être redirigé vers l'écran principal."

Ce rapport contient :

• un contexte précis

  • iPhone 12, version 1.0.0 ;

• des étapes claires

  • cliquer sur le bouton après saisie des identifiants ;

• le résultat observé

  • rien ne se passe, écran statique ;

• le résultat attendu

  • redirection vers l’écran principal.

Après correction : re-tester

Une fois le bug corrigé :

• le test correspondant doit être rejoué ;

• on vérifie que :

  • la correction fonctionne ;
  • aucune autre fonctionnalité n’a été impactée.

Cycle fondamental :

test → bug → correction → re-test

🔄 5.1.7 Tests de régression

Corriger un bug peut parfois en créer un autre.

Les tests de régression consistent à rejouer des tests existants après une modification du code.

Sur une application mobile, il est particulièrement important de re-tester :

• les fonctionnalités principales ;

• les parcours utilisateurs critiques :

  • connexion,
  • inscription,
  • sauvegarde,
  • navigation.

Même une petite modification peut avoir un impact inattendu ailleurs.

🥥 Anecdote – La noix de coco de Team Fortress 2

Un utilisateur a décompilé des fichiers du jeu Team Fortress 2 et a découvert une image de noix de coco dans les assets.

En essayant de la supprimer, il constate que le jeu ne se lance plus sans ce fichier.

• Easter egg ?
• bug de régression ?
• simple vérification d'intégrité des fichiers ?

Personne n’est 100 % certain, mais cela illustre bien :

une petite modification peut avoir des conséquences inattendues.

"I have no f**** idea who put this here, but when I deleted it the game wouldn’t start. Words cannot describe my f**** confusion."*

🧠 5.1.8 Bonnes pratiques de test fonctionnel

Quelques principes essentiels :

• tester le plus tôt possible, pas uniquement à la fin ;
• tester les cas normaux et les cas limites ;
• documenter les tests, même lorsqu'ils réussissent ;
• tester sur appareil réel avant publication ;
• rejouer régulièrement les tests critiques (régression).

Les tests fonctionnels sont une étape clé de la qualité logicielle, et non une contrainte inutile.

🧪 5.1.9 Activité pratique – Tests fonctionnels

À partir d’une application mobile donnée (réelle ou fictive), vous devez :

• identifier 3 à 5 exigences fonctionnelles ;
• rédiger les cas de test correspondants ;
• simuler l’exécution des tests ;
• identifier d’éventuels problèmes ;
• proposer des corrections.

Ce travail peut être réalisé :

• individuellement ;
• ou en binôme.

🔗 Sources et références

• Android Developers – Testing apps
• Apple Developer – Testing your app
• ISTQB – Glossaire des tests logiciels