Fragen und Antworten mit Max Saperstone von Coveros: Teil XNUMX - Aufbau einer Teststrategie

In diesem zweiten Teil meines Gesprächs (erster Teil ist hier ) mit Max Saperstone, Director of Test Automation bei AbdeckungenWir erhalten einen Einblick in die Entwicklung einer effektiven Teststrategie und seine Gedanken zu kommerziellen Testautomatisierungstools.

Max hat bei seinen Kunden die gleiche Situation festgestellt wie hier bei Parasoft. Viele Unternehmen stehen vor Herausforderungen beim Testen und beim Zuweisen von Ressourcen zu jeder Testphase. Max schließt sich mit einer Diskussion über seine Einstellung zu kommerziellen Tools und einer zusätzlichen Diskussion über codeloses Testen an.

Teststrategie & die Testpyramide

Mark Lambert: Wenn eine API-Teststrategie vorhanden ist, können Sie Probleme sehr früh im Prozess finden, und eine sehr frühe Isolierung ist offensichtlich das, worauf sich die Branche hinbewegt. Aber wenn ich mit Leuten spreche, beschreiben sie ihre Teststrategie eher als eine Eistüte oder eine umgekehrte Pyramide. Sehen Sie das auch? Und wenn ja, vor welchen Herausforderungen sehen Sie Software-Teams in dieser Situation vom Typ Eistüte?

Max Saperstein: Ich habe alle möglichen Variationen der umgekehrten Pyramide gesehen. Einige sind fast eine Sanduhr, in der unten viel Aktivität und oben viel Aktivität herrscht und in der Mitte wirklich nicht viel.

Das Problem liegt wirklich in den Kosten und der Geschwindigkeit, und ehrlich gesagt fließt die Geschwindigkeit auch in die Kosten ein. Unit-Tests sind kostengünstig und sollten in Sekundenschnelle ausgeführt werden. Diese Unit-Tests sollten wirklich den Boden Ihrer Pyramide ausmachen. Sie sollten relativ billig zu erstellen und relativ billig zu warten sein. Wenn sie keines dieser Dinge sind, schnell und wartbar usw., dann sind sie entweder keine Unit-Tests oder Sie machen nur einen schlechten Job mit ihnen.

Ich arbeite viel mit Entwicklern, Testern und Anforderungsanalysten zusammen. Ich muss verstehen, was wirklich benötigt wird, um in verschiedenen Bereichen getestet zu werden, und dass jeder auf die gleiche Seite kommt. Wenn Sie beispielsweise eine Datenbank testen, handelt es sich nicht mehr um einen Komponententest, sondern um Komponententests. Ich sehe Teams, die eine Reihe von Unit-Tests haben, aber auch viele Integrationstests. Eine schlechte Isolation und komplexe Unit-Tests verlangsamen den Unit-Test-Prozess.

Der Grund dafür, dass Unit-Tests schnell durchgeführt werden sollen, besteht darin, schnell Feedback zu erhalten, noch bevor der Code kompiliert wird. Sie möchten sicherstellen, dass der Code mindestens das tut, was der Entwickler möchte. Denn wenn es nicht das tut, was der Entwickler will, gibt es keinen Grund, weiterzumachen.

Funktionstests, üblicherweise in Form von UI-Tests, sind von Natur aus spröde. Sie sind schwieriger zu pflegen. Warum sollte ein Team mehr davon wollen? Ich gehe in verschiedene Organisationen und sie sagen: "Nun, Automatisierung funktioniert bei uns nicht." Und ich sage: „In Ordnung. Schauen wir uns Ihre Tests an. “ Was ich finde, ist eine Kombination aus drei Dingen: Sie haben zu viele UI-Tests, sie sind zu schwer zu warten und sie sind schlecht geschrieben. Ich sage ihnen, dass sie die Anzahl der UI-Tests reduzieren können, weil all diese anderen Testebenen (Einheit und Komponente) sie unterstützen, und wenn sie diese verbessern, kann ich ihnen helfen, bessere Funktionstests zu schreiben als heute.

