Automatisiertes Testen: Erklären des Geschäftswerts

25

So starte ich glaube nicht , das ist eine Wiederholung von Fragen auf Unit - Tests . Was ich brauche, ist Hilfe, um seinen Wert einem Team von Programmierern, Analysten, Managern und Testern zu vermitteln. Bei automatisierten Tests muss ich meines Erachtens nicht zwischen Komponententests (z. B. JUnit), BDD (z. B. JBehave, Fitness) und UI (Selen, Watir) unterscheiden, da ich denke, dass sie alle einen ähnlichen Wert haben (aber es steht mir frei, dies zu tun) schreibe eine Antwort, die nicht einverstanden ist :))

Das Folgende ist eine Liste, die ich identifiziert habe. Ich suche nach Antworten, die helfen, sie zu erweitern oder zu verfeinern:

  1. Zeit- / Kostenersparnis : Das Schreiben von automatisierten Tests kann mehr Zeit in Anspruch nehmen als das Schreiben von Testfällen. Angesichts der Tatsache, dass Tests mehrmals ausgeführt werden, ist der Grenzaufwand (dh Kosten / Zeit) für die Ausführung automatisierter Tests jedoch um mehrere Größenordnungen geringer. Die Tatsache, dass die automatisierten Tests kostengünstig sind, erleichtert das Ändern des Systems im Laufe der Zeit.
  2. Dokumentation : Es gibt keinen besseren Weg zu wissen, wie ein System funktioniert als seine Tests. Jede andere Dokumentation ist normalerweise nicht mehr aktuell, aber Tests (zumindest die, die bestanden wurden) zeigen, wie die Dinge tatsächlich funktionieren. Dies gilt sowohl für die Endbenutzer- als auch für die API-Dokumentation.
  3. Code-Qualität : Testschreiben zwingt Sie zu:
    • Betrachten Sie Kunden, weil Tests ein Kunde sind
    • Bricht Abhängigkeiten auf, bei denen das Testen von Code oft bedeutet, herauszufinden, wie dieser Code erstellt werden kann, ohne dass ein anderes großes System verfügbar sein muss
Orangepips
quelle

Antworten:

21

Einige meiner Gedanken:

  1. Seien Sie ehrlich, dass das Schreiben automatisierter Tests länger dauert. Wenn Sie TDD auf Einheitenebene ausführen (was ich als Ausgangspunkt für Investitionen in automatisierte Tests empfehlen würde), müssen Sie mit einer zusätzlichen Zeit von ca. 30% rechnen, um eine Funktion zu codieren. Der Schlüssel hier ist zu erklären, dass diese zusätzlichen 30% (wahrscheinlich mehr als 30% am Anfang, wenn Ihr Team lernt, wie man gute Tests schreibt) eine Investition sind, die im Laufe der Zeit Kosten spart. Wie bei TDD auf Geräteebene ist das Design Ihres Systems lose gekoppelt und sehr zusammenhängend, wodurch Ihr System an zeitliche Veränderungen angepasst werden kann. Neue Anforderungen und unerwartete Fehler erfordern immer Änderungen an Ihrem System.
  2. In Anbetracht der Zeit, die zum Schreiben dieser Tests benötigt wird, wie lange sie ausgeführt werden und wie viel Wartung sie erfordern, wird viel über den Wert von Tests auf Akzeptanz- und Benutzerschnittstellenebene diskutiert. Ich würde empfehlen, diesen Artikel von James Shore darüber zu lesen .
  3. In der Welt des automatisierten Testens gibt es gute und schlechte Möglichkeiten, dies zu tun. Wenn Sie Ihr Management mit automatisierten Tests beauftragen, würde ich Ihnen auch erläutern, wie Sie Ihr Team darin schulen möchten, gute Tests zu schreiben. Die Art of Unit Testing von Roy Osherove, das effektive Arbeiten mit Legacy-Code von Michael Feathers, und The Art of Agile Development von James Shore sind großartige Bücher, die sich direkt oder indirekt mit diesen Themen befassen. Sie sollten sich auch eine Art Trainer oder ein formelles Training ansehen. Es ist eine große Veränderung.
  4. In Bezug auf den Geschäftswert dienen die Punkte 2 und 3 oben tatsächlich Ihrem ersten Punkt. Daher würde ich Punkt 1 hervorheben und darüber sprechen, wie die Punkte 2 und 3 diesem größeren Punkt dienen. Die Dokumentation macht Ihr System verständlicher, wodurch Ihr Team schneller arbeitet. Die Codequalität macht Ihr System anpassungsfähig, sodass Ihr Team schneller arbeiten kann. Für Geschäftsleute dreht sich alles um die Maximierung des Werteflusses von der Idee bis zur Lieferung der Idee als funktionierende Software.
