Ein Weg zu besserem agilem Testen

Veröffentlicht: 2022-03-11

Der jährlich von Capgemini erstellte World Quality Report zeigt, dass 42 % der Umfrageteilnehmer einen „Mangel an professioneller Testexpertise“ als Herausforderung bei der Anwendung von Tests in der agilen Entwicklung angeben. Während das Aufkommen von Agile die Geschwindigkeit der Iterationen für die Softwareentwicklung erhöht hat, ging dies in einigen Fällen auf Kosten der Qualität.

Der harte Wettbewerb setzt Teams unter Druck, ständig neue Produktaktualisierungen bereitzustellen, aber dies ist manchmal mit seinen eigenen Kosten verbunden, einschließlich einer verringerten Aufmerksamkeit für Tests. Einige, wie Rob Mason, gehen sogar noch weiter und argumentieren, dass Agile das Testen von Software tötet. Kürzlich hat Facebook sein Motto von „Move Fast and Break Things“ zu „Move Fast with Stable Infrastructure“ geändert, um der Versuchung zu widerstehen, Qualität zu opfern.

Wie also lässt sich das Testen besser in die neue Welt der agilen Softwareentwicklung integrieren? Agiles Testen.

Herkömmliches Testen ist ziemlich umständlich und hängt von einer Menge Dokumentation ab. Agiles Testen ist ein Ansatz für den Testprozess, der die Prinzipien der agilen Softwareentwicklung nachahmt, wobei:

  • Es wird viel häufiger getestet,
  • Das Testen stützt sich weniger auf die Dokumentation und mehr auf die Zusammenarbeit der Teammitglieder und
  • Einige Testaktivitäten werden nicht nur von Testern, sondern auch von Entwicklern durchgeführt.

In den letzten sieben Jahren habe ich viele Teams auf agiles Testen umgestellt und Seite an Seite mit Testern gearbeitet, um ihre Prozesse an die neue Methodik anzupassen. In diesem Artikel teile ich einige der wirkungsvollsten Tipps, die ich auf meinem Weg zu besseren agilen Tests gelernt habe. Während es bei Agile-Praktiken ganz natürlich zu Spannungen zwischen Geschwindigkeit und Qualität kommt, behandelt dieser Artikel einige Techniken, mit denen die Testqualität verbessert werden kann, ohne die Agilität zu beeinträchtigen. Die meisten der hier skizzierten Vorschläge erfordern die Beteiligung des Teams, daher ist es von Vorteil, wenn sowohl Entwickler als auch Tester an der Planung teilnehmen.

Formulieren Sie einen Release-Testzyklus-Prozess

Ein Problem beim Testen ist das Fehlen des Release-Testzyklus, kein Release-Zeitplan oder unregelmäßige Testanfragen. Die On-Demand-Testanfragen erschweren den QA-Prozess, insbesondere wenn Tester mehrere Projekte bearbeiten.

Viele Teams erstellen nach jedem Sprint nur einen einzigen Build, was für Agile-Projekte nicht ideal ist. Der Wechsel zu einmal wöchentlichen Releases könnte von Vorteil sein, wenn Sie schrittweise auf mehrere Builds pro Woche umstellen. Im Idealfall sollten Entwicklungs-Builds und -Tests täglich stattfinden, was bedeutet, dass Entwickler jeden Tag Code in das Repository übertragen und Builds zu einer bestimmten Zeit ausgeführt werden. Um noch einen Schritt weiter zu gehen, könnten Entwickler bei Bedarf neuen Code bereitstellen. Um dies zu implementieren, können Teams einen kontinuierlichen Integrations- und kontinuierlichen Bereitstellungsprozess (CI/CD) einsetzen. CI/CD schränkt die Möglichkeit eines fehlgeschlagenen Builds am Tag einer Hauptversion ein.

Zyklus von Continuous Integration und Continuous Delivery

Wenn CI/CD und Testautomatisierung kombiniert werden, ist eine frühzeitige Erkennung kritischer Fehler möglich, sodass Entwickler genügend Zeit haben, kritische Fehler vor der geplanten Client-Veröffentlichung zu beheben. Eines der Prinzipien von Agile besagt, dass funktionierende Software das primäre Maß für den Fortschritt ist. In diesem Zusammenhang macht ein formalisierter Release-Zyklus den Testprozess agiler.

