Zuerst durchgeführte Abnahmetests… wie kann dies erreicht werden?


8

Der Kern der meisten agilen Methoden besteht darin, dass eine Funktion erst dann "ausgeführt" wird, wenn sie entwickelt, getestet und in vielen Fällen veröffentlicht wurde. Dies soll in kurzen Zeitabschnitten wie "Sprints" im Scrum-Prozess geschehen.

Ein gemeinsamer Teil von Agile ist auch TDD, das besagt, dass Tests zuerst durchgeführt werden.

Mein Team arbeitet an einem GUI-Programm, das viele spezifische Zeichnungen und dergleichen ausführt. Um Tests durchführen zu können, muss das Testteam in der Lage sein, mit etwas zu arbeiten, das zumindest versucht, die Dinge auszuführen, die es zu testen versucht. Wir haben keinen Weg gefunden, um dieses Problem zu umgehen.

Ich kann sehr gut sehen, woher sie kommen, denn wenn ich versuchen würde, Software zu schreiben, die auf eine im Grunde mysteriöse Oberfläche abzielt, würde ich es sehr schwer haben. Obwohl das Verhalten ziemlich genau spezifiziert ist, scheint der genaue Prozess der Interaktion mit verschiedenen UI-Elementen in Bezug auf die Automatisierung für eine Funktion zu einzigartig zu sein, als dass Tester automatisierte Skripte schreiben könnten, um etwas zu steuern, das nicht existiert. Selbst wenn wir könnten, tauchen viele Dinge später als in der Spezifikation fehlend auf.

Eine Sache, die wir in Betracht gezogen haben, war, dass die Tester Testskripte schreiben, die eher einer Reihe von Schritten ähneln, die ausgeführt werden müssen, wie aus Sicht des Anwendungsfalls beschrieben, damit sie von einem Menschen "automatisiert" werden können. Dies kann dann von den Entwicklern durchgeführt werden, die die Funktion schreiben, und / oder von einer anderen Person überprüft werden. Wenn die Tester später die Gelegenheit bekommen, automatisieren sie das "Skript" hauptsächlich zu Regressionszwecken. Dies hat sich jedoch nicht im Team durchgesetzt.

Der Testteil des Teams fällt tatsächlich um einiges hinter uns zurück. Dies ist ein Grund, warum die anscheinend zusätzliche Zeit für die Entwicklung eines "Skripts" für einen Menschen einfach nicht vergangen ist ... sie stehen unter einer Krise, um mit uns Entwicklern Schritt zu halten. Wenn wir auf sie warten würden, würden wir nichts erledigen. Es ist nicht wirklich ihre Schuld, sie sind ein Flaschenhals, aber sie tun, was sie sein sollten und arbeiten so schnell wie möglich. Der Prozess selbst scheint gegen sie gerichtet zu sein.

Sehr oft müssen wir einen Monat oder länger zurückgehen, um Fehler zu beheben, die die Tester endlich überprüft haben. Es ist eine hässliche Wahrheit, gegen die ich etwas unternehmen möchte.

Was tun andere Teams, um diese Fehlerkaskade zu lösen? Wie können wir Tester vor uns bringen und wie können wir es schaffen, dass sie tatsächlich Zeit haben, Tests für die Funktionen zu schreiben, die wir in einem Sprint ausführen, ohne dass wir in der Zwischenzeit sitzen und mit den Daumen drehen müssen? Um eine Funktion mit agilen Definitionen "fertig" zu machen, müssen die Entwickler 1 Woche lang arbeiten, dann die Tester die zweite Woche und die Entwickler hoffentlich in der Lage sein, alle Fehler zu beheben, die sie sich einfallen lassen in den letzten paar Tagen. Das wird einfach nicht passieren, auch wenn ich zustimmte, dass es eine vernünftige Lösung war. Ich brauche bessere Ideen ...

Antworten:


7

Beseitigen Sie zunächst die Trennung zwischen "Testern" und "Entwicklern". Jeder testet

Zweitens codieren die Entwickler in TDD die Tests, bevor sie das Feature / die Story codieren

