Trouver les erreurs. Avant vos clients.

Des risques métier à une couverture de tests justifiée

Un grand nombre de tests réussis n'a que peu de valeur si le cas métier décisif fait défaut. Nous mettons en correspondance les exigences, les risques et les vérifications. Pour un circuit de validation, cela inclut par exemple les changements de rôle non autorisés, le traitement en parallèle et les délais expirés. Des analyses aux valeurs limites et diverses combinaisons de saisies complètent les cas de succès habituels. Les résultats attendus sont justifiés sur le plan métier, plutôt que de se contenter de figer le comportement actuel du programme.

Pour chaque règle importante, nous choisissons le niveau approprié. De petits tests isolés vérifient rapidement les calculs ; les tests d'intégration vérifient l'interaction avec la base de données ou le service ; quelques tests de bout en bout ciblés sécurisent les processus complets. Les doublures de test simplifient les vérifications, mais peuvent donner une image erronée du véritable partenaire. C'est pourquoi il est précisé quelles hypothèses doivent en outre être démontrées sur des systèmes de test réels.

Données de test, tests instables et pipelines pertinents

Un test doit maîtriser son état initial. Des comptes partagés, des dates de calendrier fixes et des exécutions de test interdépendantes créent des erreurs qui disparaissent à la tentative suivante. Nous planifions des jeux de données restaurables, des identités de test distinctes et une gestion maîtrisée du temps. Les données synthétiques peuvent couvrir des cas types de manière ciblée ; leurs répartitions et relations doivent néanmoins correspondre à l'usage prévu.

Les tests instables sont examinés, et non dissimulés durablement par un nombre illimité de nouvelles tentatives. Un test temporairement exclu nécessite un responsable, une justification et un plan de retour. Les rapports de test distinguent les défauts du produit des problèmes liés à l'environnement de test. Pour obtenir un retour rapide, les vérifications appropriées s'exécutent tôt dans le pipeline, tandis que les tests de charge ou de compatibilité, plus coûteux, ont lieu à des moments définis. La décision de validation devient ainsi compréhensible, au lieu de dépendre uniquement d'un code couleur.

Charge, restauration et validation en conditions d'erreur

Un test de charge commence par un modèle d'utilisation : quelles opérations se produisent, à quelle fréquence, quelle est la taille des volumes de données et combien d'utilisateurs travaillent simultanément ? Les moyennes peuvent masquer des cas isolés particulièrement lents. Nous examinons donc les distributions des temps de réponse ainsi que le taux d'erreur et l'utilisation des ressources. Les pics de charge, le fonctionnement prolongé et les dépendances lentes répondent à des questions différentes et ne sont pas fondus en un seul indicateur.

Nous vérifions en outre des scénarios d'erreur convenus dans des environnements maîtrisés, par exemple un service inaccessible ou une tâche de fond interrompue. Ce qui compte, c'est que les données restent cohérentes, que les utilisateurs reçoivent des retours compréhensibles et que l'exploitation détecte l'incident. Un rapport de validation indique l'état des tests, l'environnement, les données utilisées, les résultats et les risques ouverts. Il montre clairement quelles affirmations sont fiables et quels domaines restent en dehors du périmètre testé.