Comment testeriez-vous un parcours de commande et de paiement de bout en bout ?

Couvrez le chemin heureux, puis les risques propres à l'argent : cartes refusées et autorisations partielles, timeouts où le débit passe mais la réponse se perd, soumissions en double, remboursements totaux et partiels, devise et arrondis, interaction entre taxes et remises, et stock qui change en pleine commande. Utilisez les cartes de test du bac à sable du fournisseur, et vérifiez ce que le back-end a enregistré plutôt que de faire confiance à l'écran de confirmation.

Le chemin heureux prend dix minutes ; tout ce qui a de la valeur est dans les modes de défaillance, parce que c'est le parcours où un bug coûte directement de l'argent. Le cas que je teste toujours en premier est la transaction interrompue : le fournisseur autorise le débit, puis la réponse ne revient jamais, expire, ou l'utilisateur ferme l'onglet. La commande existe-t-elle ? Le client est-il débité sans rien en retour ? C'est le pire résultat de tout le système et cela demande une logique de rapprochement, pas de l'espoir. À côté de cela, le double clic sur valider, et le retour en arrière puis la resoumission, qui doit être idempotente plutôt que de débiter deux fois. Puis les réponses spécifiques du fournisseur via ses cartes de test en bac à sable : refus, fonds insuffisants, carte expirée, et une carte qui déclenche une authentification supplémentaire, parce que ce chemin a sa propre redirection et ses propres façons de casser. Puis l'arithmétique de l'argent : devises avec un nombre de décimales différent, arrondi sur une remise en pourcentage, taxe appliquée avant ou après la remise, et un bon de réduction supérieur au total de la commande. Et aussi le stock qui tombe à zéro pendant que le client est sur l'écran de paiement. Je vérifie contre la base de données et le tableau de bord du fournisseur, jamais contre la page de confirmation.