Was Sie beschrieben haben, ist nicht TDD [es kann jedoch Scrum sein; Scrum ist eine von der Entwicklungsmethodik unabhängige Projektmanagementmethode. Scrum ist für Ihr Problem nicht relevant.]

Szenarien, in denen automatisierte Tests nicht möglich sind , sind äußerst selten. Szenarien, in denen automatisierte Tests schwierig, teuer oder unpraktisch sind, sind weitaus häufiger - aber genau in diesen Szenarien sind automatisierte Tests am dringendsten erforderlich.

Aus der vagen Beschreibung gehe ich davon aus, dass die Software etwas auf dem Bildschirm zeichnet. Wenn das, was gezeichnet wird, durch Daten, Formeln oder Funktionsschritte bestimmt wird, schreiben Sie mindestens automatisierte Tests, die auf der Ebene der Daten / Formeln / Funktionsschritte testen. Wenn die Bildschirmausgabe deterministisch ist (dieselben Schritte führen jedes Mal zu derselben Zeichnungsausgabe), testen Sie sie einmal manuell, machen Sie einen Screenshot und lassen Sie zukünftige Tests die Ausgabe mit dem verifizierten Screenshot vergleichen. Wenn die Bildschirmausgabe nicht deterministisch ist und nicht durch Daten, Formeln oder Funktionsschritte gesteuert wird, befinden Sie sich in dem seltenen Bereich, in dem automatisierte Tests möglicherweise nicht möglich sind. Aber ich bezweifle es.

Ich vermute, dass der einzige Grund, warum das Testen bisher nicht automatisiert wurde, darin besteht, dass es den Entwicklern egal ist . In TDD führen die Entwickler die Tests durch, sodass sie den Schmerz der langweiligen Wiederholung spüren, den gleichen 62-Schritte-Prozess hundert Mal zu testen, bis alle Fehler verschwunden sind. Nichts kann eine automatisierte Testlösung schneller entwickeln, als die Entwickler dazu zu bringen, die Tests durchzuführen.


Ich spreche speziell von Abnahmetests, nicht von Unit-Tests. Ich werde jedenfalls nicht die Möglichkeit haben, die Abteilungsstruktur des Unternehmens zu ändern. Benötigen Sie eine Lösung, die sowohl mit Entwicklern als auch mit "Entwicklern im Test" funktioniert. Das heißt, wie würden Sie Ihr Screenshot-Beispiel machen, bevor es etwas zu Screenshots gab? Es gibt tatsächlich VIELE unserer automatisierten Tests, die dies tun, aber bevor so etwas automatisiert werden kann, muss es etwas geben, von dem ein Screenshot gemacht werden kann.
Edward Strange

@Crazy Eddie: TDD definiert Tests für User Stories, die die Funktionen der Anwendung definieren. Die Terminologie des "Unit-Tests" wird in diesem Zusammenhang häufig verwendet, hat jedoch nicht die gleiche eingeschränkte Bedeutung wie bei einer reinen Unit-Test-Methodik (bei der beispielsweise die Codeabdeckung eine Rolle spielen würde). TDD testet Funktionen und skaliert auf das Akzeptanztestniveau. Die Verwendung des Begriffs "Unit Testing" in der Literatur ist für viele Menschen ein bedauerlicher Punkt der Verwirrung. Für den Screenshot müssen Sie das Ding einmal erfolgreich ausführen, damit dieser Ansatz nur für Regressionstests geeignet ist.
Steven A. Lowe

@Crazy Eddie: Mit einem Namen wie Crazy Eddie würde ich erwarten, dass du der Champion bist, wenn es darum geht, sinnlose, ineffiziente Fehlerzyklen herauszufordern ;-) [Ja, ich habe deinen Blog gelesen]. Im Ernst, nichts wird sich ändern, weil die Entwickler keine Schmerzen haben. Lassen Sie sie den Schmerz spüren - oder bieten Sie ihnen eine Belohnung für ihre Hilfe an - und sie werden eine Lösung für automatisierte Tests finden und / oder mit dem Schreiben von Code beginnen, der einfacher zu testen ist.
Steven A. Lowe

