# Choisir quoi tester quand le délai ne permet pas de tout couvrir > Une méthode de priorisation par risque pour décider quels tests écrire en premier, quand le calendrier ne laisse pas la place à une couverture exhaustive. - Auteur : WordPress Développement - Publié le : 2023-07-11 - Mis à jour le : 2023-07-11 - Catégorie : Tests - URL : https://www.wpmoderne.fr/tests/choisir-quoi-tester-delai-priorisation-risque/ ## L’essentiel - Croiser probabilité de régression et gravité de l'impact - Tester en priorité ce qui touche à l'argent et aux données personnelles - Accepter explicitement ce qui reste non testé Quels tests écrire en priorité quand il ne reste que quatre heures avant une mise en ligne déjà repoussée deux fois ? Cette question, posée un vendredi après-midi sur un projet de plateforme de réservation de créneaux pour un cabinet de kinésithérapie, ne trouve pas de bonne réponse dans une liste de bonnes pratiques générale : elle demande une méthode de priorisation rapide, applicable en quelques minutes. La tentation naturelle est de tester ce qui est le plus simple à tester, ou ce qui vient d'être développé. Ces deux critères ignorent complètement ce qui compte vraiment : la probabilité qu'un bug survienne, et la gravité de ses conséquences s'il survient. ## La grille de priorisation en deux axes > L'essentiel à retenir : Croiser probabilité de régression et gravité de l'impact ; Tester en priorité ce qui touche à l'argent et aux données personnelles ; Accepter explicitement ce qui reste non testé Chaque fonctionnalité candidate à un test est évaluée sur deux axes indépendants, notés simplement de 1 à 3 : - **Probabilité de régression** : le code est-il récent, complexe, modifié souvent, ou touché par plusieurs développeurs récemment ? Un code stable depuis des mois, jamais modifié, obtient un score bas même s'il est important. - **Gravité de l'impact** : une régression sur cette fonctionnalité affecte-t-elle de l'argent, des données personnelles, ou simplement un affichage esthétique ? Un bug d'affichage sur une page secondaire pèse peu ; un bug qui double-facture un créneau pèse énormément. Le produit des deux scores donne un ordre de priorité clair, sans ambiguïté sur ce qu'il faut traiter en premier : ``` Fonctionnalité Probabilité Gravité Priorité Calcul du prix selon durée de séance 3 3 9 Annulation d'un rendez-vous 2 3 6 Affichage du planning du praticien 2 2 4 Envoi de l'e-mail de confirmation 1 2 2 Mise en forme du pied de page 1 1 1 ``` ## Appliquer la grille avec quatre heures devant soi Sur ce projet, la grille a désigné sans hésiter le calcul du prix selon la durée de séance comme priorité absolue : il venait d'être modifié pour gérer des tarifs dégressifs, touchait directement à la facturation du client final, et n'avait encore jamais été testé automatiquement. Deux tests ont suffi à couvrir les cas limites les plus risqués (durée à zéro, tarif dégressif au seuil exact). L'annulation de rendez-vous, deuxième priorité, a reçu un seul test ciblé sur le remboursement partiel, cas identifié comme le plus probable à mal fonctionner compte tenu d'un changement récent de logique métier. ## Ce qui reste volontairement non testé La grille sert aussi à assumer, par écrit, ce qui ne sera pas testé dans le temps imparti. Sur ce projet, l'affichage du planning et l'envoi d'e-mail de confirmation ont été laissés sans nouveau test, avec une note explicite dans le ticket de suivi précisant la raison du choix et le risque accepté. > Ne pas tester une fonctionnalité par manque de temps est un choix ; ne pas savoir qu'on l'a fait est un risque. ## Les limites de cette méthode Cette grille fonctionne bien pour une décision ponctuelle sous contrainte de délai, mais elle ne remplace pas une stratégie de couverture construite sur la durée. Utilisée systématiquement comme seule boussole de test, elle finit par ne jamais couvrir les fonctionnalités jugées secondaires, qui peuvent pourtant accumuler une dette de tests significative au fil des mois — un sujet à part entière, distinct de la priorisation ponctuelle traitée ici. ### Un biais à surveiller La probabilité de régression est souvent sous-estimée pour du code ancien jamais retouché : un changement de version PHP ou WordPress peut réveiller un bug latent dans une fonctionnalité considérée à tort comme stable. La grille doit être révisée chaque fois qu'une dépendance externe change, pas seulement quand le code du projet change. ## En résumé Face à un délai contraint, croiser probabilité de régression et gravité d'impact permet de décider en quelques minutes ce qui mérite un test immédiat, et de documenter explicitement ce qui reste un risque assumé. Sur ce projet, les deux tests écrits en urgence ont effectivement révélé un bug réel sur le tarif dégressif, corrigé avant la mise en ligne repoussée une troisième fois de quelques heures seulement.