Je m'appelle Sasha Zubarchuk. Je suis arrivé chez Solid il y a trois ans en tant que Junior Manual QA. Depuis, je suis devenu ingénieur en automatisation, diplômé de la première école QA avec laquelle nous avons travaillé et suis passé au poste de chef de produit.
Dans cet article, je parlerai des fonctionnalités de test des systèmes de paiement et partagerai l'expérience de notre équipe: ce que nous testons, comment, à quels défis nous sommes confrontés et comment nous y répondons. Cette expérience sera utile à ceux qui construisent le processus de test sur le projet - à la fois les ingénieurs QA et les chefs de produit / projet.
Je n'entrerai pas dans la technique et les outils spécifiques, mais je parlerai de l'idée principale: comment rendre le processus de test de services techniquement complexes aussi transparent et calme que possible.
De quoi il s'agit et comment cela fonctionne
Solid est une passerelle qui permet aux entreprises du monde entier d'accepter les paiements en ligne des clients de différentes manières, des cartes bancaires et des portefeuilles électroniques à PayPal et Alipay.
Il y a quatre acteurs principaux dans toute cette histoire:
- utilisateur (il est également acheteur);
- commerçant - toute entreprise qui vend ses produits / services sur Internet et souhaite accepter de l'argent pour eux;
- passerelle de paiement - Solide;
- banque (acquéreur) - une institution financière qui effectue des transactions avec de l'argent réel.
En
termes simplifiés , cela ressemble à ceci: En termes simples, nous aidons les marchands à monétiser et à gagner de l'argent.
Vous vous posez peut-être une question: pourquoi les commerçants choisissent-ils Solid, s'ils peuvent travailler directement avec les banques? Tout est simple: 1) il existe de nombreuses banques, et chacune d'elles a ses propres spécificités - en combinant différentes banques de différents pays dans une seule infrastructure, nous obtenons un maximum de conversions et de revenus; 2) nous avons une vaste expertise dans les logiques de paiement et la lutte contre la fraude; 3) en plus des paiements bancaires, nous acceptons toutes les méthodes de paiement alternatives populaires dans une région particulière, et 4) nous sommes moins chers.
Commençons par le premier point - quelles sont ces caractéristiques des paiements dans différents pays? Par exemple, aux États-Unis, curieusement, vous ne pourrez pas effectuer de paiement aussi facilement qu'en Ukraine - en utilisant uniquement les détails de votre carte. Là, les banques sont tenues de vérifier les détails supplémentaires du payeur, tels que l'adresse de facturation et le code postal.
Il existe de nombreuses nuances similaires. Ainsi que des alternatives aux paiements par carte. Aux Pays-Bas et en Allemagne, par exemple, les gens aiment utiliser des portefeuilles Internet locaux. Les méthodes de paiement les plus populaires en Chine sont Alipay, WeChat Pay et UnionPay. Et au Nigéria , pour payer ses biens sur Internet, les utilisateurs se rendent à la banque en espèces!
Nous acceptons tous les paiements courants, sans exception - des cartes bancaires à PayPal, en passant par les portefeuilles électroniques, Google Pay, Apple Pay ou SMS. Avec l'aide de Solid, le commerçant peut travailler avec tous les types de paiement en une seule intégration. De plus, la passerelle dispose de sa propre protection contre la fraude, d'un système de routage des paiements, d'un outil pour éviter les rétrofacturations déraisonnables et bien plus encore.
Pourquoi tester les systèmes de paiement et les risques de ne pas tester
De nombreux commerçants sont connectés à Solid. Par conséquent, nous sommes responsables non seulement de notre activité, mais également de la monétisation de tous les clients qui nous sont connectés. Si quelque chose ne va pas de notre côté, nous échouons trop d'entreprises. Et vice versa - en testant et en améliorant notre service de paiement, nous améliorons les produits d'autres entreprises.
Malheureusement, en plus d'un paiement réussi, des erreurs peuvent survenir - à la fois le système et l'utilisateur. Il est important de comprendre que 100% des paiements ne réussiront jamais à aucun endroit. Mais pour notre part, nous sommes obligés de tout faire pour que la conversion des paiements soit la plus possible.
Tester une passerelle de paiement n'est pas une tâche de routine, car il s'agit d'un mécanisme assez complexe de dizaines de microservices et d'interconnexions. Nous testons tout en trois étapes. Tout d'abord, nous vérifions chaque tâche dans un environnement isolé, puis nous les combinons et les vérifions dans la release candidate au stade, nous voyons comment tout fonctionne dans l'intégration, puis nous publions et testons tout à nouveau en production.
Examinons de plus près ce que nous devons tester spécifiquement.
Caractéristiques des tests des systèmes de paiement
Le système de paiement comprend à la fois des interfaces API et Web. Il n'y a pas de différences cardinales dans l'API et les tests Web pour les systèmes de paiement, contrairement à tous les autres produits. La principale caractéristique est de tester des paiements spécifiques pour différentes régions, ainsi que pour tous les services auxiliaires.
Il semble que tester le paiement ne soit pas difficile: vous devez effectuer un paiement, vérifier que l'argent a été débité d'un compte et crédité sur un autre. Mais il y a des nuances. Les testeurs doivent connaître les spécificités des paiements dans différents pays, et parfois les nuances des lois locales et des réglementations bancaires.
Le deuxième point concerne les différents types de paiements: les abonnements, le premier paiement, l'autorisation (gel de l'argent sur le compte), le paiement via un portefeuille électronique. Chacun d'eux a ses propres spécificités de test.
Une attention particulière doit être portée au travail avec les devises: toutes n'ont pas une partie fractionnaire. Par exemple, la hryvnia a un sou, mais pas le peso chilien. Si vous transférez le montant du paiement 100 en Ukraine, la banque radiera 1 UAH, soit 100 kopecks. Et au Chili, cela signifierait 100 pesos. Comme vous pouvez le voir, de tels moments ne doivent pas être manqués.
Ce qui doit être testé dans les systèmes de paiement
Tous nos clients (web, applications mobiles, ainsi que services back-end) communiquent avec nous via l' API Solid . La passerelle elle-même est située sur un cluster séparé et communique avec différents systèmes (antifraude, tokenizer, banques, etc.).
Les développeurs solides sont engagés dans la résolution de plusieurs types de problèmes (et toutes ces tâches finissent à la disposition de l'équipe QA):
- ( , , , , );
- (PayPal, Alipay Visa Mastercard);
- : API, ;
- ( , );
- , (, , -);
- .
En plus des tâches qui viennent directement des développeurs, nous en recevons d'autres: vérification de toutes les données et UAT lors de la connexion de nouveaux marchands, vérification des tâches de l'équipe DevOps, mise en place de règles anti-fraude.
Pour résumer, tout ce que nous testons peut être décomposé dans les catégories suivantes:
Services backend solides:
- anti fraude;
- service d'abonnement;
- acheminement des paiements;
- système de contrôle comptable et financier;
- intégration avec des services externes.
Intégration avec les banques:
- vérifier l'exactitude du travail avec les devises;
- vérification des différents types de paiements (premier paiement par données de carte, paiement par jeton, remboursements, gel d'argent, etc.);
- traitement des notifications.
Modes de paiement alternatifs (sans carte):
- vérification du paiement;
- vérifier les caractéristiques de l'emplacement.
Administrateur:
- panneau d'administration interne (tout ce qui aide les analystes de Solid à exécuter des tests A / B sur la conversion d'un formulaire de paiement, à mettre en place des règles anti-fraude);
- panneau d'administration pour les commerçants.
Les interfaces des utilisateurs:
- l'apparence des formulaires et des pages de paiement;
- si le formulaire est affiché dans la langue d'une région spécifique (le formulaire de paiement Solid est disponible dans toutes les langues du monde);
- affichage correct du montant et des devises;
- suivi des actions des utilisateurs sur les formulaires;
- état de la page.
Autre:
- UAT lors de la connexion d'un nouveau marchand à Solid;
- tâches du département des risques pour vérifier les nouvelles configurations;
- études de santé fonctionnelle (par exemple, Apple Pay fonctionne-t-il dans WKWebView).
Étapes pour tester le succès
Automatisation
Lorsque vous travaillez avec des solutions informatiques à grande échelle, telles que des fournisseurs de paiement, vous devez constamment tester non seulement le fonctionnement des éléments fonctionnels individuels, mais également leur interaction. Cela ne fonctionnera pas sans automatisation. Si certains services ne sont pas couverts par les tests automatiques, les échecs ne peuvent pas être évités. Exécutez des autotests chaque fois que possible. Versé la tâche dans l'environnement - exécutez les tests. Fusion de plusieurs tâches dans une version candidate - exécutez les tests.
Dans notre cas, cela ressemble à ceci:
- les développeurs exécutent indépendamment des tests lors de la mise en œuvre d'une tâche;
- les testeurs exécutent des tests lorsqu'ils testent une tâche dans un environnement isolé;
- les tests sont automatiquement lancés lorsqu'une nouvelle version de la construction est construite;
- les autotests sont constamment exécutés sur l'environnement Prod.
L'exécution des autotests prend du temps, c'est pourquoi nous nous efforçons toujours d'optimiser ce processus autant que possible. Les tests sont exécutés de manière multithread, et ils sont également divisés en tâches par importance.
Nous disposons d'un ensemble minimal de tests qui valident la fonctionnalité de traitement des paiements de base de Solid - elle s'exécute en moins d'une minute. Tous les autres tests de Solid API et d'autres microservices prennent environ 3 à 4 minutes. Les tests d'interface utilisateur sont, bien sûr, légèrement plus lents. Mais même ici, nous n'arrêtons pas de travailler sur l'amélioration et l'optimisation.
Pourquoi le test isolé n'est-il pas la meilleure option pour tester les paiements? Je vais vous parler de notre affaire anti-fraude.
Chaque marchand Solid dispose d'un compte anti-fraude lié à la mise en place des règles, à leur fonctionnement. Par exemple, si un utilisateur a effectué plus de trois paiements par jour avec un marchand, nous bloquons le quatrième. Ou si plus de cinq utilisateurs effectuent des paiements avec la même carte, nous les bloquons et les ajoutons également à la liste noire. Nous l'avons couvert avec des autotests, mais nous avons rencontré un problème.
Au départ, nous avons dupliqué toutes les règles d'un compte test, simulé des actions frauduleuses et les tests semblaient fonctionner. Mais il s'est avéré que le commerçant lui-même a souvent des situations où les règles anti-fraude sont combinées, par exemple, trois d'entre elles ont fonctionné.
En isolant chaque paiement pour chaque règle spécifique, nous nous sommes débarrassés de la possibilité d'une combinaison de règles et de l'influence d'autres services sur le processus de paiement.
Comment nous avons effectué chaque paiement: nous avons effacé les données de test, créé toutes les conditions pour que le paiement soit soumis à une certaine règle, puis cela a fonctionné. Mais ce n'est pas un fait qu'il en sera ainsi dans un environnement de travail, car il n'y aura jamais de situation idéale pour qu'un paiement relève d'une seule règle.
Nous avons décidé de relier les véritables règles anti-fraude de nos clients au commerçant test. Ensuite, ils ont commencé à travailler plus clairement. Autrement dit, il était nécessaire de créer non pas des règles isolées, mais de les tester globalement comme pour un client particulier.
Désormais, les clients Solid peuvent personnaliser eux-mêmes les règles anti-fraude. Parce que les transactions qui ressemblent à de la fraude pour un commerçant peuvent être la norme pour un autre.
Si une personne fait cinq achats par jour dans une boutique en ligne, c'est la norme: d'abord, elle a aimé l'étui du mobile, puis le cahier, etc. Mais pour les applications de fitness, c'est déjà une anomalie. Il est peu probable qu'une personne achète cinq programmes d'entraînement par jour.
L'automatisation aide vraiment à établir un équilibre: seules les nouvelles fonctionnalités et les scénarios qui nécessitent une attention humaine sont vérifiés manuellement, tout le reste est automatisé. L'automatisation peut aider à réduire à la fois les coûts de test et les risques humains.
Essais au stade des spécifications techniques
En plus de vérifier directement la fonctionnalité de la fonctionnalité, nous consacrons beaucoup de temps à nous assurer que les développeurs et les gestionnaires perçoivent la fonctionnalité implémentée de la même manière. Cela semble évident, mais beaucoup le négligent.
Tous les services de configuration sont assez complexes, ils ont une vaste gamme de possibilités et même les plus petits détails peuvent empêcher le service de fonctionner comme prévu.
La technique du "early testing" présente plusieurs avantages à la fois:
- l'équipe de développement comprendra correctement la tâche et nous ne perdrons pas de temps sur les correctifs;
- une spécification technique bien rédigée représente 70% d'une bonne documentation;
- étant donné que l'équipe de test s'est familiarisée à l'avance avec la spécification technique, les scénarios de test sont également pensés à l'avance, et au moment où la tâche implémentée arrive au test, le processus est plus rapide.
Bonne documentation de test
Une documentation interne vraiment bonne et structurée représente la moitié de la bataille lors des tests. Malgré le fait que presque toutes les fonctionnalités doivent être automatisées, le travail manuel ne sera jamais nul.
La description des processus de test pour diverses fonctionnalités, des articles avec des solutions de problèmes possibles et divers manuels accélèrent le travail de l'équipe de test.
Chez Solid, nous avons créé notre propre base de connaissances. Il décrit comment chaque banque et un autre mode de paiement fonctionnent dans différents endroits, quels types de paiements la banque prend en charge et comment, en principe, les paiements sont effectués dans une région particulière.
Une telle base est une tâche vaste et complexe qui est devenue un défi pour nous. Il était nécessaire de rassembler toute la documentation et de décrire les processus de manière accessible. Mais maintenant, lorsqu'un nouvel employé vient chez nous, il n'y a aucun problème. Il est difficile de se rappeler comment quelque chose devrait fonctionner la première fois, et s'il existe une documentation de test, l'option de faire une erreur est minime. La documentation claire permet au testeur de déterminer exactement pourquoi le paiement ne passe pas: est-ce une erreur ou ce type de paiement ne devrait tout simplement pas fonctionner dans cette banque.
Laissez-moi vous donner un autre exemple. Une fois que nous avons changé les logos des systèmes de paiement internationaux sur les formulaires de paiement. Nous avons plus de 200 designs différents pour nos clients et pour chaque design il peut y avoir plusieurs configurations de champs sur le formulaire. Par exemple, pour le Brésil, un champ CPF supplémentaire est ajouté - un analogue de notre code d'identification.
En raison de la nouvelle taille du logo, certains champs du formulaire peuvent se déplacer, se cacher ou devenir non cliquables. Personne dans l'équipe de test de Solid ne sait physiquement à quoi devraient ressembler les 200 formes.
Tester cette tâche était angoissant, mais en conséquence, nous avons créé une base de connaissances avec des formulaires de référence pour chacun de nos marchands, l'avons couverte d'autotests et maintenant nous n'avons pas peur des changements liés aux conceptions.
***
Enfin, je vais vous dire un petit fait intéressant du monde du traitement: la part des baisses de cartes restreintes en Ukraine est assez faible - 1 à 2%. Soit les banques ukrainiennes sont si douées pour la prévention de la fraude, soit personne ne veut voler les données des cartes des utilisateurs ukrainiens ...
Néanmoins, il n'y a pas de produit avec des processus de développement et de test idéaux, mais nous pouvons les améliorer. Après tout, la tâche de chaque entreprise est de lancer un produit de qualité. Qui d'autre, si ce ne sont les ingénieurs QA, va vous aider?
Je serais heureux si vous partagiez vos principes d'un bon processus de test dans les commentaires.