Der Unterschied, den ich aus meiner Sicht als am wichtigsten betrachte, besteht darin, dass sie unterschiedliche Fachgebiete erfordern. Ein Komponententest kann und wird häufig in derselben Sprache geschrieben wie die von ihnen getesteten Anwendungsbits. Automatisierte Abnahmetests verwenden dagegen die Sprache, auf die die jeweilige Software zur Steuerung der Benutzeroberfläche reagiert. Sie erfordern auch unterschiedliche Architekturen, da zumindest unsere Tester riesige Bibliotheken wiederverwendbarer Komponenten entwickelt haben, die sie an spezifische Anforderungen anpassen. So wie ein Team DB-Experten gegen Code einbeziehen kann, scheint es in Ordnung zu sein, Testexperten zu haben.
Edward Strange

Ich denke, dies löst das Problem, Entwickler zu beschäftigen, während Tests durchgeführt werden. Selbst wenn sie für eine bestimmte Aufgabe länger brauchen, könnte es sich lohnen. Ich bekomme möglicherweise nicht das Buy-In, das ich brauche, und ich stelle mir das Problem vor, einfach weiter aufzutauchen, bis wir herausfinden können, wie wir die Tests im Voraus oder zumindest synchron schreiben können. Ich sehe immer noch keine Möglichkeit, dieses Problem zu lösen, da die Anforderung, etwas zum Fahren zu haben, eine Voraussetzung für das Automatisierungsproblem zu sein scheint.
Edward Strange

4

Meine Teams stellten fest, dass TDD für das Entwerfen von GUI-Tests nicht geeignet war. Für alle von uns verwendeten automatisierten GUI-Testframeworks musste vor dem Test Code geschrieben werden. Also haben wir zu Behavior Driven Development gewechselt . Sicher, die Tests sind nicht automatisiert, aber es gab uns eine Möglichkeit zu messen, ob die Benutzeroberfläche von Anfang an "erledigt" war.


3

Wir finden ATDD für die GUI zu schwierig / teuer.

Normalerweise machen wir zuerst das Frontend. Da wir Webapps schreiben, ist dies normalerweise in HTML / CSS / JS der Fall, und dann erhalten wir eine Freigabe für das Aussehen, den Ablauf usw. Diese werden schließlich in Vorlagen übersetzt, wobei die entsprechenden Teile durch dynamische Bits ersetzt werden.

Sobald das UI-Modell abgeschlossen ist, schreiben wir Tests, die eine Webanforderung nachahmen. XPath wird verwendet, um zu bestätigen, dass die Daten in den richtigen HTML-Tags vorhanden sind.

Wir finden, dass diese Art des Testens uns ein gutes Preis-Leistungs-Verhältnis bietet. Wir behaupten immer noch, dass die Daten zurückgegeben werden und eine allgemeine Struktur über das HTML. Da wir den Look bereits im Verlauf der Modellphase ausgearbeitet haben, müssen wir nicht versuchen, die Pixelplatzierung zu bestätigen. Wir schauen uns nur die Seite an, während wir sowohl als Teil der Entwicklung als auch als Doppelprüfung entwickeln.

Für GUI-Nicht-Web-Entwickler würde ich wahrscheinlich versuchen, einige Hooks hinzuzufügen, um das Front-End skriptfähig zu machen. Ich würde wahrscheinlich auch zuerst die Benutzeroberfläche nachahmen, selbst wenn auf dem Papier.


1
 > Acceptance tests done first…how can this be accomplished?

Ich bevorzuge einen bdd-tdd-Entwicklungsstil, wie in diesem Artikel beschrieben: Verhaltensgesteuerte Entwicklung mit SpecFlow und WatiN .

Das Beispiel verwendet .net für die Entwicklung mit SpecFlow + NUnit + WaitN. Wenn Sie mit (j) Ruby / Java entwickeln, können Sie Gurke + Junit + Waitr ausprobieren


1

Eine Sache, die wir in Betracht gezogen haben, war, dass die Tester Testskripte schreiben, die eher einer Reihe von Schritten ähneln, die ausgeführt werden müssen, wie aus Sicht des Anwendungsfalls beschrieben, damit sie von einem Menschen "automatisiert" werden können. Dies kann dann von den Entwicklern durchgeführt werden, die die Funktion schreiben, und / oder von einer anderen Person überprüft werden. Wenn die Tester später die Gelegenheit bekommen, automatisieren sie das "Skript" hauptsächlich zu Regressionszwecken. Dies hat sich jedoch nicht im Team durchgesetzt.

