Was ist agiles Testen?

Ein Leitfaden für Einsteiger über moderne Softwaretests

In der Welt der Softwareentwicklung bezieht sich der Begriff agil normalerweise auf jeden Ansatz des Projektmanagements, bei dem Teams auf den Grundsätzen der Zusammenarbeit, Flexibilität, Einfachheit, Transparenz und Reaktion auf Rückmeldungen während des gesamten Prozesses der Entwicklung eines neuen Programms oder Produkts vereint werden. Agiles Testen bedeutet im Allgemeinen das Testen von Software auf Fehler oder Leistungsprobleme im Kontext eines agilen Workflows.

Obwohl das Wort agil manchmal verwendet wird, um jede Art von “dynamischer” oder “unstrukturierter” Form der Zusammenarbeit mit anderen zu bezeichnen, deutet der Begriff häufiger auf einen fokussierten, aber schnell iterativen Softwareprozess, der auf Prinzipien basiert, die erstmals in einem 68-Worte-Dokument namens Agile Manifesto beschrieben wurden. Das Manifest, das Anfang 2001 von einer Gruppe von Software-Ingenieuren konzipiert wurde, zielte darauf ab, die Entwicklung von Computerprogrammen und IT-Systemen auf effizientere, humanere und kollaborative Weise zu fördern. Heutzutage wird die agile Methode,—die oft einfach als Agile bezeichnet wird, mit einem großgeschriebenen “A” gekennzeichnet, das die Einhaltung der im Agile Manifest—beschriebenen Prinzipien zum Ausdruck bringt, das als ein wirksamer Ansatz (oder genauer eine Klasse von Ansätzen) für das Projektmanagement innerhalb der Mainstream-Softwareentwicklungs- und Testgemeinschaft akzeptiert ist.

Im Februar 2001 versammelte sich in einer abgelegenen Skihütte in Snowbird, Utah, eine Gruppe von Computeringenieuren, um sich die Zukunft ihrer Branche vorzustellen. Vereint in der Leidenschaft für innovative, flexible Ansätze für das Projektmanagement und einem Misstrauen gegenüber traditionelleren linearen Methoden versuchten sie, ihren Eifer in einem digitalen Manifest festzuhalten, einem prägnanten Statement über Werte, die von Entwicklern und IT-Experten weltweit gesehen und bedacht werden würden. Während tage- und nächtelanger intensiver Diskussionen, die zu gleichen Teilen von Kaffee und heißem Kakao angeheizt wurden, nahmen siebzehn Männer den Stand der Software-Industrie unter die Lupe, verglichen ihre bevorzugten Workflow-Praktiken—von “Scrum” über “Lean” bis “XP” (d. h. Extreme Programming)—und ergründeten eine Synthese von Prinzipien, die die besten Elemente dieser innovativen Pfade erfassen würde.

Diese Synthese wiederum würde dazu beitragen, die dramatischen Veränderungen voranzutreiben, die ihrer Ansicht nach von jedem Software-Entwicklungsteam angenommen werden müssen, das mit den sich ständig weiterentwickelnden Realitäten seiner Fachrichtung Schritt halten möchte. Um mehr als nur eine neue Projektmanagementmethode zu entwickeln, hatten sie ihre winterliche Zusammenkunft einberufen, um eine Denkweise zu definieren und die neue Denk- und Arbeitsordnung zu artikulieren, die durch dynamische Ansätze wie Scrum und XP veranschaulicht wurde.

Das Snowbird Accord, durch welches das Agile Manifesto zustandekam, hat in bestimmten Software-Entwicklungskreisen nahezu mythische Ausmaße angenommen. Handschriftliche Notizen dieses historischen Treffens, als der beschreibende Begriff “Agile” vereinbart wurde, sowie Ausdrucke mit Namen und alten E-Mail-Adressen der ausgewählten siebzehn Teilnehmer werden beibehalten und von Entwicklern und Testern mit einem quasi-religiösen Gefühl der Ehrfurcht geteilt. Innerhalb weniger Monate nach dem Treffen in Snowbird bildete eine Gruppe inspirierter Konvertiten die Agile Alliance, eine internationale gemeinnützige Organisation, die sich der Verbreitung der im Manifest enthaltenen Weisheit verschrieben hatte. Bis zum heutigen Tag veranstaltet die Alliance Konferenzen und Bildungsveranstaltungen, verbreitet die Werte von Agile weltweit und schult Führungskräfte, IT-Experten und Softwareentwickler, um ihre Methoden erfolgreich in ihrer Arbeit einzusetzen.

