Fragen und Antworten mit Max Saperstone von Coveros: Teil Drei – Erfolg und Misserfolg mit Testautomatisierung

In diesem dritten Teil meines Gesprächs (lesen Teil eins und Zweiter Teil) Mit Max Saperstone, Director of Test Automation bei Coveros, besprechen wir Erfolge und Misserfolge, die er mit der Testautomatisierung erlebt hat.

Max fand eine ähnliche Erfahrung wie auf dem Markt: Schlechte Planung und mangelndes Buy-In auf allen Ebenen sind kein gutes Umfeld für den Erfolg. Wenn der ROI der Automatisierung jedoch gut formuliert ist, ist der Erfolg wahrscheinlicher. Werfen wir einen Blick auf Max 'Erfahrungen in diesem Bereich.

Testautomatisierung: Erfolg und Misserfolg

Markus Lambert: Lassen Sie uns diese Diskussion mit zwei letzten Fragen abschließen. Die erste Frage ist, geben Sie mir ein Beispiel, in dem Sie in eine Organisation gegangen sind, um ihnen bei der Testautomatisierung zu helfen, und es war ein Erfolg. Was war der Grund, warum es gut lief und etwas, das Ihre Augen in einem Moment der Glühbirne öffnete?

Max Saperstein: Interessante Frage. Eines der Beispiele, die mir besonders auffallen, ist, als ich zu einer Organisation ging, die eine ganze Reihe manueller Tests durchführte. Viele ihrer Tests bestanden darin, Daten einzugeben und Formulare zu validieren. Ihre Herausforderung bestand darin, Wochen damit zu verbringen, ihr System aufgrund der Komplexität und der unterschiedlichen Kombinationen von Eingaben zu testen, die zum Testen der Anwendung erforderlich sind. Sie wussten sogar, dass sie nicht alles abdeckten.

Wir setzten uns mit ihnen zusammen und sprachen über Anforderungen und alles, was sie suchten. Sie sagten: „Weißt du was? Ehrlich gesagt, wir wissen es nicht. “ Wir haben unter anderem die Postleitzahlen manuell eingegeben und die Anwendung hat verschiedene Benutzer zurückgemeldet. Für jeden zurückgegebenen Benutzer musste eine weitere Abfrage durchgeführt werden, um sicherzustellen, dass die Informationen korrekt waren.

Wir haben einige Skripte für sie erstellt und ausgeführt, und es stellte sich heraus, dass es sich um eine dreiviertel Million verschiedene Kombinationen handelte. Es dauerte ungefähr acht Stunden pro Nacht, um alle diese Tests durchzuführen. Sie sahen sich die Daten an und wir fragten: „In Ordnung. Was machen wir damit? " Sie sagten: "Wir haben keine Ahnung."

Wir wussten, dass all dieses Zeug in ihrer Datenbank war, aber wir konnten es nicht testen. Also hat sich tatsächlich jemand mit diesen Daten hingesetzt und es hat wahrscheinlich über einen Monat gedauert. Sie kamen schließlich zurück und sagten: „Wir haben alles durchgesehen und all diese Daten analysiert. Es ist nicht alles richtig. " Sie fanden 30 oder 40 verschiedene Diskrepanzen, aber die Tatsache, dass sie diese nie zuvor tatsächlich gefangen hätten - sie machten im Wesentlichen Zufallsstichproben.

Was wir tun konnten, war, diesen Datensatz zu nehmen und - anstatt diese Ausgaben zu skripten - sie in Tests umzuwandeln. Es dauerte immer noch die ganze Nacht, aber sie verbrachten keine Wochen damit, Ergebnisse mit schlechter Abdeckung zu analysieren. Diese neuen Tests bestätigten, dass alle Ausgaben tatsächlich korrekt waren und die Organisation weiterhin neue Kunden zu ihrer Datenbank hinzufügen konnte, ohne dass der Aufwand für das Testen der Ergebnisse aufgewendet werden musste.

Wir haben nicht nur Fehler gefunden, diese neue Automatisierung hat es dem Kunden ermöglicht, tatsächlich alles im Auge zu behalten. Für mich war das ein großer Erfolg. Die Kombination von Automatisierung und intelligentem manuellen Aufwand sparte viel Zeit und Mühe. Ein weiterer Erfolg bestand darin, Fehler zu finden, die sich absolut auf das Unternehmensergebnis auswirken würden, wenn sie im Endprodukt landen würden.

Markus Lambert: Sie haben also eine vollständige Testabdeckung erhalten, indem sie einen gesamten Datensatz genutzt haben? Anstatt nach dem Zufallsprinzip zu versuchen, Fehler zu finden.

Max Saperstein: Ja schon. Wiederum war es eine vollständige Abdeckung eines Bereichs der Anwendung. Aber es war der Einsatz von Automatisierung, der so cool zu sehen war. Dies war jedoch ein teures Unterfangen, und wenn ein Kunde wirklich möchte, dass wir alles, was wir haben, auf das Problem werfen, werden wir es tun. In diesem Fall war es ein großer Aufschwung für unseren Kunden, und am Ende stellte sich heraus, dass es sich für sie gelohnt hat, was gut war.