Das machen wir mehr oder weniger. Jedes Feature wird parallel zum Testfall (Skript) entwickelt und es wird kein Feature "ausgeführt", bis alle drei Schritte ausgeführt sind: Entwicklung, Testfall und Testen. Alle Testfälle werden von den Testern anhand der Anforderungen geschrieben und mit den Entwicklern besprochen, sodass wir alle ein gemeinsames Verständnis des Problems haben. Wie Ihr Vorschlag "jede zweite Woche", außer dass die Tester, wenn die Entwickler an der Funktion arbeiten, an Testfällen arbeiten und wenn die Tester die Funktion testen, die Entwickler die nächste Funktion untersuchen.

Ich denke, das größte Problem, das Sie haben, ist das

[t] Der Testteil des Teams fällt tatsächlich um einiges hinter uns zurück. [...] Wenn wir auf sie warten würden, würden wir nichts tun

Da das Testteam so weit zurückliegt, denke ich wirklich, dass Sie auf sie warten sollten. Ich bin mir sicher, dass Sie etwas Produktives tun können - beispielsweise einige Funktionen entwickeln, die einfach zu testen sind, deren Entwicklung jedoch viel Zeit in Anspruch nimmt. Es kann auch hilfreich sein, die Testzeit bei der Planung eines Sprints zu berücksichtigen. Weder Entwickler noch Tester sollten überarbeitet oder untätig sein.


1

Akzeptanztestgesteuerte Entwicklung (anders als, aber komplementär zu testgesteuerter Entwicklung) ist eine hervorragende Möglichkeit, um sicherzustellen, dass Sie die Anforderungen erfüllen, bevor Sie mit dem Codieren beginnen.

In meinem Team sitzen wir (Product Owner, QA-Analysten und Entwickler) zusammen und verwenden FitNesse zwei Schreibabnahmetests. Diese Sitzungen werden normalerweise von der Qualitätssicherung geleitet, aber wir alle nehmen daran teil. Diese werden nicht sofort ausgeführt, da einige Entwicklungsanstrengungen erforderlich sind, um die Fixtures hinzuzufügen (der Klebstoff zwischen den Wiki-Seiten und dem Produktionscode). Diese Tests bilden die Akzeptanzkriterien für eine Geschichte . FitNesse wurde entwickelt, um mit der Ebene unter der Benutzeroberfläche zu interagieren.

Als Entwickler arbeiten wir dann daran, dass diese Abnahmetests bestanden werden. Wir verwenden TDD dafür, aber TDD sollte nicht mit ATDD verwechselt werden.

Sobald die FitNesse-Seiten grün werden, sind wir fast fertig. Wir haben noch einige Arbeiten zu erledigen (Erkundungstests, die normalerweise von der Qualitätssicherung durchgeführt werden usw.).


Ich sehe, wie Unit-Tests und Abnahmetests nicht verwechselt werden sollten. Nicht dass Onkel Bob ein Gott ist, aber in "Agile Prinzipien, Muster und Praktiken in C #" schließt er Akzeptanztests (und verwendet FitNesse) als Teil von TDD ein und macht keinen Unterschied und erwähnt ATDD nicht einmal.
JeffO

0

Vielleicht kann Ihnen das Schreiben codierter UI-Tests helfen. Wenn Sie mit Visual Studio 2010 arbeiten, können Sie ein Add-In namens "Coded UI Test" zum Aufzeichnen und Codieren eines ganz bestimmten Skripts für die Interaktion mit der Benutzeroberfläche Ihrer App verwenden. Durch das Aufzeichnen einer Interaktion in einem Skript wird eine zusätzliche Abstraktionsebene eingeführt, die Sie vor kleinen Änderungen in der Benutzeroberfläche schützt. Die Einführung dieser Testform bedeutet jedoch auch die Belastung für die Aufrechterhaltung der Tests.

Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.