Réponse.

Le test manuel des intégrations est le processus de vérification de l'interaction entre différents modules, services ou systèmes externes manuellement, sans scripts automatisés.

Contexte de la question :

À l'aube du développement des produits informatiques, tous les systèmes étaient créés de manière monolithique, mais avec l'augmentation de l'échelle des entreprises et du nombre de services tiers, des tests d'intégration sont devenus pertinents. Les testeurs ont commencé à se poser la question : comment s'assurer que les données et les actions passent correctement entre les systèmes - par exemple, que le paiement réussi est reflété à la fois dans la facturation et dans le système de comptabilité.

Problème :

La plus grande difficulté est l'absence d'un environnement pleinement fonctionnel : les intégrations peuvent dépendre de services tiers, d'API instables ou de contraintes externes. De plus, le test manuel à chaque point d'intégration peut être très laborieux, il est facile de commettre une erreur dans l'ordre des étapes ou d'omettre une conséquence en cascade importante.

Solution :

Utilisez des environnements de test avec des « mocks » (mock/stub) pour garantir la répétabilité du test.
Structurez les cas de test, rédigez des vérifications étape par étape des messages, des journaux, des statuts.
Testez en priorité les cas limites, les timeouts, les tentatives de réappel des intégrations, la réaction du système face aux échecs.

Caractéristiques clés :

Nécessité de comprendre la logique métier des deux parties intégrées.
Prise en compte de l'asynchronie et des erreurs de transmission d'état.
Soutien de la résilience face aux pannes partielles.

Questions pièges.

Qu'est-ce que des doubles de test (test doubles) et pourquoi sont-ils nécessaires lors du test manuel des intégrations ?

Les doubles de test sont des imitations de composants d'intégration (par exemple, mock, stub, fake). Lors du test manuel, ils sont nécessaires pour traiter des scénarios où le véritable système externe est inaccessible ou où ses appels coûtent de l'argent.

Peut-on considérer l'intégration comme testée si les cas de test n'ont couvert que le happy path ?

Non. Il est nécessaire de tester les cas limites : erreurs de connexion, formats de données incorrects, timeouts, réponses inattendues.

Est-il suffisant de vérifier uniquement l'envoi/réception des données ou faut-il autre chose ?

Il est important de vérifier la validité du CONTENU des données, leur transformation et le comportement du système face à diverses erreurs à l'interface.

Erreurs typiques et anti-patterns

Travailler uniquement avec « sa » partie du système sans vérifier le comportement du côté du partenaire.
Ignorer les scénarios négatifs.
Ne pas analyser les journaux ou ne pas conserver l'historique des erreurs d'intégration.

Exemple de la vie réelle

Cas négatif

Le testeur vérifie l'intégration entre le CRM et le système de facturation uniquement sur l'ajout réussi d'une commande. Il ne vérifie pas l'erreur de synchronisation et l'omission d'une transaction.

Avantages :

Couverture rapide des scénarios principaux.

Inconvénients :

L'erreur en cas de panne d'intégration ne sera détectée qu'avec de vraies données.

Cas positif

Le testeur crée un ensemble de tests avec la désactivation et l'activation de la connexion Internet, en utilisant des jetons invalides. Il valide les journaux des deux côtés.