Mark Lambert: Sie haben etwas erwähnt, auf das ich zurückkommen möchte, weil ich dieses Problem seit meinem Eintritt bei Parasoft vor 15 Jahren gesehen habe. Wenn jemand sagt: "Ja, ich mache Unit-Tests", aber wenn Sie dort ankommen, machen sie tatsächlich keine Unit-Tests, sondern befinden sich tatsächlich weiter oben in der Pyramide. Wie Sie sagten, bedeutet die Verwendung eines Unit-Testing-Frameworks nicht unbedingt, dass Unit-Tests durchgeführt werden. Warum denkst Du, das ist? Was ist die Herausforderung für jemanden, einen korrekten oder realen Komponententest zu erstellen?

Max Saperstein: Dies ist definitiv kein Einzelfall, den ich an ein oder zwei Orten gesehen habe. Ehrlich gesagt ist es schwierig, einen guten Komponententest zu schreiben, im Gegensatz zu einem Integrations- oder Systemtest. Wenn Sie gute Komponententests durchführen möchten, müssen Sie sich über alles lustig machen, von dem die Einheit abhängt.

Mocks zu schreiben ist nicht einfach. Es erfordert mehr Arbeit; Es erfordert mehr Bibliotheken. Entwickler kämpfen tatsächlich damit; Sie wissen möglicherweise nicht, wie es geht, oder haben möglicherweise nicht die Zeit, es zu tun. Aus diesen Gründen entscheiden sie sich möglicherweise für eine Verknüpfung, um schnell eine Datenbank zu verbinden, z. B. für eine kurzfristige Lösung. Eine Woche später verwenden alle anderen denselben Code und es wird zu spät, ihn zu ändern. Die Antwort darauf, wenn ich auf diese Probleme hinweise, lautet: „Nun, wir schreiben Tests. Das ist besser als nichts. " Und das ist es auch, aber diese Teams kommen schnell an den Punkt, an dem ihre Tests nicht so effektiv sind, wie sie sein könnten.

Ich denke nicht, dass es größtenteils Unwissenheit ist. Ich denke wirklich, in den meisten Fällen ist es eine Zeitkrise. Wenn es darauf ankommt, und das sehe ich in jeder einzelnen Organisation, kümmert sich das Management viel mehr darum, das Produkt aus der Tür zu holen, als darum, die Dinge zunächst richtig zu machen. Diese Teams bauen also technische Schulden auf und kurzfristig gibt es kein Problem damit. Das eigentliche Problem liegt jedoch in der Tatsache, dass diese komplexen, nicht isolierten „Unit-Tests“ immer spröder werden und immer mehr Dinge, wenn sie nicht zurückkommen und die Schulden reduzieren, wenn sie zum Refactor-Code gehen oder etwas ändern fang an zu brechen. Obwohl sie anfangs gute Absichten hatten, verursacht dieser Aufbau von schlechten Tests und technischen Schulden die Probleme, die ich sehe.

Testen Sie die Automatisierungstools

Mark Lambert: Wenn Sie Kunden bei der Bereitstellung ihrer Teststrategie unterstützen und festgelegt haben, wo die Automatisierung angewendet werden soll, müssen sie einige Technologieentscheidungen treffen. Zum Beispiel müssen sie sich entscheiden, ob sie Open Source oder kommerzielle Lösungen verwenden wollen? Oder bauen sie einfach ihr eigenes Framework? Wo empfehlen Sie, den Entscheidungsprozess zu starten?

Max Saperstein: Das ist eine gute Frage, Mark. Und das ist tatsächlich eine der Fragen, die mir am häufigsten gestellt werden: Welches Tool soll ich verwenden? Welches Framework soll ich verwenden? Der Client beginnt normalerweise mit der Automatisierung oder dem Einstieg in API-Tests. Leider lautet die Antwort, die ich immer gebe, "Oh, ich weiß nicht", weil mir der erste Ansatz des Tools nicht gefällt.

Ich mag es wirklich, wenn meine Kunden einen Schritt zurücktreten und über ihre Anforderungen nachdenken. Was betrachten sie aus Sicht der Testergebnisse und der Rückverfolgbarkeit? Was versuchen sie zu erreichen? Welche Ebenen der Testpyramide sollen die Werkzeuge unterstützen? Testet es nur auf der Benutzeroberfläche, API, Unit-Tests? Was ist die allgemeine Teststrategie?

