Beginnen wir mit dem Süßen und geben Beispiele aus der Testpraxis.
Stellen Sie sich einen Online-Shop vor, der zum Start bereit ist. Nichts ist Ärger. Vermarkter entwickelten eine Werbestrategie, Artikel wurden in speziellen Internetquellen verfasst und Werbung wurde bezahlt. Das Management erwartet wöchentlich bis zu 300 Einkäufe. In der ersten Woche verzeichnen die Manager 53 Zahlungen. Die Geschäftsleitung ist wütend ...
Der Projektmanager sucht nach Gründen: dem Mangel an Gedanken an die Benutzerfreundlichkeit? unangemessener Verkehr? noch etwas? Wir begannen zu verstehen, studierten das Datenanalysesystem. Es stellte sich heraus, dass 247 Personen die Kasse erreichten und nur 53 bezahlten.
Die Analyse ergab, dass der Rest aufgrund der E-Mail-Adresse keinen Kauf tätigen konnte!
Die Prüfung des Bestellformulars wurde einem unerfahrenen Spezialisten übergeben. Er versuchte sein Bestes, gab in die Felder "Name", "E-Mail", "Telefon" alle möglichen und unmöglichen Optionen ein, die ihm Online-Generatoren gaben. Eine Woche später wurden alle Fehler gefunden und behoben. Die Veröffentlichung hat stattgefunden. Unter den in Betracht gezogenen Optionen gab es jedoch keine einzige E-Mail-Adresse mit weniger als 8 Zeichen nach @.
Daher konnten die glücklichen Besitzer von Mails @ mail.ru, @ ya.ru (und ähnlichen) ihre E-Mails nicht eingeben und verließen die Website ohne Einkaufen. Die Eigentümer erhielten weniger als 600.000 Rubel, das gesamte Werbebudget wurde ins Leere geleert und der Online-Shop selbst erhielt eine Reihe negativer Bewertungen.
Denken Sie, dass dies ein Einzelfall ist? Dann ist hier eine weitere Horrorgeschichte für den Kunden.
Aufgrund des allgemeinen Interesses an bargeldlosen Zahlungen beschloss die Kreditgesellschaft, eine neue Art der Überweisung von Geldern einzuführen - auf die Bankkarte des Kreditnehmers. Wir haben das entsprechende Formular in das persönliche Konto des Managers implementiert, verschiedene Fehleroptionen in den Feldern für die Eingabe von Kartendaten getestet, behoben und mit der Arbeit begonnen. Einen Monat später erreichte das Management die Information, dass 24% der potenziellen Kreditnehmer, die bereits eine Genehmigung erhalten hatten, erst am Ende einen Kredit beantragten. Warum? Sie stellten eine Bankkarte zur Verfügung, deren Nummer 18 Ziffern enthielt, anstatt der zugesagten und getesteten 16. Weder das System noch die Manager konnten solche Karten registrieren, und die Kunden ließen nichts übrig.
Das Pilotprojekt wurde in 3 Büros der Stadt durchgeführt. Die durchschnittliche Anzahl der monatlichen Kredite in drei Büros betrug 340. Ergebnis: Die Organisation verlor mindestens 612.000 Rubel. Einnahmen.
Dies sind nur einige Beispiele, bei denen synthetische Daten ernsthafte Verluste bei einem Projekt verursachen können. Viele Tester geben synthetische Daten ein, um verschiedene Projekte zu testen - von mobilen Anwendungen bis hin zu Software. In diesem Fall entwickeln die Tester selbst Testsituationen und versuchen, das Benutzerverhalten vorherzusagen.
Meistens sehen sie den Benutzer jedoch nicht mehrdimensional wie in einem Kino mit 3D-Brille, sondern skizzenhaft, als hätte das Kind einen kleinen Mann auf ein Albumblatt gezeichnet.
Dies führt dazu, dass der Tester nicht alle möglichen Testsituationen abdeckt und nicht mit einer großen Datenmenge arbeiten kann. Obwohl Tests gut durchgeführt werden können, gibt es keine Garantie dafür, dass das System nicht abstürzt, wenn ein realer Benutzer (meistens unlogisch und sogar unvorhersehbar) mit dem Produkt interagiert.
Heute werden wir darüber sprechen, welche Daten im Testprozess bevorzugt werden sollen: synthetisch oder real.
Wir werden in Begriffen verstehen
Jedes Mal, wenn wir einen Test machen, entscheiden wir, welche Testdaten wir verwenden. Ihre Quellen können sein:
- Kopien der Produktionsdatenbank auf dem Prüfstand.
- Datenbank von Client-Systemen von Drittanbietern, die im aktuellen System verwendet werden können.
- Testen Sie Datengeneratoren.
- Manuelle Erstellung von Testdaten.
Die ersten beiden Quellen liefern uns echte Testdaten. Sie werden durch vorhandene Prozesse von Benutzern oder dem System erstellt.
Wenn wir uns beispielsweise einem Projekt zur Entwicklung eines Webprodukts für ein produzierendes Unternehmen anschließen, können wir eine Kopie der vorhandenen 1C-Datenbank zum Testen verwenden, die seit mehreren Jahren alle Daten über Vorgänge und Kunden sammelt und verarbeitet. Mit dem Modul zum Generieren und Anzeigen von Berichten über abgeschlossene Bestellungen erhalten wir Informationen von 1C im erforderlichen Format und arbeiten mit realen Testdaten.
Wir nennen die Quellen aus den Punkten 3 und 4 „synthetische Testdaten“ (ein solcher Begriff kann in ausländischen Tests gefunden werden, wird jedoch im russischsprachigen Segment selten verwendet). Wir erstellen solche Daten selbst zum Zwecke der Entwicklung und Erprobung.
Zum Beispiel haben wir von einer neuen elektronischen Handelsplattform einen Auftrag zur Beschaffung durch staatliche und kommunale Organisationen nach 44 Bundesgesetzen erhalten. Hier werden sehr strenge Informationsschutzregeln befolgt, sodass das Team keinen Zugriff auf reale Daten hat. Der einzige Ausweg zum Testen besteht darin, einen ganzen Satz von Testdaten von Grund auf neu zu erstellen. Sogar physische digitale Signaturen, die ausschließlich zum Testen bestimmt sind.
In unserer Praxis wird selten ein Datentyp verwendet. In der Regel arbeiten wir je nach Aufgabe mit einer Kombination davon.
Um die Einschränkungen und Ausnahmen im selben System für das produzierende Unternehmen zu überprüfen, haben wir zusätzlich synthetische Daten verwendet. Mit ihrer Hilfe haben wir überprüft, wie sich der Bericht verhält, wenn eine Bestellung keine Produkte enthält. Auf einer elektronischen Handelsplattform haben wir synthetische Daten mit echten Nachschlagewerken OKPD2 und OKVED2 kombiniert.
Synthetische Datenfunktionen
In einigen Situationen kann auf synthetische Daten einfach nicht verzichtet werden! Mal sehen, welche Aufgaben sie aus dem Arsenal des Testers verwenden können:
1. Vereinfachung und Standardisierung
Oft sind reale Daten homogene Datenfelder: Stellen Sie sich vor, dass Tausende von Personen mit einem Satz von Attributen, juristische Personen unterschiedlichen Typs, Standardoperationen und viele andere Arten von Entitäten im System registriert sind. Warum sollten Sie dann Stunden damit verbringen, dieselbe Eingabe zu testen, wenn Sie sie zu Gruppen zusammenfassen und für jede Gruppe einen „Vertreter“ ernennen können?
Bei einem der Projekte des letzten Jahres hat der Kunde beschlossen, das Testerteam vor der nächsten Veröffentlichung zu verstärken, an der ein Team unserer Spezialisten beteiligt war. Das Produkt enthielt ein modifiziertes Registrierungsformular mit vielen Feldern. Wir haben die Testformulare 30 Minuten lang ausgelegt und ungefähr die gleiche Zeit verbracht. Parallel dazu stellte sich heraus, dass ein anderer Tester dieses Formular bereits getestet hatte, nachdem er 7 Stunden damit verbracht hatte. Warum? Er hat gerade beschlossen, den Test gemäß den tatsächlichen Daten von 12 Mitarbeitern aus der Mitarbeiterliste durchzuführen, und nicht berücksichtigt, dass der Test für einen Mitarbeiter alle Attribute abdeckt, die für jedes registrierte Profil gleich sind.
Gewinn: 6 Stunden 30 Minuten und dies ist nur bei einem Test.
2. Kombinatorik und Testabdeckung
Trotz der oft großen Menge an realen Daten enthalten sie möglicherweise keine Reihe möglicher Fälle. Um die Funktionsfähigkeit des Systems mit verschiedenen Kombinationen von Eingabedaten zu gewährleisten, müssen wir diese selbst generieren.
Kehren wir zum vorherigen Beispiel zurück. Das Registrierungsformular in der neuen Version wurde aus einem bestimmten Grund fertiggestellt. Das Kundenteam, basierend auf den Normen der Unternehmenskultur, hat beschlossen, den zweiten Vornamen verbindlich zu machen. Infolgedessen hatten alle ausländischen Spezialisten im Staat plötzlich einen Vater - Ivan (jemand soll Ivanovich schreiben, bis er es repariert). Der Fall ist lustig, aber wenn Sie einige Wunschliste oder die Parameter Ihrer Kunden in den Tests nicht berücksichtigen, dann seien Sie nicht beleidigt, wenn diese Personen Sie dann in ihren Kosten / Bewertungen nicht berücksichtigen.
3. Automatisierung
Bei automatisierten Tests sind synthetische Daten unverzichtbar. Selbst scheinbar unbedeutende Änderungen der Daten können den Betrieb einer ganzen Reihe von Testläufen beeinträchtigen.
Ein Beispiel aus dem Bankensektor soll hier veranschaulichen. Um zu überprüfen, ob die Anwendung die Bankkontonummern in den von ihr erstellten Dokumenten korrekt notiert, haben wir 120 Personen / Stunde damit verbracht, Autotests zu schreiben. Es gab keinen Zugriff auf die Datenbank, da die Kontonummer im Autotest selbst angegeben wurde. Die Tests zeigten hervorragende Ergebnisse und wir waren bereit, im Bericht einen ROI von 180% + aus der Automatisierung zu ziehen. Eine Woche später wurde die Datenbank mit einer Änderung der Kontonummer aktualisiert. Alle Autotests sowie unsere Automatisierungsbemühungen endeten sicher. Nach Überarbeitung der Autotests sank der endgültige ROI auf 106%. Mit dem gleichen Erfolg konnten wir sofort mit unseren Händen mit dem Testen beginnen.
4. Verbesserung der Verwaltbarkeit
Anhand synthetischer Daten wissen wir (im schlimmsten Fall nehmen wir an), welche Art von Reaktion vom System zu erwarten ist. Wenn Änderungen an der Funktionalität vorgenommen werden, verstehen wir, wie sich die Reaktion auf dieselben Daten ändert. Oder wir können die Daten anpassen, um das gewünschte Ergebnis zu erzielen.
In einem der Projekte begann unser Team mit dem Testen anhand realer Daten aus der Kontrahentendatenbank des Kunden. Die Datenbank wurde aktiv verfeinert, aber zu diesem Zeitpunkt wurde sie äußerst nachlässig zusammengestellt. Wir haben Zeit verloren, um zu verstehen, wo der Fehler liegt, in der Funktionalität oder in der Datenbank. Die Lösung war einfach, eine synthetische Datenbank zu erstellen, die kürzer, aber angemessener und informativer geworden ist. Der Test dieser Funktionalität wurde in 12 Personen / Stunde abgeschlossen.
Was sind die Nachteile?
Synthetische Daten scheinen allmächtig zu sein. So ist es, bis Sie auf den menschlichen Faktor stoßen. Synthetische Daten werden absichtlich von Menschen erstellt und dies ist ihr Hauptnachteil. Wir können physisch nicht alle möglichen Szenarien und Kombinationen von Eingabefaktoren durchdenken (und niemand hat höhere Gewalt abgesagt). Und hier bleibt der Vorteil für die realen Daten.
Die Vorteile der Arbeit mit realen Daten
Welche Vorteile sehen wir in der Arbeit mit realen Daten? 4 Beweise aus unserer Erfahrung:
1. Arbeiten Sie mit großen Informationsmengen
Der tatsächliche Betrieb des Systems liefert uns Millionen von Operationen. Wiederholen Sie die gleichzeitige Arbeit von Tausenden von Benutzern oder die automatische Datengenerierung kann kein Team von Spezialisten.
Beweis: Wir haben eine synthetische Minidatenbank erstellt, die, wie es uns schien, alle Kriterien der bestehenden Kundenbasis erfüllt. Mit einer synthetischen Basis hat alles super funktioniert, aber sobald Sie Tests mit einer echten Basis durchgeführt haben, ist alles gefallen. Fazit: Wenn Sie nicht alle Nuancen einer realen Datenstichprobe berücksichtigen können, verschwenden Sie keine Zeit damit, synthetische Daten zu generieren.
2. Verwenden verschiedener Datenformate
Text, Ton, Video, Bilder, ausführbare Dateien, Archive - es ist unmöglich vorherzusagen, was der Benutzer zum Hochladen in das Formularfeld entscheidet. Tipps zu akzeptierten Formaten werden möglicherweise ignoriert, und das Verbot des Herunterladens wird vom Entwicklungsteam möglicherweise nicht umgesetzt. Als Ergebnis werden die gewünschten Szenarien getestet. Beispielsweise ist es im Bereich Sound-Download tatsächlich möglich, eine MP3-Datei herunterzuladen, und das Herunterladen einer ausführbaren Datei schadet dem System nicht. Mit realen Daten können wir Ausnahmen verfolgen.
Beweis: Wir haben das Foto-Upload-Feld im Benutzerprofil getestet. Wir haben die gängigsten Grafikformate aus der Datenbank sowie mehrere Video- und Textdateien ausprobiert. Synthetische Zusammenstellung perfekt geladen. Bei der tatsächlichen Verwendung stellte sich heraus, dass jeder Versuch, eine Audiodatei herunterzuladen, einen Fehler verursacht. Das gesamte Registrierungsformular stürzte ab, ohne dass die Datei ersetzt werden konnte. Auch eine Seitenaktualisierung wurde nicht gespeichert.
3. Unvorhersehbarkeit des Benutzerverhaltens
Obwohl es vielen QS-Spezialisten gelungen ist, Ausnahmesituationen zu schaffen und zu analysieren, seien wir ehrlich - wir werden niemals genau vorhersagen können, wie sich eine Person verhält und welche Faktoren sie umgeben. Sie können mit dem Ausschalten des Internets zum Zeitpunkt des Vorgangs beginnen und mit Vorgängen mit dem Programmcode und den internen Dateien enden.
Beweis: In unserem Unternehmen werden Mitarbeiter jedes Jahr zertifiziert, wo sie unter anderem ihre Fähigkeiten in einem speziellen Fragebogen bewerten. Die Schätzungen werden mit dem Leiter vereinbart, und auf dieser Grundlage wird die Note (Stufe) des Spezialisten berechnet. Vor der Veröffentlichung wurde das Modul vollständig getestet, alles funktionierte wie eine Uhr. Zum Zeitpunkt des Speicherns der Ergebnisse wurde jedoch einmal ein ddos-Angriff auf das System ausgeführt, wodurch nur ein Teil der Daten gespeichert wurde, und nachfolgende Versuche, nur die Fehler zu speichern, duplizierten die Fehler. Ohne eine reale Situation hätten wir einen so schwerwiegenden Fehler nicht aufgespürt.
4. Systemaktualisierungen
Es ist sehr wichtig zu verstehen, wie sich das System während des Upgrades verhält, welche Risiken möglich sind und was möglicherweise nicht abhebt. In Programmen wie 1C, in denen eine große Anzahl von Verzeichnissen und Links vorhanden ist, ist das Problem der Aktualisierungen besonders akut. Und hier wäre die beste Option, eine neue Kopie der Produktionsversion zu haben, das Update darauf zu testen und erst dann veröffentlicht zu werden.
Beweis: Der Fall ist ziemlich häufig. Projekt im Bereich Factoring-Dienstleistungen. Die Kritikalität von Datenverlust und -verzerrung ist überwältigend, und jeder Verdacht auf die Relevanz der vom System reproduzierten Daten kann das gesamte Büro stoppen. Und hier rollt unser Special krumm das nächste Update sofort auf den Prod, ohne die letzten 10 Versionen der Builds zu erfassen.
Sie rollten es um 18.00 Uhr aus und reparierten es am Morgen um 11.00 Uhr. Aufgrund der fehlgeschlagenen Fertigstellung und des Unverständnisses mit den Versionen wurde die Arbeit der Unternehmensbereiche für 2 Stunden vollständig eingefroren. Manager konnten aktuelle Verträge nicht bearbeiten und neue registrieren.
Seitdem arbeiten wir unbedingt mit drei Ständen:- Entwickeln. Hier werden Verbesserungen dargelegt, Anarchie und Gesetzlosigkeit gehen voran, sogenannte Ausnahmetests. QS-Ingenieure arbeiten hauptsächlich mit synthetischen Daten, echte werden selten infundiert.
- Vorabversion. Wenn alle Verbesserungen implementiert und getestet sind, werden sie in diesen Zweig verschoben. Eine Version mit einem Verkauf wird hier ebenfalls vorläufig gerollt. Daher testen wir die Aktualisierung und den Betrieb neuer Funktionen unter bedingten Kampfbedingungen.
- Produktion. Dies ist eine funktionierende Kampfversion des Systems, mit dem Endbenutzer arbeiten.
Also welche Daten und wann arbeiten?
Wir teilen 3 Erkenntnisse unserer Arbeit mit realen und synthetischen Daten:
1. Denken Sie daran, dass die Auswahl des Datentyps von den Zielen und der Testphase abhängt. Bei der Entwicklung eines neuen Systems können wir also nur mit synthetischen Daten arbeiten. Um verschiedene Kombinationen von Eingabebedingungen abzudecken, wenden wir uns meistens auch diesen zu. Die Reproduktion einer kniffligen Ausnahme im Zusammenhang mit dem Benutzerverhalten erfordert jedoch echte Protokolle. Gleiches gilt für die Arbeit mit allgemein anerkannten Verzeichnissen und Registern.
2. Vergessen Sie nicht, Ihre Arbeit mit Testdaten zu optimieren. Verwenden Sie nach Möglichkeit Generatoren, erstellen Sie gemeinsame Register der Hauptentitäten, speichern und verwenden Sie Systemsicherungen rechtzeitig und stellen Sie sie zum richtigen Zeitpunkt bereit. Dann wird die Vorbereitung auf das nächste Projekt für Sie keine Quelle der Melancholie und Finsternis sein, sondern eine der Arbeitsschritte.
3. Gehen Sie nicht auf die Seite fester Kunststoffe, sondern konzentrieren Sie sich nicht auf reale Daten. Verwenden Sie einen kombinierten Ansatz, um Daten zu testen, um Fehler nicht zu verpassen, Zeit zu sparen und maximale Ergebnisse bei Ihrer Arbeit zu erzielen.
Trotz der Tatsache, dass Kunststoffe eine große Zukunft prophezeien und Wissenschaftler in synthetischen Daten eine neue Hoffnung für künstliche Intelligenz gesehen haben, sind Kunststoffe kein Allheilmittel für Tests. Dies ist nur ein weiterer Ansatz zur Generierung von Testdaten, die zur Lösung Ihrer Probleme beitragen und zu neuen führen können. Das Wissen um die Stärken und Schwächen realer / synthetischer Daten sowie die Fähigkeit, diese zum richtigen Zeitpunkt anzuwenden, schützt Sie vor Verlusten, Ausfallzeiten oder rechtlichen Schritten. Ich hoffe, wir haben Ihnen heute geholfen, ein bisschen sicherer zu werden. Oder nicht?
Lassen Sie uns diskutieren. Teilen Sie uns in den Kommentaren Ihre Fälle mit, in denen Sie mit synthetischen und realen Testdaten gearbeitet haben. Mal sehen, wer unter uns mehr ist: Realisten oder Kunststoffe? ;)
Victoria Sokovikova.
Test Analyst im Qualitätslabor