Falls Sie sich jedoch immer noch fragen, worum es bei Agile eigentlich geht, können dessen Grundprinzipien wahrscheinlich am besten im Vergleich zu traditionelleren Ansätzen der Softwareentwicklung erläutert werden, wie z. B. “Waterfall,” von dem Agile-Anhänger glauben, dass es sich um einen archaischen Überrest aus einer Ära handelt, als Software erstmals eine verpackte Ware wurde, die wie andere physische Güter produziert und an Verbraucher verkauft werden sollte.

Laut dem Software-Testexperten Scott Barber begannen zwischen 1979 und 1985 praktisch alle Softwareunternehmen, ihre Produktionsprozesse in dieselbe Wasserfallmethode umzuwandeln, die in der verarbeitenden Industrie und im Maschinenbau seit Jahrzehnten erfolgreich eingesetzt wurde. Bei einem Wasserfallansatz verläuft der Workflow eines Projekts in einer linearen Reihe von aufeinanderfolgenden Schritten, wobei die Produktionskette von der Anforderung über das Design über die Implementierung bis hin zur Überprüfung und Software-Pflege voranschreitet.

Traditional-Waterfall-Testing-Model.png

Wie Sie im obigen Diagramm sehen können, befinden sich die “Design-” und “Implementierungsstufen” in einem Wasserfallprozess vor den “Überprüfungs-” und “Pflegestufen” und unterscheiden sich von diesen. Diese Trennung zwischen Softwareentwicklern und Softwaretestern, die an verschiedenen Stellen eines Produktionszyklus als separate Einheiten positioniert werden, ist eines der grundlegenden Probleme, die Agile lösen möchte.

Beim Agile-Ansatz werden Entwickler und Tester als zwei Seiten derselben Produktionsmünze betrachtet, zwei parallele Linien, die sich immer treffen und täglich vergleichen sollten. Aus Sicht des Agile-Ansatzes wird die effiziente Produktion stark beeinträchtigt, wenn Ihre Entwickler bestrebt sind, ihren Code bis zur Perfektion zu verfeinern, bevor Sie sie an ein separates Testteam weitergeben, das anschließend versucht, den Code auf möglichst viele Arten auf Herz und Nieren zu prüfen, bevor dieses dann einen Schadensbericht an das Entwicklerteam zurücksendet. Dieser zweistufige Prozess erfordert Zeit, Geld und führt häufig zu einer internen Trennung zwischen den Entwicklern und Testern eines Unternehmens. Stattdessen schlägt Agile vor, dass diese beiden wesentlichen Funktionen—nicht notwendigerweise in Bezug auf Personen, sondern in Bezug auf Zeit und Prozess zusammengeführt werden, —wodurch die illusorische Kluft zwischen Code-Erstellern und Code-Brechern überbrückt wird und sogar der Bedarf an robusten Testteams reduziert wird, während die Notwendigkeit beider Rollen nach wie vor berücksichtigt wird.

Man könnte sogar sagen, dass Entwickler in Agile dazu ermutigt werden, eher wie Tester zu denken, ihren eigenen Code ständig auf mögliche Fehler zu überprüfen, und Tester werden aufgefordert, eher wie Entwickler zu denken und ihre natürlichen zerstörerischen Tendenzen zu mildern, um sich stärker am kreativen Prozess zu beteiligen. Barber bezeichnet dies als Schaffung eines “Produktbereitstellungsteams mit der vereinheitlichten Vision, zum ‘ersten’ Mal produktionswürdigen Code bereitzustellen, indem Entwickler- und Testerdenken in den gesamten Code-Schreibprozess integriert werden.” Diese Integration impliziert, dass Entwickler sowohl die Denkfähigkeiten ihrer Tester verbessern als auch die Idee der direkten Interaktion, sogar Paarung, mit denjenigen befürworten, die sich auf die Denkweise der Tester beim Programmieren spezialisiert haben.

Vereinfachen Sie die Zusammenarbeit im Team und verwalten Sie Ihre agilen Tests an einem zentralen Ort. Testen Sie QAComplete.

Demo anfordern