Brian Geihsler
quelle
1
+1 gute Antwort. Interessanter Link zum Artikel von James Shore. Ich würde The Clean Coder von Robert Martin zu Ihrer Buchliste hinzufügen . Ich denke, dass von Entwicklern erstellte UI-Tests zufriedenstellende Pfade abdecken sollten, während die Qualitätssicherung (falls vorhanden) Ausnahmen schreibt. Unit-Tests sollten sich wirklich mit den Ausnahmefällen befassen.
Orangepips
@orangepips - Danke für die Buchempfehlung. Ein Nachteil dieser UI-Tests ist, dass es schwieriger ist, diese Unit-Tests zu schreiben, wenn Sie nicht für alles Unit-Tests durchführen. Unit-Tests verbessern die Testbarkeit Ihrer App, indem sie die Kopplung gering halten, während bei UI-Tests nicht erforderlich ist, dass der Code darunter lose gekoppelt ist.
Unit Tests sollten alles abdecken.
Orangepips
1
@orangepips - Ich stimme nicht zu. "QA-Level" / Akzeptanztests sollten alles testen, was für den Benutzer wichtig ist, dh glückliche Wege und alternative Szenarien. Unit-Tests verwenden häufig Mocks, Stubs und Fakes. Dies bedeutet, dass der Happy-Path-Unit-Test möglicherweise bestanden wird . Wenn jedoch alle Komponenten zusammengeführt werden, schlägt der Happy-Path-End-to-End-Test möglicherweise fehl. Es ist eine zu große Chance, dem Schicksal überlassen zu werden.
Gishu
2
@orangepips - Mein Einwand bezog sich auf die QA / Dev Exceptions / Happy Divide. Unit-Tests stellen sicher, dass Sie alles richtig machen. Es gibt QS- / Abnahmetests, um sicherzustellen, dass Sie das richtige System erstellen. Daher sollten alle für das Unternehmen relevanten Szenarien (z. B. abgelaufene Kreditkarte) von der Qualitätssicherung getestet werden, bevor sie als versandbereit gekennzeichnet werden. Ich empfehle die Automatisierung von Abnahmetests - Automatisieren Sie mühsame Routinearbeiten zu über 80%. Runden Sie das Ganze mit ein paar fantasievollen manuellen Tests ab, die nicht über Skripte erfolgen.
Gishu
9

Eine Sache von definitivem Wert ist, dass automatisierte Tests kontinuierlich ausgeführt werden können; wie jede stunde auf einen umbau oder ähnliches. Dadurch werden Bugs oder Regressionen innerhalb von Stunden oder Tagen, nachdem ein Programmierer an dem fehlerhaften Code gearbeitet hat, schnell ans Tageslicht gebracht. Dies erleichtert das Wechseln des Kontexts erheblich. Der zweite Vorteil kontinuierlicher Tests besteht darin, dass Sie gezwungen sind, Ihre Tests in einem funktionierenden Zustand zu halten. Nichts ist langweiliger, als die erste Woche eines Testzyklus damit zu verbringen, alle veralteten Tests zu reparieren. Wenn Sie sie automatisieren können, können Sie sie jederzeit ausführen. Wenn Sie sie regelmäßig ausführen, können Sie Fehler in Ihren Tests oder im Code schnell erkennen.

TafT
quelle
7

Testaufwand

Sobald ein automatischer Test geschrieben wurde, kann er auf Kosten einiger Joule von einem Computer ausgeführt werden. Für den entsprechenden manuellen Test muss eine Person auf der Gehaltsliste eine Liste mit Anweisungen erstellen.