Mark Lambert: Okay, letzte Frage. Was ist mit einem Beispiel, bei dem das Projekt völlig schief gelaufen ist? Was hat dazu geführt, dass diese Implementierung schief gelaufen ist? Was haben wir gelernt?

Max Saperstein: Ich habe damals mit einem anderen Unternehmen zusammengearbeitet als heute, und ein Kunde hat uns hinzugezogen und gesagt: „Wir brauchen Sie wirklich, um unsere Tests zu automatisieren. Wir haben all diese manuellen Tester, die Wochen damit verbringen, ihre Regressionstests durchzuführen. Was wir wirklich brauchen, ist, diese Tests zu automatisieren und die Testzeit zu verkürzen. “

Dies ist eine Weile her und naiv sagte ich: "Sicher." Ich fing an, das Problem zu untersuchen, einige Tests zu schreiben und mit den manuellen Testern zu sprechen, um herauszufinden, wofür sie die meiste Zeit verbrachten. Nach ein oder zwei Monaten hatte ich eine anständige Reihe von Tests und übergab diese den Testern.

Ich sagte: „Hier, du gehst. Sie müssen keine manuellen Tests mehr durchführen. Diese automatisierten Tests untersuchen einige Bereiche der Anwendung für Sie. “

Was geschah, war, dass die Tester diese automatisierten Tests nicht ausführten - oder sie würden sie ausführen, aber sie würden sie dann manuell erneut ausführen. Wie ich erfuhr, war ein Grund dafür, dass sie nicht ausgeführt wurden, dass die Tester sich nicht darum kümmerten, sie auszuführen. Sie vertrauten ihnen nicht unbedingt. Sie sahen nicht den Wert, den sie aus der Automatisierung herausholten. Auch die Art und Weise, wie die Tests erstellt wurden, waren keine vollständigen End-to-End-Tests, an die die Tester gewöhnt waren. Bei den Tests wurden Teile der Anwendung ausgeführt, die sie benötigten, aber die Tester mussten noch viele andere Schritte durchlaufen, um die erforderliche Abdeckung zu erhalten.

Am Ende sagten sie: "Nun, wenn ich diese manuellen Tests durchführen muss, sparen wir nicht wirklich so viel Zeit." Der Kunde hat diesen Wert, der ihm hinzugefügt wurde, einfach nicht gesehen. Ich denke, das Hauptproblem für dieses Projekt war wirklich die Kommunikation. Wir haben herausgefunden, wofür die Tester viel Zeit aufgewendet haben, aber wir haben nicht mit ihnen darüber gesprochen, wie sie die Software getestet haben und was sie automatisieren möchten. Wir mussten sie fragen: "Wenn Sie absolut alles tun könnten, was wäre das?"

Wir haben uns zu sehr auf Best Practices konzentriert. Das Problem war, dass diese Praktiken und die von uns automatisierten Tests nicht in ihren gesamten Qualitätsworkflow passten, was sie wirklich brauchten, um einen Teil der Zeit für die Qualitätssicherung zu verkürzen.

Ich denke, wir hätten über eine Strategie auf höherer Ebene sprechen und ein besseres Gefühl dafür bekommen sollen, was wir hätten tun können, um die Anzahl der manuellen Tests sofort zu reduzieren. Wir hätten fragen sollen, was wir tun könnten, damit die Tester wirklich begeistert wären, wenn sie versuchen würden, es zu verwenden? Oder sogar, was ist ihrer Meinung nach sinnvoll zu automatisieren und mit welcher Technologie waren sie vertraut?

Es stellte sich heraus, dass einige der Tester nicht einmal auf ihrem Computer auf "Los" klicken wollten, um einen automatisierten Test durchzuführen. Andere waren jedoch mit der Automatisierung vertraut und erhielten jeden Morgen einen Bericht per E-Mail mit der Aufschrift: „Das lief, das ist erledigt.“ Diese Diskussionen wurden leider nicht früh geführt.

Also gingen wir zurück und wiederholten dieses Projekt. Aber es gab definitiv viel Aufwand im Voraus, der durch weitere Diskussionen über diese hochrangige Teststrategie hätte eingespart werden können. Und das geht auf den ersten Kommentar zurück, über den wir gesprochen haben.

Markus Lambert: Ohne Planung und ohne Buy-In von den Teams gibt es also kein Vertrauen und keinen wahrgenommenen Wert. Sie springen blind in die Testautomatisierung, was nicht wirklich geholfen hat.

Max Saperstein: Genau. Es ging um Testautomatisierung, um der Testautomatisierung willen, anstatt wirklich zu bestimmen, was der wahre Wert ist und wie wir das Beste daraus machen können.

Mark Lambert: Großartig. Vielen Dank, Max. Schätzen Sie wirklich die Zeit damit. Ich denke, das war eine großartige Diskussion.