Agile erfordert eine intensive Zusammenarbeit zwischen den Stakeholdern,—einschließlich Managern, Entwicklern, Testern und Kunden,—während des gesamten Produktionsprozesses, die in einem herkömmlichen Wasserfall-Workflow nicht zu finden sind. Das Testen wird zu einem wesentlichen Bestandteil jeder Phase des Entwicklungsprozesses. In jeder Phase der Entwicklung wird Qualität durch die ständige Rückmeldung von allen, die eine Vision des Endprodukts haben, in das finale Produkt “eingebettet” . Martin Fowler, einer der ursprünglichen Unterzeichner des Agile-Manifests, erklärt dies wie folgt:

Der Schlüssel zu diesem Feedback ist die iterative Entwicklung. Das ist keine neue Idee. Die iterative Entwicklung gibt es schon seit geraumer Zeit unter vielen Namen: inkrementell, evolutionär, inszeniert, spiralförmig ... viele Namen. Der Schlüssel zur iterativen Entwicklung besteht darin, häufig funktionierende Versionen des endgültigen Systems zu erstellen, die eine Teilmenge der erforderlichen Funktionen aufweisen. Diese Arbeitssysteme haben zu wenig Funktionalität, sollten aber ansonsten den Anforderungen des endgültigen Systems entsprechen. Sie sollten wie eine endgültige Lieferung vollständig integriert sein und ebenso sorgfältig getestet werden.

Beim Agile-Test gibt es nur wenige oder gar keine starren Vorgaben für Anforderungsdokumente und Checklisten. Das Ziel ist stattdessen, zu jedem Zeitpunkt einfach alles Notwendigezu unternehmen, um die Anforderungen eines Kunden zu erfüllen, die Dokumentation durch persönliche Meetings zu ersetzen und isolierte Funktionen durch vereinheitlichte, sich selbst organisierende Projektteams zu ersetzen. In einer agilen Unternehmenskultur wird von jedem erwartet, dass er/sie unabhängig von seiner/ihrer Rolle eng mit anderen zusammenarbeitet, um ein einzelnes, gemeinsames Ziel zu erreichen: ein qualitativ hochwertiges Softwareprodukt, das alle wesentlichen Spezifikationen erfüllt, die ein Kunde oder Designer bei jeder Iteration benötigt.

Softwareentwickler, Tester und QA-Personal tragen von Zeit zu Zeit die Verantwortung des jeweils anderen. Obwohl es eine ausgewählte Gruppe von Leuten gibt, die die meisten Tests durchführen, verschwindet die Vorstellung eines separaten Testteams für viele Produktteams, und verschwindet auch innerhalb des Kernentwicklungszyklus für diejenigen Organisationen, die von externen Stellen (oder sogar gesetzlich vorgeschrieben) dazu aufgefordert werden, formale und/oder externe Release Candidate-Tests zur Verfügung zu haben. Selbst in diesen Fällen werden bei diesem separaten “Tests” der Release Candidates keine Tests durchgeführt, nur um Probleme zu finden oder das Produkt zu verbessern. Es handelt sich hierbei um eine Überprüfung der Einhaltung gesetzlicher Vorschriften und/oder das Abschließen von Prüfpfaden.

Es ist jene dynamisch kollaborative Dimension des agilen Ansatzes, von der die Befürworter der Meinung sind, dass sie sich von anderen Methoden unterscheidet. Der ständige interne Dialog führt zu einer besseren Kommunikation mit Kunden und Endbenutzern, einer besseren Reaktionsfähigkeit auf sich ständig ändernde Projektanforderungen, bessere Arbeitsbeziehungen zwischen Entwicklern und Testern und ein insgesamt besser und effizienter geliefertes Softwareprodukt.

Obwohl es scheinbar komplexer ist als herkömmliche Projektmanagementmethoden wie Wasserfall, behaupten die Befürworter von Agile, nach erfolgreicher Implementierung führe dies rasch zu größerer Einfachheit, wodurch das kreative Potenzial und die Effizienz der Software-Produktionsteams auf sequentielle, lineare und strengere prozedurale Ansätze zur Softwareentwicklung freigemacht würden, was bei Ansätzen, die nach Schema F arbeiten, nur selten der Fall ist.

Wie der Name vermuten lässt, schlägt Agile lediglich vor, schneller, vorrangiger & auf Risiken zu setzen und flexibler, anpassungsfähiger und effizienter zu sein, um das komplizierte Geschäft der Softwareproduktion zu erledigen. Und natürlich hat auch dieser Ansatz seine Kritiker.