Zuverlässigkeit testen

Dem Computer kann vertraut werden, dass er jedes Mal den gleichen Testvorgang ausführt. Der Mensch neigt dazu, Fehler zu machen und faul zu werden.

Die Testfehler-Modi des Computers sind auch viel leichter zu erkennen - er ist abgestürzt (Testberichte werden nicht mehr angezeigt), es ist ein Fehler aufgetreten, der zu einem falschen Testergebnis geführt hat (führen Sie einen deterministischen Test erneut durch, und das Ergebnis ist unterschiedlich). Wenn ein Mensch einen Schritt verfehlt und das "OK" abhakt, wie können wir das erkennen?

Haltbarkeit testen

Ein automatisierter Test muss ein konkretes Artefakt (z. B. ein Stück Code) sein, um ausgeführt werden zu können, und ist natürlich in den anderen Softwareentwicklungsartefakten enthalten - dem Quellrepository. Ein manueller Test kann von einem Tester auf einem Blatt Notizpapier entwickelt und niemals formalisiert werden. Es ist wahrscheinlicher, dass das Unternehmen Prozesse benötigt, um sicherzustellen, dass dies nicht geschieht.

Testwert

Der Computer kann so programmiert werden, dass Testergebnisse in einer konsistenten, einfach zu analysierenden Form ausgegeben werden. Die Person führt entweder eine Dateneingabe durch, um dasselbe zu generieren, oder sie zeichnet Freiformnotizen auf, für deren Verdauung ein Analyst, Entwickler oder Manager erforderlich ist.

Phil Miller
quelle
+1 für den Begriff der Berichterstattung und zum Referenzieren von Joules.
Orangepips
"Es kann davon ausgegangen werden, dass der Computer jedes Mal das gleiche Testverfahren zuverlässig ausführt." Es sollte nicht vergessen werden, dass einige Fehler von Personen festgestellt werden, die Dinge auf unerwartete Weise tun. Sehr oft führt ein anderer Tester den gleichen Befehlssatz auf andere Weise aus. Dies ist eine gute Sache, da dadurch die Testabdeckung erhöht wird. Die Testautomatisierung spart zwar Zeit und ist eine hervorragende Möglichkeit, auf erwartete Fehler und Rückschritte zu prüfen. Sie kann jedoch menschliche Tests nicht vollständig ersetzen.
In diesem Fall ist es vorzuziehen, den menschlichen Testern allgemeine Listen der zu untersuchenden Gebiete und der zu testenden Dinge und keine detaillierten Anweisungen zu geben, die sie getreu wiederholen sollten.
Phil Miller
4
@TafT: Nur die Armen oder Törichten verzichten auf manuelle Tests, aber die wertvollsten manuellen Tests sind meines Erachtens eher explorativ als in der Natur geschrieben. Also der Drang, das zu automatisieren, was sein kann.
Orangepips
5

Meistens (abhängig von Ihrer Testabdeckung) fehlerfreier Code, und ich würde sagen, eines der größten Argumente ist, wenn Sie Ihrem Manager sagen, dass Sie einen Test für einen entdeckten Fehler schreiben können, um sicherzustellen, dass Sie in Zukunft immer wissen, ob dieser Fehler kommt zurück :)

Meiner Meinung nach sind Unit- / Integrationstests am wichtigsten, wenn Sie jedoch ein UI-Muster wie MVC anwenden, ist dies für die meisten Projekte ausreichend. Normalerweise teste ich alle Aktionen auf meinen Controllern / Präsentatoren und überlasse die Datenbindung den Ansichten.

Natürlich ersetzen automatisierte Tests nicht das gute alte "Point-and-Click" -Abenteuer in Ihrer Anwendung, bei dem Versuch, die wildesten Dinge herauszufinden, die Ihr Benutzer tun könnte.

Es gibt auch einen Punkt der kontinuierlichen Integration .

Eine weitere Sache - man muss sich bemühen, dass Codequalität zu Produktqualität, Geschäftswert und Wartbarkeit führt - sonst macht es keinen Sinn, dies zu tun.