Sobald ich all diese Fragen beantwortet habe. Dann werde ich einige der Frameworks und Tools untersuchen, die es auf dem Markt gibt, und Entscheidungen treffen, die auf der Untersuchung der Kundenanforderungen basieren. Ich empfehle immer, zuerst ein Open Source-Tool zu verwenden. Ich bin ein großer Fan davon, Dinge so agil wie möglich zu machen, und ein großer Teil davon ist das Experimentieren. Wie Sie wissen, ist das Scheitern manchmal ein Teil des Experimentierens. Möglicherweise finden Sie das richtige Werkzeug, und es funktioniert anfangs möglicherweise einwandfrei oder nicht. Wenn Sie für diese Tools Geld bezahlen müssen, kann das Experimentieren teuer werden und Sie erhalten möglicherweise nicht das, was Sie wollen.

Nach dem Experimentieren mit Open Source-Tools empfehle ich meinen Kunden, sich kommerzielle Tools mit kostenlosen Testzeiträumen anzusehen, um zu versuchen, die Dinge zu überprüfen. An dieser Stelle empfehle ich, dass sie anfangen, kommerzielle Analysen genauer zu analysieren.

Bei der Betrachtung von Open Source-Tools ist vor allem die Unterstützung zu berücksichtigen. Es gibt verschiedene Open-Source-Frameworks und -Tools, und nur weil sie kostenlos sind, heißt das nicht, dass sie Müll sind, aber es bedeutet auch nicht, dass sie auch gut sind. Zum Beispiel gab es ein Stigma um Selen und die Leute fragten sich, ob ein kostenloses Werkzeug etwas Gutes sein kann. Jetzt gibt es eine riesige Community, die dazu beiträgt, und es ist das Automatisierungstool Nummer eins für UI-Tests, obwohl Sie es einfach kostenlos herunterladen können.

Für Open-Source-Tools ist es wichtig zu wissen, welche Unterstützung es gibt. Es ist auch eines der wichtigsten Dinge, die gute Open Source-Projekte auszeichnen. die Community-Unterstützung. Sie stellen Fragen, die Leute bekommen relativ schnell Antworten. Selen hat eine Vielzahl von Menschen, die sich dort der Beantwortung von Fragen widmen. Eine solche Community-Unterstützung, egal ob es sich um kostenpflichtige oder kostenlose Tools handelt, ist wirklich wichtig.

Eine Gefahr bei Open Source-Tools besteht darin, dass ein Fehler oder ein Verwendungsproblem auftreten kann und das Projekt abgebrochen wird, obwohl dies auch bei kommerziellen Tools passieren kann. Wenn ich meine Tests jedoch nicht portabel gemacht habe, ist dies ein Problem, das ich erstellt habe.

Alle diese verschiedenen Tools und Ansätze haben Kompromisse, wenn Sie sie betrachten. Mit der angemessenen Unterstützung und Unterstützung macht das für mich die Open-Source-Community immer ein bisschen wertvoller.

Kommerzielle Werkzeuge

Markus Lambert: Wenn Sie Bedenken hinsichtlich der Lieferantenbindung haben, suchen Sie nach einer Technologie, mit der Tests problemlos zwischen verschiedenen Frameworks portiert werden können? Mit anderen Worten, ist ein kritischer Aspekt bei der Bewertung kommerzieller Lösungen die Fähigkeit, zwischen Tools zu wechseln und sicherzustellen, dass Sie nicht an deren Plattform gebunden sind?

Max Saperstein: Ja, es kommt wirklich darauf an. Für viele Anbieter ist die Unterstützung der Austauschbarkeit eine gute Sache, und für einige Tools funktioniert sie sehr gut. Wenn Sie jedoch zum ersten Mal experimentieren, möchten Sie nicht unbedingt mit kommerziellen Tools beginnen. Es ist schmerzhaft, wenn ich sechs verschiedene Testsuiten neu schreiben muss, um sechs verschiedene Software-Teile auszuprobieren.

Markus Lambert: Also, Open Source zuerst, bis Sie gegen eine Wand stoßen, und dann nach etwas suchen, das Ihnen vielleicht helfen kann, über diese Wand hinauszugehen?