“Bei all seinen Befürwortern,” schreibt Mike Brown von uTest, hat “Agile auch einen Anteil an Skeptikern und Kritikern. Dies sind Menschen, die eine ganz andere Erfahrung mit Agile haben,— eine, die durch chaotische Prozesse, geringere Qualität, Missverständnisse und zahlreiche andere Probleme gekennzeichnet ist.”

Und diese Kritiker sind nicht in der Minderheit. 2012 berichtete Max Smolaks von TechWeek Europe über die von Voke Media durchgeführten Untersuchungen Folgendes, um zu ermitteln, was 200 verschiedene Software-Unternehmen von ihrem Versuch hielten, Agile zu nutzen:

Von über 200 Teilnehmern gaben 64 Prozent an, dass der Wechsel zu Agile Development schwieriger sei, als es zunächst schien. Vierzig Prozent der Befragten haben keinen offensichtlichen Nutzen für die Praxis festgestellt. Unter denen, die dies jedoch feststellten, waren 14 Prozent der Meinung, dass dies zu schnelleren Releases führte und 13 Prozent,—dass dies zu mehr Feedback führte. Sieben Prozent der Befragten gaben an, dass Agile-Entwickler aufgrund einer geringeren zukünftigen Planung und Dokumentation zufriedener waren.

Diese Ergebnisse deuten stark darauf hin, dass für Organisationen, die in jahrelangen nicht-agilen Arbeitspraktiken verankert sind, der Wechsel schwierig werden kann, wenn nicht sogar kontraproduktiv ist. Scott Barber von SmartBear erklärt dazu Folgendes:

Ich glaube, dass der Trend “zu Agile” fehlgeleitet ist. Wenn ein Unternehmen gute Software entwickelt, die Leute, die an der Entwicklung dieser Software beteiligt sind, gerne dort arbeiten, die Softwareentwicklung nachhaltig ist und das Unternehmen von dieser Software ausreichend bedient wird, besteht kein Grund, dass sie versuchen, mehr oder weniger agil zu sein. Agile birgt Herausforderungen wie jede andere Kultur, aber die größte Herausforderung, die ich erkenne, sind Unternehmen, die versuchen, Probleme mit der Entwicklung, dem Prozess, dem Management und/oder dem Zeitplan allein durch “einen Wechsel zu Agile zu lösen.” Teams, die in einer Kultur gewachsen sind, die sich grundlegend von Agile unterscheidet, wird es einfach nicht leicht fallen, “auf Agile umzusteigen.”

Mit anderen Worten: Unternehmen, die von Agile eine magische Lösung erwarten, um die Probleme zu beheben, die ihre Produktionsbemühungen beeinträchtigen, können ernsthaft enttäuscht werden, da es eine mehr systemische Kulturverlagerung erfordert, als lediglich das Akzeptieren neuer Werkzeuge und Verfahren. Darüber hinaus ist es kein einheitlicher Ansatz, der auf alles zutrifft. Was für ein kleines Startup-Unternehmen in San Francisco funktioniert, ist für ein Unternehmen mit 5.000 Mitarbeitern in Städten auf der ganzen Welt möglicherweise völlig ungeeignet. Agile ist möglicherweise auch nicht die richtige Vorgehensweise für Softwareunternehmen und IT-Unternehmen, die gesetzlich vorgeschriebenen Compliance-Anforderungen unterliegen, wie etwa Regierungsbehörden und deren Auftragnehmer, bei denen umfangreiche Dokumentationen und Verfahren mit Kontrollen und Abwägungen einhergehen.

Befürworter von Agile legen natürlich nahe, dass praktisch alle Probleme, Beschwerden und negativen Erfahrungen, die von Unternehmen, die Agile einsetzen wollen, berichtet wurden, nicht auf ein Problem mit Agile selbst zurückzuführen sind, sondern dass die Vorgehensweise und ihre Grenzen nicht verstanden werden. Andere, wie der Technologiestratege Lajos Moczar, behaupten, Agile vollständig zu verstehen und glauben dennoch, dass dessen Leitprinzipien fehlerhaft seien.