Denis Biondic
quelle
+1 für Continuous Integration aus technischer Sicht. Ich bin mir jedoch nicht sicher, wie ich sehe, dass Ihre Vorschläge ein Gespräch mit nicht-technischen Mitarbeitern (z. B. Analysten) erleichtern. Was halten Sie von der Überprüfung in mehreren Browsern und Betriebssystemen?
Orangepips
Nun, ich kann meine Seite aus Sicht des Entwicklers nur über die Analysten erzählen - ich verstehe ihre Rollen in wirklich großen Projekten nicht ganz - also keine wirklichen Ratschläge. Über die browserübergreifenden Cross-OS-Tests hatte ich auch keine Chance dazu.
Denis Biondic
2

Ich denke, Sie sollten mit den magischen Punkten "niedrigere Kosten" und "mehr Funktionen / Zeiteinheit" / kürzere Zykluszeit führen.

Bevor ich jedoch eine Sache vorbringe, rate ich Ihnen, über Ihre Situation nachzudenken. Ihre Frage hat mich dazu veranlasst, einen Blog-Beitrag über die möglichen Nachteile des automatisierten Testens zu schreiben .

Gishu
quelle
+1 für einen guten Blog-Beitrag, auch wenn diese Punkte hier gut angesprochen würden. Es scheint mir das Hauptanliegen zu sein, keine Programmierer zu haben, die nur die Bewegungen durchgehen. Wie schlagen Sie zu diesem Zweck vor, die Qualität zu fördern oder zumindest eine Atmosphäre zu vermeiden, die dies verhindert?
Orangepips
guter Link. Die Reifung eines Softwareprozesses erfordert viel Arbeit. Ich denke, dass die wichtige Konsequenz auch darin besteht, den Umsatz zu reduzieren, sodass Sie über genügend Mitarbeiter mit Organisationsgedächtnis und Vertrauen verfügen , um so etwas voranzutreiben.
orangepips
1

Einfaches Refactoring spielt hier eine große Rolle. Wenn Sie eine gute Abdeckung durch einen schönen und LESBAREN (!!!) Komponententest haben, können Sie Ihr System umgestalten, ohne die bestehende Funktionalität zu gefährden.

Morten
quelle
Unterscheidet sich dies von meinem Punkt # 1?
Orangepips
@orangepips: Nein, ich habe diesen Teil verpasst. Sorry: o) Trotzdem ist es wichtig zu betonen
Morten
1

Sie müssen das Konzept verkaufen - Sie müssen vermeiden, ihnen mitzuteilen, dass es den Code verbessert. Wenn sie eine Investition in den Code haben, werden sie sofort gegen Sie / Auto-Tests gestellt. Wenn sie gut sind, verstehen sie auch GIGO und verstehen nicht, warum Sie denken, dass es nicht zutrifft.

Ich würde es auch als Dokumentationsaspekt auslassen, Dinge wie Fitnesse können es gut machen, aber bis sie erfahren haben, könnte es schwierig sein, es zu visualisieren.

Bereiche, von denen ich denke, dass sie Glück haben könnten, wenn man sie weiterverkauft

  1. Komponententests können den Platz vieler Entwicklertests einnehmen - hier erstellen Sie Anwendungen, um in den Bereich zum Debuggen / Testen zu gelangen, ohne alle Anmeldungen / Menüs durchlaufen zu müssen.

  2. Mit Tests können Sie problemlos Problemsituationen einrichten und wiederholen - ohne viel Zeit mit dem Einrichten von Testdaten zu verbringen (insbesondere mit einem anständigen Verspottungssystem).

  3. Wenn Sie eine Reihe von BDD- und UI-Tests aufbauen, erhalten Sie eine viel schnellere Antwort, wenn es einfache Pausen gibt, als auf das nächste Mal zu warten, wenn der Tester es sich ansieht

  4. Durch BDD- und UI-Tests können Sie vermeiden, dass Sie wiederholt auf Schaltflächen drücken, um alle Aspekte zu überprüfen, die möglicherweise von Ihrer Änderung betroffen sind, und sich nicht alle Bereiche merken müssen.

  5. Automatische Builds werden oft hervorgehoben, wenn jemand vergessen hat, Code einzuchecken

  6. Tests helfen Ihnen dabei, das Wiederauftreten von Fehlern zu vermeiden.

  7. Unit Tests und anständige Verspottungen bedeuten weniger miteinander verknüpften Code und sind einfacher zu lösen