Unterstützen Sie Tester mit Bereitstellungstools

Einer der häufigsten Reibungspunkte beim Testen ist die Bereitstellung des Codes in einer Staging-Umgebung. Dieser Prozess hängt von der technischen Infrastruktur ab, auf die Ihr Team möglicherweise keinen Einfluss hat. Wenn jedoch eine gewisse Flexibilität vorhanden ist, können Tools für technisch nicht versierte Personen wie Tester oder Projektmanager erstellt werden, mit denen sie die aktualisierte Codebasis zum Testen selbst bereitstellen können.

In einem meiner Teams haben wir beispielsweise Git für die Versionskontrolle und Slack für die Kommunikation verwendet. Die Entwickler erstellten einen Slackbot, der Zugriff auf Git, Bereitstellungsskripte und eine virtuelle Maschine hatte. Tester konnten den Bot mit einem von GitHub oder Jira erworbenen Branch-Namen anpingen und ihn in einer Staging-Umgebung bereitstellen.

Dieses Setup sparte den Entwicklern viel Zeit und reduzierte gleichzeitig die Kommunikationsverschwendung und die ständigen Unterbrechungen, wenn Tester Entwickler bitten mussten, einen Zweig zum Testen bereitzustellen.

Experimentieren Sie mit TDD und ATDD

Testgetriebene Entwicklung (TDD) ist eine Art Softwareentwicklungsprozess, der großen Wert auf Qualität legt. Traditionell schreibt ein Entwickler Code und dann testet ihn jemand und meldet, ob Fehler gefunden wurden. In TDD schreiben Entwickler zuerst Komponententests, bevor sie überhaupt Code schreiben, der eine User Story vervollständigen würde. Die Tests schlagen zunächst fehl, bis der Entwickler die minimale Menge an Code schreibt, um die Tests zu bestehen. Danach wird der Code umgestaltet, um die Qualitätsanforderungen des Teams zu erfüllen.

Phasen der testgetriebenen Entwicklung

Acceptance Test Driven Development (ATDD) folgt einer ähnlichen Logik wie TDD, konzentriert sich aber, wie der Name schon sagt, auf Akzeptanztests. In diesem Fall werden Akzeptanztests vor der Entwicklung in Zusammenarbeit mit Entwicklern, Testern und Anforderern (Kunde, Product Owner, Business Analyst usw.) erstellt. Diese Tests helfen jedem im Team, die Anforderungen des Kunden zu verstehen, bevor Code geschrieben wird.

Techniken wie TDD und ATDD machen das Testen agiler, indem sie Testverfahren in die frühen Phasen des Entwicklungslebenszyklus verlagern. Beim frühzeitigen Schreiben von Testszenarien müssen Entwickler die Anforderungen wirklich gut verstehen. Dies minimiert unnötige Codeerstellung und beseitigt auch Produktunsicherheiten zu Beginn des Entwicklungszyklus. Wenn Produktfragen oder -konflikte erst in späteren Phasen auftauchen, steigen Entwicklungszeit und -kosten.

Entdecken Sie Ineffizienzen, indem Sie die Bewegung von Aufgabenkarten verfolgen

In einem meiner Teams hatten wir einen Entwickler, der extrem schnell war, besonders bei kleinen Features. Während der Codeüberprüfung erhielt er viele Kommentare, aber unser Scrum Master und ich schrieben das als Mangel an Erfahrung ab. Als er jedoch anfing, komplexere Funktionen zu programmieren, wurden die Probleme deutlicher. Er hatte ein Muster entwickelt, um Code zum Testen zu übergeben, bevor er vollständig fertig war. Dieses Muster entsteht typischerweise, wenn es an Transparenz im Entwicklungsprozess mangelt – z. B. wenn nicht klar ist, wie viel Zeit verschiedene Personen für eine bestimmte Aufgabe aufwenden.