Max Saperstein: Wahrscheinlich. Es gibt viele verschiedene Lösungen mit einer kostenlosen Version oder einem „Freemium“ -Modell, bei denen Sie zusätzlich für zusätzliche Funktionen bezahlen. Darüber hinaus gibt es auch kostenpflichtige Versionen. Viele dieser Tools gefallen mir sehr gut, denn wenn ich sie mir einmal anschaue, wird mir klar, dass ich all diese coolen Dinge tun kann. Für mich lohnt es sich oft, denn wenn das Tool über die richtigen Funktionen verfügt und ich einen Großteil meiner Entwicklung im Voraus durchführen kann, benötige ich nur ein oder zwei Lizenzen, um die Tools während der Erstellung auszuführen. Das ist gar nicht so schlecht.

Auch hier kommt es auf das technische Niveau des Teams an. Das Schöne an bezahlten Produkten ist, dass sie normalerweise Support für Sie bereithalten. Wenn das Team technisch nicht so gut mit Testwerkzeugen umgehen kann und mehr Unterstützung benötigt, ist diese verfügbar. Bei den Produkten von Parasoft ist Support eines der Dinge, für die Kunden bezahlen, was strategisch sehr sinnvoll ist.

Codeloses Testen

Mark Lambert: Wenn Sie Ihren Kommentar zu nicht-technischen Benutzern ansprechen, z. B. zu jemandem, der mit der Codierung von Selen nicht vertraut ist, wären codelose Testtools eine Lösung? Was bedeutet dieses codelose Testen für Sie? Was sind deine Gedanken?

Max Saperstein: Ich sehe zu diesem Zeitpunkt seit ungefähr fünf Jahren codelose Testautomatisierungstools. Ich denke zurück, als ich zum ersten Mal auf sie aufmerksam gemacht wurde, waren sie wirklich schlau. Ich mag es, dass sie viele Dinge relativ einfach machen können und einige von ihnen über den codlosen Aspekt hinausgehen. Mit einigen Tools können Sie bei Bedarf eintauchen und beispielsweise in Java oder Python schreiben. Die Fähigkeit zum codelosen Testen und die Fähigkeit, bei Bedarf Code hinzuzufügen, ist wichtig, wenn Sie weniger technische Teams haben.

In meinen Augen hat jeder einzelne Werkzeugtyp Kosten. Sie müssen mehr für Leute bezahlen, die einen Codierungshintergrund haben, und weniger Geld für weniger technische Tester. Dies könnte jedoch durch die Technologie ausgeglichen werden und etwas mehr für die Unterstützung der Anbieter zahlen. Daher denke ich, dass codeloses Testen wirklich eine großartige Lösung dafür bietet.

Die große Herausforderung, die ich sehe, ist, dass es in diesem Bereich viele verschiedene Spieler gibt. Ich habe nicht wirklich gesehen, wie ein Anbieter einem anderen vorausgezogen hat. Anbieter scheinen immer noch einen kleinen Halt zu haben. Dies bedeutet zwar, dass es definitiv einen Wachstumsmarkt für Testautomatisierungstools gibt, diese Tools lösen jedoch möglicherweise nicht die Hauptprobleme, die wir im Bereich Testautomatisierung haben.

Ich habe bereits erwähnt, dass es zwei Dinge gibt, die ich normalerweise als Probleme betrachte: Teams verbringen zu viel Zeit damit, ihre Tests aufrechtzuerhalten, weil sie spröde sind und brechen. Das andere ist, dass die Leute schlechte Tests schreiben. Dies waren meiner Meinung nach die Hauptschmerzpunkte der Testautomatisierung im Allgemeinen. Ich glaube nicht, dass die codelose Automatisierung diese Probleme tatsächlich angeht. Sie machen es viel einfacher, Tests zu schreiben, aber ich denke nicht, dass dies das häufigste Problem ist. Diese Tools erleichtern es möglicherweise, denselben schlechten Test zu schreiben.

Viele dieser Probleme und der mangelnde Erfolg bei der Automatisierung gehen auf das Fehlen einer Teststrategie zurück. Ich denke, Tools und Automatisierung sind noch nicht wirklich explodiert, sie lösen definitiv Probleme, aber sie lösen nicht das größte Problem im Raum.

Im nächsten Beitrag sprechen wir mit Max über seine Erfahrungen mit Fehlern und Erfolgen beim Testen und bei der Testautomatisierung.