Denken Sie daran, dass Sie versuchen, es zu verkaufen, und sie nicht in eine Religion umzuwandeln. Akzeptieren Sie also kleine Schritte und versuchen Sie, sie nicht gegen Sie aufzubringen. Es wird auch einige Zeit dauern, bis sie sich anpassen und lernen, gute Tests zu schreiben.


quelle
+1 für den Religionskommentar. Ich denke, man muss herausfinden, wofür es sich lohnt, automatisierte Tests zu schreiben, und die Antwort ist nicht alles. OTO, ich denke, wir sind besser dran, wenn wir zumindest ein paar automatisierte Tests durchführen. Vielleicht ist der eigentliche Schlüssel darin zu erkennen, dass zumindest in meiner Organisation der SDLC-Engpass die Qualitätssicherung ist. Meine eigene Anstrengung zielt darauf ab, diese Anstrengungskurve zu glätten, indem die Entwicklung einen Teil dieser Verantwortung übernimmt.
Orangepips
In Bezug auf Nummer 3) können Sie so Statistiken erstellen und Berichte erstellen. Sichtbar kann ein großes Verkaufsargument sein. Die Einführung von Feature X in dieser Woche hat dazu geführt, dass 10 Tests fehlgeschlagen sind. Dies ist ein schöner Gewinn für ein Projekt und hilft auch dabei, die Risiken der Einführung neuer Features in der Zukunft zu dokumentieren.
1

Jemand muss glauben, dass es ein Problem gibt, bevor er eine vorgeschlagene Lösung für dieses Problem akzeptiert.

Durch automatisierte Tests können Fehlerbehebungskosten gespart werden. Wenn Ihre Kollegen nicht glauben, dass die Kosten für die Fehlerbehebung beträchtlich oder übermäßig sind, sind sie schwer zu überzeugen. Wenn diese Kosten hoch oder überhöht sind, die Leute dies jedoch nicht glauben, müssen Sie möglicherweise zuerst überzeugende Daten zu diesen Kosten abrufen.


quelle
1
Woher sollten Ihrer Meinung nach die Informationen kommen?
Orangepips
0

Was Unternehmen lieben, ist Wertsteigerung und Kostensenkung. Sie müssen erklären, wie automatisiertes Testen den Wert erhöht, da es zusätzliche Kosten verursacht.

Wenn Ihr Code modular aufgebaut ist, können Sie ihn wiederverwenden. Das bedeutet, dass die Tests nicht erneut geschrieben werden müssen und Sie einfach auf dem vorhandenen Code arbeiten können.

Bei älteren Projekten erleichtert das automatisierte Testen die Umgestaltung erheblich. Die technischen Schulden müssen irgendwann getilgt werden.

Das von Ihnen angegebene Dokumentationsargument ist nicht sehr gut. Der Unterschied zwischen der Aktualisierung der Tests und der Aktualisierung der Dokumentation ist nur Gewohnheit.

Rudolf Olah
quelle
Nach meiner Erfahrung ist die Wiederverwendung von Code für eine aufkommende Qualität von Software nicht geplant. Mit anderen Worten, erst als ich das Gleiche das dritte, vierte oder fünfte Mal umgeschrieben habe, habe ich wirklich verstanden, wie man es wiederverwendbar macht. Ich denke also, Manager haben sich oft von der Vorstellung der Programmierer verbrannt gefühlt, "gib mir mehr Zeit, um es richtig zu bauen, und das wird zu Kosteneinsparungen führen", weil ich dies in der Praxis als einen im Allgemeinen falschen Ansatz empfinde.
Orangepips
0

"Was ich brauche, ist Hilfe, um seinen Wert einem Team von Programmierern, Analysten, Managern und Testern zu vermitteln. Bei automatisierten Tests muss ich meines Erachtens nicht zwischen Komponententests (z. B. JUnit), BDD ( zB JBehave, Fitness) und UI (Selenium, Watir), weil ich denke, dass sie alle einen ähnlichen Wert bieten (aber Sie können gerne eine Antwort schreiben, die nicht übereinstimmt :)) "