Manchmal überstürzen Entwickler ihre Arbeit in dem Versuch, Funktionen so schnell wie möglich herauszubringen und die Qualität an die Tester „auszulagern“. Ein solches Setup verschiebt den Engpass im Sprint nur weiter nach unten. Qualitätssicherung (QA) ist das wichtigste Sicherheitsnetz des Teams, aber das kann bedeuten, dass die Existenz von QA Entwicklern die Möglichkeit gibt, auf Qualitätsüberlegungen zu verzichten.

Viele moderne Projektmanagement-Tools haben die Fähigkeit, die Bewegung von Aufgabenkarten auf einem Scrum- oder Kanban-Board zu verfolgen. In unserem Fall haben wir mithilfe von Jira analysiert, was mit den Aufgaben des betreffenden Entwicklers passiert ist, und Vergleiche mit anderen Entwicklern im Team angestellt. Wir haben erfahren, dass:

  • Seine Aufgaben verbrachten fast doppelt so viel Zeit in der Testspalte unseres Boards;
  • Seine Aufgaben wurden viel häufiger von der Qualitätssicherung für eine zweite oder dritte Korrekturrunde zurückgegeben.

Abgesehen davon, dass die Tester mehr Zeit für seine Aufgaben aufwenden mussten, mussten sie es auch mehrmals tun. Unser undurchsichtiger Prozess ließ den Eindruck entstehen, dass der Entwickler wirklich schnell war; Dies stellte sich jedoch unter Berücksichtigung der Testzeit als falsch heraus. Das Hin- und Herschieben von User Stories ist offensichtlich kein schlanker Ansatz.

Um dieses Problem zu lösen, haben wir zunächst eine ehrliche Diskussion mit diesem Entwickler geführt. In unserem Fall war ihm einfach nicht bewusst, wie schädlich sein Arbeitsmuster war. So hatte er sich an die Arbeit in seinem vorherigen Unternehmen gewöhnt, das geringere Qualitätsanforderungen und einen größeren Testerpool hatte. Nach unserem Gespräch und mit Hilfe einiger Programmiersitzungen zu zweit mit unserem Scrum-Master wechselte er allmählich zu einem qualitativ hochwertigeren Entwicklungsansatz. Aufgrund seiner schnellen Programmierfähigkeiten war er immer noch ein Leistungsträger, aber die beseitigte „Verschwendung“ des QA-Prozesses machte den gesamten Testprozess viel agiler.

Fügen Sie dem QA-Team-Skillset Testautomatisierung hinzu

Das Testen in nicht agilen Projekten umfasst Aktivitäten wie Testanalyse, Testdesign und Testausführung. Diese Aktivitäten sind sequentiell und erfordern eine umfangreiche Dokumentation. Wenn ein Unternehmen zu Agile übergeht, konzentriert sich der Übergang meistens hauptsächlich auf die Entwickler und nicht so sehr auf die Tester. Sie stellen die Erstellung umfangreicher Dokumentationen (eine Säule traditioneller Tests) ein, führen aber weiterhin manuelle Tests durch. Manuelles Testen ist jedoch langsam und kann in der Regel nicht mit den schnellen Feedback-Schleifen von Agile fertig werden.

Testautomatisierung ist eine beliebte Lösung für dieses Problem. Automatisierte Tests erleichtern das Testen neuer und kleiner Funktionen erheblich, da der Testcode im Hintergrund ausgeführt werden kann, während sich Entwickler und Tester auf andere Aufgaben konzentrieren. Da die Tests außerdem automatisch ausgeführt werden, kann die Testabdeckung im Vergleich zu manuellen Testanstrengungen viel größer sein.

Automatisierte Tests sind Teile von Softwarecode, die der zu testenden Codebasis ähneln. Das bedeutet, dass Personen, die automatisierte Tests schreiben, technische Fähigkeiten benötigen, um erfolgreich zu sein. Es gibt viele verschiedene Varianten, wie automatisierte Tests in verschiedenen Teams implementiert werden. Manchmal übernehmen Entwickler selbst die Rolle von Testern und erweitern die Testcodebasis mit jedem neuen Feature. In anderen Teams lernen manuelle Tester den Umgang mit Testautomatisierungstools oder ein erfahrener technischer Tester wird eingestellt, um den Testprozess zu automatisieren. Welchen Weg das Team auch einschlägt, die Automatisierung führt zu viel agileren Tests.

Testprioritäten verwalten