In einem im Juni 2013 veröffentlichten Artikel auf CIO.com mit dem Titel “Why Agile Isn’t Working,” entfachte Moczar einen Flächenbrand bei pro-agilen und anti-agilen Kommentatoren zu seinem Beitrag, der in milde verbale Kriegsführung mündete. “Die Kommentare in diesem Thread haben einen seltsam negativ-religiösen Ton angenommen,” bemerkte ein Teilnehmer, “als würde man einem Sektierer dabei zusehen, wie er mit einem Mitglied einer anderen Sekte über die Lehre argumentiert.” Wie bei allen ideologischen Paradigmen nehmen manche Menschen Agile mit fast spiritueller Leidenschaft entweder an—oder lehnen—es ab.

Es gibt jedoch viele Anzeichen dafür, dass trotz der potenziellen Nachteile die rasche Einführung und Popularisierung von Agile weitgehend auf den pragmatischen Anforderungen an die Softwareproduktion und die Informationstechnologie im frühen 21. Jahrhundert beruht. Wenn sich alles so schnell ändert, ist einfach etwas Agilität gefragt.

Wie schon erwähnt, hat Agile bereits den Kampf um die Akzeptanz des Mainstreams gewonnen, und durch alle Anzeichen werden seine allgemeinen Vorschriften für einige Zeit tragfähig bleiben. Ein großer Teil dieses Erfolgs beruht zweifellos auf dessen Wirksamkeit, wenn es unter geeigneten Umständen eingesetzt wird und Softwareteams von alten, überholten Geschäftsmethoden befreit sind, aber es ist zumindest teilweise das Ergebnis des sich verändernden Gebiets der Datenverarbeitung selbst.

Vor ein paar Jahrzehnten, als die Verbraucher zu ihrem örtlichen Costco gingen, um Software zu kaufen, die magnetisch auf Disketten codiert war, und diese übergroßen Kisten zusammen mit ihren Frühstücks-Muffins und Corndogs zur Kasse brachten, war dies sowohl für große Unternehmen als auch kleine Unternehmen sinnvoll, die Software als ein weiteres industrielles Massenprodukt betrachten. Ein Herstellungsprozess im Wasserfallstil schien nicht nur angemessen, sondern auch effektiv. Tester waren erforderlich, um den Entwicklercode’ bis zum endgültigen Commit zu überprüfen, woraufhin die Produktteams der Qualitätssicherung die Übertragung auf physische Datenträger—beaufsichtigen, wobei Disketten wie bei jedem anderen physischen Produkt die Montagelinie durchlaufen mussten.

Aber dann kam das Internet auf und die Breitbandanbindung veränderte einfach alles. Mit der Möglichkeit, Software direkt von Anbietern herunterzuladen, zusammen mit regelmäßigen Fehlerbehebungen und Updates, hat sich das gesamte Spiel verändert. Produktionsprozesse mussten iterativ, leichtgewichtig und kontextabhängig werden und auf das Kundenfeedback mehr denn je reagieren. Für viele erschien die Möglichkeit, ein Softwareprojekt “zu Ende zu bringen,” immer schwerer. Die langsame, schrittweise Produktionsmentalität, die die Softwareentwicklung in den 1980er Jahren dominiert hatte, wurde durch die sich rasch entwickelnde Infrastruktur des Computers selbst in Frage gestellt. Um den Prozess zu rationalisieren, war etwas flexibleres und effizienteres, etwas ... agileres notwendig.

Heute leben wir in einer Welt, in der digitale Downloads den Verkauf dominieren und eine kontinuierliche Bereitstellung zum Standard wird. Zu jedem beliebigen Zeitpunkt lädt Ihr Smartphone möglicherweise App-Updates im Hintergrund herunter, um Fehler zu beheben, von denen Sie nicht einmal wussten, dass sie aus der Cloud von einem Agile-Team auf Ihr Telefon übertragen—wurden, das fast täglich neue Iterationen ihrer Software verfeinert. Die Geschwindigkeit des Softwareverkaufs nimmt stetig zu (und steigt dazu auch noch exponentiell), und den Bewertungen in den App-Stores nach zu urteilen, scheint die Geduld der Kunden’ für Software-Probleme im Gegenteil dazu zu sinken. Damit Unternehmen wettbewerbsfähig bleiben und Tests mit den richtigen Tools durchführen und so schnell wie Entwickler Code ändern können, müssen sie erkennen, dass die Zukunft der Softwareentwicklung nicht mehr linear—ist und vielleicht niemals hätte sein dürfen.

Bis die nächste große Innovation im Softwareprozess eintritt, ist die Zukunft eindeutig agil.