OK, ich werde diese Herausforderung annehmen;)

Ich arbeite hauptsächlich mit Programmierern und der Qualitätssicherung. Meine Werkzeuge sind Ruby, Rails, Testunit, Rspec, Jasmin und Selen.

Die BDD / TDD-Tools von rspec und testunit sind Bestandteil der Programmierung. Sie brechen sie nicht aus und besprechen sie separat mit dem Management, Sie schieben sie nicht aus Zeitmangel auf, Sie beziehen sie in all Ihre Zeitschätzungen ein. Wenn Sie wirklich gefragt werden, wie viel Zeit die Leute haben, um Ihnen Informatik und Programmierung zu erklären. Ich benutze diese Tests nicht für das Frontend

GUI / UI / Jasmin / Selen. Diese sind unterschiedlich. Ich habe diese von QA-Leuten gemacht, die Programmierer-Hintergründe haben. Wir stellen sicher, dass die Tests so robust wie möglich sind und nicht auf dem Layout des Inhalts basieren. Die (möglicherweise neuen) Kosten hierfür sind als verschobene Kosten zu erklären . Anstatt später mit defekter Software, verlorenen Kunden und teuren Reparaturen zu zahlen, zahlen Sie jetzt mit ein paar einfachen Methoden viel weniger (relativ).

Michael Durrant
quelle
0

Ich denke, der Schlüssel liegt darin, über bestimmte Kategorien von Tests zu sprechen, die Sie erstellen, und nicht über "automatisierte Tests" insgesamt. Letzteres kann ein bisschen nebulös und beunruhigend sein, und es ist zu einfach, Beispiele dafür zu finden, wo Zeitverschwendung wäre.

Ich empfehle immer, Ihre Tests in 4 Gruppen aufzuteilen (mehr Details hier ). Bleiben Sie bei mir, ich werde gleich erfahren, wie Sie Tests an andere verkaufen können.

  1. Tests Ihrer Kernfunktionalität . Dh für ein Website-Überwachungstool sind dies Tests von Warnungen, die für Websites ausgelöst werden sollen, die Sie überwachen. Diese Tests stellen sicher, dass dieses Zeug niemals kaputt geht.
  2. Rauchtests für Ihre gesamte Anwendung . Verwenden Sie beispielsweise Selenium, um durch alle Links / Schaltflächen in einer Webanwendung zu navigieren und sicherzustellen, dass keine Fehler vom Server vorliegen. Mit diesen Tests verschwenden Sie keine Zeit mit offensichtlich kaputten Builds.
  3. Testet jeden fragilen Code . Dh für dieses alte Modul möchte niemand etwas anfassen oder den komplexen Code, der immer Fehler enthält.
  4. Tests, die Entwickler schreiben wollten, um ihre Arbeit zu unterstützen . Weil Tests manchmal nützlich sind, wenn Sie etwas schreiben, aber nicht in die obigen Kategorien fallen.

Durch Aufteilen Ihrer Tests in diese Kategorien können Sie jetzt eine andere Diskussion führen. Nehmen Sie die ersten drei Gruppen (die vierte Gruppe liegt ohnehin im Ermessen des Einzelnen) und fragen Sie die Leute, ob sich Tests für diese Codeteile lohnen würden. Wenn Sie keine Einigung erzielen können, schließen Sie diese Tests möglicherweise vorerst nicht ein. Wenn Sie können, dh wenn Sie der Meinung sind, dass Tests rund um die Kernfunktionalität, die bei jedem Commit ausgeführt werden, nützlich sind, fügen Sie diese hinzu.

Die andere Gruppe, die nützlich sein kann, sind Tests, deren manuelle Durchführung schwierig oder zeitaufwändig ist . Es sollte einen ziemlich einfachen Vorteil geben, der darin besteht, manuelle Testzeiten zu sparen oder Dinge testen zu lassen, die aus Zeitgründen übersprungen werden.

Robin
quelle