Bei der nicht-agilen Softwareentwicklung werden Tester normalerweise pro Projekt zugewiesen. Mit dem Aufkommen von Agile und Scrum ist es jedoch üblich geworden, dass dieselben QA-Experten über mehrere Projekte hinweg arbeiten. Diese sich überschneidenden Verantwortlichkeiten können zu Terminkonflikten führen und dazu führen, dass Tester wichtige Zeremonien verpassen, wenn ein Tester den Release-Tests eines Teams Vorrang vor der Sprint-Planungssitzung eines anderen Teams einräumt.

Binden Sie Tester in agile Zeremonien ein.

Der Grund, warum Tester manchmal an mehreren Projekten arbeiten, liegt auf der Hand – es gibt selten einen konstanten Fluss von Aufgaben zum Testen, um eine Vollzeitstelle zu besetzen. Daher kann es schwierig sein, die Beteiligten davon zu überzeugen, einem Team eine dedizierte Testressource zuzuweisen. Es gibt jedoch einige sinnvolle Aufgaben, die ein Tester ausführen kann, um seine Ausfallzeit auszugleichen, wenn er nicht an Testaktivitäten beteiligt ist.

Kundendienst

Eine mögliche Einrichtung besteht darin, dass der Tester seine Sprint-Ausfallzeit damit verbringt, dem Kunden-Support-Team zu helfen. Durch die ständige Auseinandersetzung mit den Problemen der Kunden hat der Tester ein besseres Verständnis für die Benutzererfahrung und wie sie verbessert werden kann. Sie können während der Planungssitzungen zu den Diskussionen beitragen. Darüber hinaus werden sie während ihrer Testaktivitäten aufmerksamer, da sie besser damit vertraut sind, wie die Kunden ihre Software tatsächlich verwenden.

Produkt Management

Eine weitere Technik zur Verwaltung der Testerprioritäten besteht darin, sie im Wesentlichen zu Junior-Produktmanagern zu machen, die manuelle Tests durchführen. Dies ist auch eine praktikable Lösung, um die Freizeit eines Testers zu füllen, da Junior-Produktmanager viel Zeit damit verbringen, Anforderungen für die User Stories zu erstellen, und daher die meisten Aufgaben genau kennen.

Testautomatisierung

Wie wir bereits besprochen haben, sind manuelle Tests der Automatisierung oft unterlegen. In diesem Zusammenhang kann der Drang zur Automatisierung damit gekoppelt werden, dass ein Tester seine volle Aufmerksamkeit dem Team widmet und seine Freizeit nutzt, um zu lernen, mit Testautomatisierungstools wie Selenium zu arbeiten.

Zusammenfassung: Qualitativ hochwertiges agiles Testen

Das Testen agiler zu gestalten, ist eine Zwangsläufigkeit, mit der viele Softwareentwicklungsteams jetzt konfrontiert sind. Die Qualität sollte jedoch nicht durch eine „Teste so schnell wie möglich“-Denkweise beeinträchtigt werden. Es ist zwingend erforderlich, dass ein agiler Übergang einen Wechsel zu agilem Testen beinhaltet, und es gibt einige Möglichkeiten, dies zu erreichen:

  • Formulieren Sie einen Release-Testzyklus-Prozess.
  • Unterstützen Sie Tester mit Bereitstellungstools.
  • Experimentieren Sie mit testgetriebener Entwicklung und akzeptanztestgetriebener Entwicklung.
  • Entdecken Sie Ineffizienzen, indem Sie die Bewegung von Aufgabenkarten verfolgen.
  • Fügen Sie dem Skillset des QA-Teams Testautomatisierung hinzu.
  • Testerprioritäten verwalten.

Jedes Jahr wird die Software besser und die Erwartungen der Benutzer steigen. Da sich die Kunden an hochwertige Produkte von Top-Softwaremarken wie Google, Apple und Facebook gewöhnen, übertragen sich diese Erwartungen außerdem auch auf andere Softwareprodukte. Daher dürfte die Betonung der Qualität in den kommenden Jahren noch wichtiger werden. Diese Verbesserungen des Test- und gesamten Entwicklungsprozesses können das Testen agiler machen und ein hohes Maß an Produktqualität sicherstellen.