Ich heiße Sasha Zubarchuk. Ich bin vor drei Jahren als Junior Manual QA zu Solid gekommen. Seitdem wurde ich Automatisierungsingenieur, absolvierte die erste QS-Schule, mit der wir zusammengearbeitet haben, und wechselte zum Produktmanager.
In diesem Artikel werde ich über die Funktionen des Testens von Zahlungssystemen sprechen und die Erfahrungen unseres Teams teilen: Was wir testen, wie, welchen Herausforderungen wir gegenüberstehen und wie wir darauf reagieren. Diese Erfahrung ist nützlich für diejenigen, die den Testprozess für das Projekt aufbauen - sowohl für QS-Ingenieure als auch für Produkt- / Projektmanager.
Ich werde mich nicht mit der Technik und den spezifischen Werkzeugen befassen, sondern über die Hauptidee sprechen: Wie kann der Prozess des Testens technisch komplexer Dienste so transparent und ruhig wie möglich gestaltet werden?
Woraus der Zahlungsdienst besteht und wie er funktioniert
Solid ist ein Gateway, mit dem Unternehmen auf der ganzen Welt Online-Kundenzahlungen auf verschiedene Arten akzeptieren können, von Bankkarten und E-Wallets bis hin zu PayPal und Alipay.
Es gibt vier Hauptakteure in dieser ganzen Geschichte:
- Benutzer (er ist auch ein Käufer);
- Händler - jedes Unternehmen, das seine Waren / Dienstleistungen im Internet verkauft und Geld dafür annehmen möchte;
- Zahlungsgateway - Solide;
- Bank (Acquirer) - ein Finanzinstitut, das Transaktionen mit echtem Geld durchführt.
In einfachen Worten sieht es so aus: Einfach ausgedrückt, wir helfen Händlern, Geld zu verdienen und Geld zu verdienen.
Sie haben vielleicht eine Frage: Warum wählen Händler Solid, wenn sie direkt mit Banken zusammenarbeiten können? Alles ist einfach: 1) Es gibt viele Banken, und jede von ihnen hat ihre eigenen Besonderheiten. Durch die Kombination verschiedener Banken aus verschiedenen Ländern in einer einzigen Infrastruktur erzielen wir maximale Conversions und Einnahmen. 2) Wir verfügen über ein umfassendes Fachwissen in Bezug auf Zahlungslogik und Betrugsbekämpfung. 3) Zusätzlich zu Bankzahlungen akzeptieren wir alle alternativen Zahlungsmethoden, die in einer bestimmten Region beliebt sind, und 4) wir sind billiger.
Beginnen wir mit dem ersten Punkt: Was sind diese Merkmale für Zahlungen in verschiedenen Ländern? In den USA können Sie beispielsweise seltsamerweise nicht so einfach bezahlen wie in der Ukraine - nur mit Kartendaten. Dort müssen die Banken zusätzliche Zahlungsdetails wie Rechnungsadresse und Postleitzahl überprüfen.
Es gibt viele ähnliche Nuancen. Sowie Alternativen zu Kartenzahlungen. In den Niederlanden und in Deutschland beispielsweise nutzen die Menschen gerne lokale Internet-Geldbörsen. Die beliebtesten Zahlungsmethoden in China sind Alipay, WeChat Pay und UnionPay. Und in Nigeria gehen Benutzer mit Bargeld zur Bank, um Waren im Internet zu bezahlen!
Wir akzeptieren ausnahmslos alle gängigen Zahlungen - von Bankkarten über PayPal, E-Wallets, Google Pay, Apple Pay bis hin zu SMS. Mit Hilfe von Solid erhält der Händler Zugriff auf die Arbeit mit allen Zahlungsarten in einer Integration. Darüber hinaus verfügt das Gateway über einen eigenen Betrugsschutz, ein Zahlungsroutingsystem, ein Tool zur Verhinderung unangemessener Rückbuchungen und vieles mehr.
Warum Zahlungssysteme testen und das Risiko, nicht zu testen?
Viele Händler sind mit Solid verbunden. Daher sind wir nicht nur für unser Geschäft verantwortlich, sondern auch für die Monetarisierung aller mit uns verbundenen Kunden. Wenn auf unserer Seite etwas schief geht, scheitern wir an zu vielen Unternehmen. Und umgekehrt - indem wir unseren Zahlungsservice testen und verbessern, verbessern wir die Produkte anderer Unternehmen.
Leider können neben einer erfolgreichen Zahlung auch Fehler auftreten - sowohl beim System als auch beim Benutzer. Es ist wichtig zu verstehen, dass 100% der Zahlungen an keinem Ort erfolgreich ausgeführt werden. Wir für unseren Teil sind jedoch verpflichtet, alles zu tun, um die Umrechnung von Zahlungen so möglich wie möglich zu gestalten.
Das Testen eines Zahlungsgateways ist keine Routineaufgabe, da es sich um einen ziemlich komplexen Mechanismus aus Dutzenden von Mikrodiensten und Verbindungen handelt. Wir testen alles in drei Schritten. Zuerst überprüfen wir jede Aufgabe in einer isolierten Umgebung, kombinieren sie dann und überprüfen sie in einem Release-Kandidaten in der Phase. Wir sehen, wie alles in der Integration funktioniert. Dann geben wir alles in der Produktion frei und testen es erneut.
Schauen wir uns genauer an, was wir speziell testen müssen.
Funktionen zum Testen von Zahlungssystemen
Das Zahlungssystem besteht sowohl aus API- als auch aus Webschnittstellen. Im Gegensatz zu anderen Produkten gibt es keine wesentlichen Unterschiede bei API- und Webtests für Zahlungssysteme. Das Hauptmerkmal besteht darin, bestimmte Zahlungen für verschiedene Regionen sowie alle Hilfsdienste zu testen.
Es scheint einfach zu sein, die Zahlung zu testen: Sie müssen eine Zahlung vornehmen, überprüfen, ob das Geld von einem Konto abgebucht und einem anderen gutgeschrieben wurde. Aber es gibt Nuancen. Tester müssen die Besonderheiten von Zahlungen in verschiedenen Ländern und manchmal die Nuancen lokaler Gesetze und Bankvorschriften kennen.
Der zweite Punkt betrifft verschiedene Arten von Zahlungen: Abonnements, die erste Zahlung, Autorisierung (Einfrieren des Geldes auf dem Konto), Zahlung über eine elektronische Geldbörse. Jeder von ihnen hat seine eigenen Testspezifikationen.
Besonderes Augenmerk sollte auf die Arbeit mit Währungen gelegt werden: Nicht alle haben einen Bruchteil. Zum Beispiel hat die Griwna einen Cent, der chilenische Peso jedoch nicht. Wenn Sie den Zahlungsbetrag 100 in der Ukraine überweisen, schreibt die Bank 1 UAH ab, dh 100 Kopeken. Und in Chile würde das 100 Pesos bedeuten. Wie Sie sehen können, sollten solche Momente nicht verpasst werden.
Was muss in Zahlungssystemen getestet werden?
Alle unsere Kunden (Web, mobile Anwendungen sowie Back-End-Services) kommunizieren über die Solid-API mit uns . Das Gateway selbst befindet sich in einem separaten Cluster und kommuniziert mit verschiedenen Systemen (Betrugsbekämpfung, Tokenizer, Banken usw.).
Solide Entwickler lösen verschiedene Arten von Problemen (und all diese Aufgaben stehen dem QS-Team zur Verfügung):
- ( , , , , );
- (PayPal, Alipay Visa Mastercard);
- : API, ;
- ( , );
- , (, , -);
- .
Zusätzlich zu den Aufgaben, die direkt von den Entwicklern kommen, erhalten wir andere: Überprüfung aller Daten und UAT, wenn neue Händler verbunden sind, Überprüfung der Aufgaben des DevOps-Teams, Einrichtung von Betrugsbekämpfungsregeln.
Zusammenfassend lässt sich alles, was wir testen, in folgende Kategorien unterteilen:
Solide Backend-Services:
- Betrugsbekämpfung;
- Abonnement;
- Zahlungsrouting;
- Buchhaltungs- und Finanzkontrollsystem;
- Integration mit externen Diensten.
Integration mit Banken:
- Überprüfung der Richtigkeit der Arbeit mit Währungen;
- Überprüfung verschiedener Arten von Zahlungen (erste Zahlung per Kartendaten, Zahlung per Token, Rückerstattung, Einfrieren von Geld usw.);
- Bearbeitung von Benachrichtigungen.
Alternative Zahlungsmethoden (ohne Karte):
- Überprüfung der Zahlung;
- Überprüfen der Funktionen des Standorts.
Admins:
- internes Admin-Panel (alles, was Solid-Analysten bei der Durchführung von A / B-Tests zur Konvertierung eines Zahlungsformulars hilft, Regeln für Betrugsbekämpfung festlegen);
- Admin-Panel für Händler.
Benutzeroberflächen:
- Erscheinen von Zahlungsformularen und -seiten;
- ob das Formular in der Sprache einer bestimmten Region angezeigt wird (das Solid-Zahlungsformular ist in allen Sprachen der Welt verfügbar);
- korrekte Anzeige des Betrags und der Währungen;
- Verfolgen von Benutzeraktionen auf Formularen;
- Seitenstatus.
Andere:
- UAT beim Verbinden eines neuen Händlers mit Solid;
- Aufgaben der Risikoabteilung zur Überprüfung neuer Konfigurationen;
- Funktionsgesundheitsstudien (funktioniert beispielsweise Apple Pay in WKWebView).
Schritte zum Testen des Erfolgs
Automatisierung
Wenn Sie mit umfangreichen IT-Lösungen wie Zahlungsanbietern arbeiten, müssen Sie nicht nur die Funktionsweise einzelner Funktionselemente, sondern auch deren Interaktion ständig testen. Ohne Automatisierung geht es nicht. Wenn einige Dienste nicht durch Autotests abgedeckt sind, können Fehler nicht vermieden werden. Führen Sie nach Möglichkeit Autotests durch. Goss die Aufgabe in die Umgebung - führen Sie die Tests aus. Mehrere Aufgaben zu einem Release-Kandidaten zusammengeführt - führen Sie die Tests aus.
In unserem Fall geht es ungefähr so:
- Entwickler führen bei der Implementierung einer Aufgabe unabhängig Tests durch.
- Tester führen Tests durch, wenn sie eine Aufgabe in einer isolierten Umgebung testen.
- Tests werden automatisch gestartet, wenn eine neue Version des Builds erstellt wird.
- Autotests werden ständig in der Prod-Umgebung ausgeführt.
Das Ausführen von Autotests braucht Zeit, und deshalb bemühen wir uns immer, diesen Prozess so weit wie möglich zu optimieren. Tests werden multithreaded ausgeführt und nach Wichtigkeit in Aufgaben unterteilt.
Wir haben nur eine minimale Anzahl von Tests, die die Kernfunktionalität von Solid für die Zahlungsabwicklung validieren - sie läuft in weniger als einer Minute. Alle anderen Tests von Solid API und anderen Microservices dauern ca. 3-4 Minuten. UI-Tests sind natürlich etwas langsamer. Aber auch hier hören wir nicht auf, an Verbesserungen und Optimierungen zu arbeiten.
Warum ist isoliertes Testen nicht die beste Option beim Testen von Zahlungen? Ich erzähle Ihnen von unserem Betrugsbekämpfungsfall.
Jeder Solid-Händler verfügt über ein Betrugsbekämpfungskonto, das mit der Festlegung von Regeln verbunden ist, wie diese funktionieren sollen. Wenn ein Benutzer beispielsweise mehr als drei Zahlungen pro Tag mit einem Händler geleistet hat, blockieren wir die vierte. Wenn mehr als fünf Benutzer mit derselben Karte bezahlen, blockieren wir diese ebenfalls und fügen sie der schwarzen Liste hinzu. Wir haben es mit Autotests abgedeckt, sind aber auf ein Problem gestoßen.
Zunächst haben wir alle Regeln für ein Testkonto dupliziert, betrügerische Aktionen simuliert und die Tests schienen zu funktionieren. Es stellte sich jedoch heraus, dass der Händler selbst häufig Situationen hat, in denen Betrugsbekämpfungsregeln kombiniert werden, zum Beispiel drei davon.
Indem wir jede Zahlung für jede spezifische Regel isolierten, haben wir die Möglichkeit einer Kombination von Regeln und den Einfluss anderer Dienste auf den Zahlungsprozess beseitigt.
So haben wir jede Zahlung getätigt: Wir haben die Testdaten gelöscht, alle Bedingungen für die Zahlung unter eine bestimmte Regel erstellt und dann hat es funktioniert. Es ist jedoch keine Tatsache, dass dies in einem Arbeitsumfeld der Fall sein wird, da es niemals eine ideale Situation geben wird, in der eine Zahlung unter eine Regel fällt.
Wir haben uns entschlossen, echte Betrugsbekämpfungsregeln unserer Kunden mit dem Testhändler zu verbinden. Dann fingen sie an, klarer zu trainieren. Das heißt, es war notwendig, keine isolierten Regeln zu erstellen, sondern sie insgesamt zu testen, wie sie für einen bestimmten Client sind.
Jetzt können Solid-Kunden die Betrugsbekämpfungsregeln für sich selbst anpassen. Weil Transaktionen, die für einen Händler wie Betrug aussehen, für einen anderen die Norm sein können.
Wenn eine Person fünf Einkäufe pro Tag in einem Online-Shop tätigt, ist dies die Norm: Zuerst mochte sie den Fall für das Handy, dann das Notebook usw. Für Fitnessanwendungen ist dies jedoch bereits eine Anomalie. Es ist unwahrscheinlich, dass eine Person fünf Trainingsprogramme pro Tag kauft.
Automatisierung hilft wirklich dabei, ein Gleichgewicht herzustellen: Nur neue Funktionen und Szenarien, die menschliche Aufmerksamkeit erfordern, werden manuell überprüft, alles andere wird automatisiert. Die Automatisierung kann dazu beitragen, sowohl die Testkosten als auch das menschliche Risiko zu senken.
Prüfung im Stadium der technischen Spezifikationen
Neben der direkten Überprüfung der Funktionalität der Funktionalität widmen wir viel Zeit, um sicherzustellen, dass Entwickler und Manager die implementierte Funktionalität auf die gleiche Weise wahrnehmen. Es scheint offensichtlich, aber viele vernachlässigen es.
Alle Konfigurationsdienste sind recht komplex, bieten eine Vielzahl von Möglichkeiten und selbst kleinste Details können dazu führen, dass der Dienst nicht wie erwartet funktioniert.
Die "Early Testing" -Technik hat mehrere Vorteile gleichzeitig:
- Das Entwicklungsteam wird die Aufgabe richtig verstehen und wir werden keine Zeit mit Korrekturen verschwenden.
- Eine gut geschriebene technische Spezifikation macht 70% der guten Dokumentation aus.
- Aufgrund der Tatsache, dass das Testteam die technischen Spezifikationen im Voraus kennengelernt hat, werden die Testszenarien auch im Voraus durchdacht, und in dem Moment, in dem die implementierte Aufgabe zum Test kommt, geht der Prozess schneller.
Gute Testdokumentation
Wirklich gute und strukturierte interne Dokumentation ist beim Testen die halbe Miete. Trotz der Tatsache, dass fast alle Funktionen automatisiert werden sollten, wird manuelle Arbeit niemals umsonst sein.
Die Beschreibung von Testprozessen für verschiedene Funktionen, Artikel mit möglichen Problemlösungen und verschiedene Handbücher beschleunigen die Arbeit des Testteams.
Wir bei Solid haben unsere eigene Wissensbasis geschaffen. Es wird beschrieben, wie jede Bank und eine alternative Zahlungsmethode an verschiedenen Standorten funktionieren, welche Arten von Zahlungen die Bank unterstützt und wie Zahlungen im Prinzip in einer bestimmten Region erfolgen.
Eine solche Basis ist eine umfangreiche und komplexe Aufgabe, die für uns zu einer Herausforderung geworden ist. Es war notwendig, die gesamte Dokumentation zusammenzuführen und die Prozesse auf zugängliche Weise zu beschreiben. Aber jetzt, wenn ein neuer Mitarbeiter zu uns kommt, gibt es keine Probleme. Es ist schwer zu merken, wie etwas beim ersten Mal funktionieren sollte, und wenn Testdokumentation vorhanden ist, ist die Möglichkeit, einen Fehler zu machen, minimal. Anhand der übersichtlichen Dokumentation kann der Tester genau feststellen, warum die Zahlung nicht ausgeführt wird: Es handelt sich um einen Fehler, oder diese Art der Zahlung sollte in dieser Bank einfach nicht funktionieren.
Lassen Sie mich Ihnen ein weiteres Beispiel geben. Einmal haben wir die Logos internationaler Zahlungssysteme auf Zahlungsformularen geändert. Wir haben mehr als 200 verschiedene Designs für unsere Kunden. Für jedes Design kann das Formular mehrere Feldkonfigurationen enthalten. Für Brasilien wird beispielsweise ein zusätzliches CPF-Feld hinzugefügt - ein Analogon zu unserem Identifikationscode.
Aufgrund der neuen Größe des Logos können einige Felder im Formular verschoben, ausgeblendet oder nicht mehr angeklickt werden. Niemand im Solid-Testteam weiß nur physisch, wie alle 200 Formulare aussehen sollen.
Das Testen dieser Aufgabe war nervenaufreibend, aber als Ergebnis haben wir eine Wissensbasis mit Referenzformularen für jeden unserer Händler erstellt, diese mit Autotests abgedeckt und jetzt haben wir keine Angst vor Änderungen im Zusammenhang mit Designs.
***.
Abschließend möchte ich Ihnen eine kleine interessante Tatsache aus der Welt der Verarbeitung erzählen: Der Anteil der Restricted Card-Rückgänge in der Ukraine ist mit 1-2% recht gering. Entweder sind ukrainische Banken so gut in der Betrugsprävention, oder niemand möchte die Kartendaten ukrainischer Benutzer stehlen ...
Trotzdem gibt es kein Produkt mit idealen Entwicklungs- und Testprozessen, aber wir können sie verbessern. Schließlich ist es die Aufgabe eines jeden Unternehmens, ein Qualitätsprodukt herauszubringen. Wer sonst, wenn nicht QS-Ingenieure, hilft dabei?
Ich würde mich freuen, wenn Sie Ihre Grundsätze eines guten Testprozesses in den Kommentaren teilen.