Aller au contenu
UFR Ingémedia
Retour au dossier

Phase de test

Tests, recette et validation du projet

Réf.
Module 06 / 11
Postes
2
Contrôle
9 questions
État
—

Tests par l'équipe projet

Les tests sont cruciaux pour livrer un produit de qualité.

Histoire vraie : Le bug à 440 millions de dollars

En 2012, Knight Capital, une société de trading, déploie une mise à jour logicielle sans tests suffisants. En 45 minutes, un bug dans l'algorithme génère des ordres d'achat involontaires pour un montant de 440 millions de dollars de pertes. L'entreprise fait faillite quelques jours plus tard. Un simple test de non-régression aurait pu éviter cette catastrophe.

Histoire vraie : Cyberpunk 2077, le jeu retiré du PlayStation Store

Décembre 2020 : CD Projekt sort Cyberpunk 2077 après 8 ans de développement et trois reports. Sur PS4 et Xbox One, le jeu plante, les textures ne chargent pas, les personnages traversent les murs. En une semaine, Sony retire le jeu de son store et rembourse les joueurs, une première pour un titre de cette taille. L'action de l'entreprise perd plus de 40 % de sa valeur. Les enquêtes révéleront que la direction connaissait l'état du jeu sur anciennes consoles mais a maintenu la date pour Noël, et que les testeurs n'avaient eu que quelques jours sur la version console. La leçon pour un chef de projet web : tester sur les « vieilles » configurations (Android d'entrée de gamme, Safari sur un iPhone de 2019, connexion 3G) n'est pas un luxe, c'est là que vos utilisateurs réels se trouvent. Et une date tenue avec un produit cassé coûte plus cher qu'un report.

×100
Coût d'un bug en production vs en développement
15-20%
du budget dev à allouer aux tests
80%
des bugs critiques détectables par des tests automatisés

Types de tests

1. Tests unitaires

  • Tester chaque fonction isolément
  • Automatisés
  • Rapides à exécuter
Outils : Jest, Mocha, PHPUnit

2. Tests d'intégration

  • Tester les interactions entre composants
  • Vérifier que les modules fonctionnent ensemble

3. Tests fonctionnels

  • Tester les fonctionnalités end-to-end
  • Simuler le comportement utilisateur
Outils : Cypress, Selenium, Playwright

4. Tests de performance

  • Temps de chargement
  • Charge serveur
  • Optimisation
Outils : Lighthouse, GTmetrix, WebPageTest

5. Tests de sécurité

  • Injection SQL
  • XSS (Cross-Site Scripting)
  • CSRF
  • Authentification
Outils : OWASP ZAP, Burp Suite

6. Tests d'accessibilité

  • Conformité WCAG
  • Navigation au clavier
  • Lecteurs d'écran
Outils : axe DevTools, WAVE

7. Tests de compatibilité

  • Navigateurs (Chrome, Firefox, Safari, Edge)
  • Devices (desktop, mobile, tablette)
  • Systèmes d'exploitation

Stratégie de tests - Pyramide

Pyramide des tests :

Haut : E2E (Peu de tests - lents, coûteux)
Milieu : Intégration (Tests modérés)
Base : Unitaires (Beaucoup de tests - rapides)

Mini-défi 30 secondes : casse ce formulaire d'inscription

Un formulaire demande un e-mail, un mot de passe et une date de naissance. Trouve cinq façons de le faire planter avant de lire la suite.

Quelques réponses de testeurs aguerris : un e-mail sans « @ » ; un mot de passe d'un seul caractère ; une date de naissance en 2031 ; un double-clic rapide sur « Valider » qui crée deux comptes ; un prénom de 500 caractères copié-collé ; l'apostrophe dans « O'Connor » qui casse une requête SQL ; le bouton « Retour » du navigateur après validation. Chaque cas devient une ligne du plan de tests. Un bon testeur ne vérifie pas que ça marche quand on fait tout bien : il vérifie que ça ne casse pas quand on fait n'importe quoi, parce que les utilisateurs feront n'importe quoi.

Checklist de tests

Fonctionnel

  • Toutes les fonctionnalités marchent
  • Formulaires validés
  • Navigation fluide
  • Liens fonctionnels

Performance

  • Temps de chargement < 3s
  • Images optimisées
  • Cache configuré

Sécurité

  • HTTPS activé
  • Formulaires protégés
  • Mots de passe hashés

SEO

  • Balises meta
  • Sitemap.xml
  • URLs propres

Responsive

  • Mobile-friendly
  • Tablette OK
  • Desktop OK

Combien de tests, à quel étage ?

Pyramide animée · ≈ 2 min

Le socle est fixé à 200 tests unitaires. Ajoutez des tests de bout-en-bout et regardez le temps du pipeline s’allonger.

Bout-en-bout (E2E) ×8

75 s chacun · un navigateur qui clique comme un humain

Intégration ×40

0,75 s chacun · plusieurs briques ensemble, sans navigateur

Unitaires ×200

10 ms chacun · une fonction, une règle, un cas

Durée du pipeline

11 min

Maintenance des tests

62 h / mois

Pipeline rapide : les tests tournent à chaque modification, les régressions sont attrapées dans la minute. C’est la forme d’une pyramide, pas d’un cornet de glace.
Copie jaune · Cas pratique

Plan de tests

Élaborer un plan de tests complet

Projet : Application de réservation en ligne

Fonctionnalités à tester :

  1. Création de compte utilisateur
  2. Connexion/déconnexion
  3. Recherche de disponibilités
  4. Réservation avec paiement
  5. Confirmation par email
  6. Espace client (historique)

Votre mission :

  1. Créez une checklist de tests pour chaque fonctionnalité
  2. Identifiez les cas limites (edge cases) à tester
  3. Proposez 5 scénarios de tests end-to-end
  4. Listez les outils que vous utiliseriez
Correction sur le feuillet rose, réservée à l’enseignant. Elle sera commentée en cours.

Contrôle du poste

Tests par l'équipe projet

7 questions

  1. Q01Moyen

    Quel type de test est le plus rapide à exécuter ?

  2. Q02Facile

    Qu'est-ce que la recette client (UAT) ?

  3. Q03Moyen

    Comment classe-t-on généralement les bugs ?

  4. Q04Facile

    Quel outil est recommandé pour tester les performances d'un site ?

  5. Q05Facile

    Qu'est-ce qu'un PV de recette ?

  6. Q06MoyenScénario
    Un développeur vous dit : « J'ai testé le tunnel de paiement, ça marche. »

    Que demandez-vous avant de passer le ticket en « validé » ?

  7. Q07FacileTexte à trous

    Un test de …__ vérifie qu'une correction n'a pas cassé une fonctionnalité qui marchait avant.

Répondez à toutes les questions pour voir la correction.