Der ultimative Tester: Wertschöpfung

Es gab einmal eine Zeit, als Projektmanager noch glaubten, dass die Erstellung von Software eine völlig überschaubare und vorhersehbare Tätigkeit sei und Tester in ein separates Team gesteckt wurden, um ihre Unabhängigkeit zu gewährleisten - das Ergebnis war beschissene Software und frustrierte Menschen. Auch wenn der Aufstieg der agilen Arbeitsweise einige Aspekte der Softwareentwicklung verbessert hat, wird die Reise nie zu Ende sein. Wir haben noch eine Menge Arbeit vor uns. Die Entwicklung guter Software beginnt mit den Menschen, die sie erstellen, dem Team. Als agiler Tester, ein Tester 3.0, wenn Sie so wollen, sind Sie ein Vorreiter dieses Paradigmenwechsels.

Sie müssen nicht mehr in einem separaten Team sitzen und Anforderungen verarbeiten, um Testskripte zu erstellen, die Sie dann manuell ausführen, indem Sie vorgeben, ein menschlicher Computer zu sein (wie dumm ist das denn!). Sie müssen nicht mehr so tun, als ob Sie an einen Master-Testplan glauben, den Ihr Testmanager Ihnen aufdrängt. Sie müssen Ihre Fehler nicht mehr in ein Fehlerverwaltungs-Tool eingeben und dann ein paar Versionen lang warten, bis sie behoben sind.

Es ist an der Zeit, die Dinge selbst in die Hand zu nehmen. Es ist an der Zeit, von Anfang an Werte zu schaffen.

Bevor wir erörtern, was dieser "Wert" ist, sollten wir klarstellen, was er nicht ist. Von Anfang an einen Mehrwert zu schaffen, bedeutet in einem agilen Kontext: keinen detaillierten Testplan zu schreiben, keine riesige Risikobewertung im Voraus vorzunehmen. Das Schöne an der agilen Vorgehensweise ist, dass die Dinge klein und offen für Veränderungen bleiben. Der Wert liegt in der Erstellung funktionierender Software und im Versuch, Verschwendung zu vermeiden.

Vor der Codierung / Das Richtige bauen

Warum beginnen Sie nicht damit, die Anforderungen zu untersuchen, die Sie in User Stories oder Use Cases finden? Versuchen Sie, diese so klar und prägnant wie möglich zu formulieren, damit Sie in Ihrem Team ein gemeinsames Verständnis haben. Wenn Sie dann Ihre Anforderungen in Form von Testfällen niederschreiben (die Sie automatisieren können), haben Sie in mehrfacher Hinsicht einen Mehrwert geschaffen: Sie haben die Feedbackschleife verkürzt, Testfälle erstellt, mit denen die Entwickler arbeiten können, und Sie haben dabei hoffentlich ein paar unklare Anforderungen ausgemerzt. Diese Arbeitsweise ist nicht neu, aber sie wird nur sehr selten richtig ausgeführt. Es ist also ratsam, Zeit zu investieren, um zu lernen, wie man darin besser wird. Möchten Sie sich in diesem Bereich verbessern? Lesen Sie Dan Norths Sicht auf BDD und diesen Blogbeitrag mit einem Beispiel für die Arbeit mit Behaviour Driven Development. Auch das Buch Specification by Example ist eine gute Möglichkeit, Ihr Wissen über dieses Thema zu erweitern.

Perfekte Anforderungen bringen Sie jedoch nicht sehr weit, wenn sie das Produkt nicht voranbringen. Angenommen, Sie arbeiten an einer mobilen Anwendung und der Product Owner möchte eine neue Funktion auf eine Art und Weise implementieren, die nicht die nativen Komponenten des Betriebssystems nutzt, würden Sie dann nichts sagen? Proaktiv zu sein bedeutet, dass Sie sich zu Wort melden, wenn Sie auf der Grundlage von Fachwissen und Fakten der Meinung sind, dass eine andere Lösung besser wäre. Das können Sie tun, indem Sie eine ganz einfache Frage stellen: "Warum?" Techniken wie die 5 Warum's oder die sokratische Methode sind ausgezeichnete Möglichkeiten, um ein zugrunde liegendes Problem aufzudecken.

Ein weiteres häufiges Problem bei agilen Teams ist, dass sie sich völlig auf die Implementierungsdetails konzentrieren und vergessen, wofür sie das Ganze eigentlich machen. Als Tester ist Ihre Position im Team perfekt, um sich in technische Entscheidungen und die Programmierung einzubringen, aber auch, um dem Product Owner bei dem übergeordneten Ziel zu helfen. Sie sind in der Lage, sich in seine Lage zu versetzen und die Dinge aus einer geschäftlichen Perspektive zu sehen. Wenn Sie Ihr Wissen über Planungstechniken wie Impact Mapping erweitern, können Sie dem Unternehmen wirklich helfen, ein großartiges Produkt zu entwickeln. All dies können Sie tun, bevor Sie mit der Programmierung beginnen, mit dem übergeordneten Ziel, "das Richtige zu bauen" und das Unternehmensziel zu erreichen.

[caption id="attachment_18939" align="aligncenter" width="640"] Beispiel für eine Auswirkungskarte[/caption]

Nach der Kodierung / Messung

Natürlich ist das Erreichen des Geschäftsziels nicht von Anfang an möglich. Letztendlich müssen Sie Ihre Software entwickeln, testen und ihren Erfolg messen. Vergessen Sie also nicht den Wert von Metriken! In vielen Fällen ist es sehr hilfreich, zu messen, wie viele Benutzer Sie haben, wie sie Ihr Produkt nutzen, woher sie kommen und wie viel Geld sie ausgeben, um festzustellen, wie erfolgreich das Produkt ist. Aus der Testperspektive ist es auch ratsam zu messen, ob die Software abstürzt oder ob der Benutzer Fehler sieht. Analysen sind heutzutage sehr wichtig, und Sie können viele davon nutzen, um Ihr Verständnis für den Benutzer zu verbessern (hilfreich für Tests mit Personas) und um die Art und Weise zu verbessern, wie Sie testen (z.B. A/B-Tests). Wenn Sie mehr über Metriken erfahren möchten, sollten Sie das Buch The Lean Startup lesen, das sich auf das 'Warum' konzentriert. Das 'Wie' würde den Rahmen dieses Blogs sprengen und ist sehr kontextabhängig. Mein Rat ist: Seien Sie sehr vorsichtig mit Metriken, denn Sie kennen wahrscheinlich das Sprichwort "Es gibt Lügen, verdammte Lügen und Statistiken!".

Zusammenfassend lässt sich sagen, dass Tester nicht mehr warten müssen, bis die Codierung abgeschlossen ist, bevor sie einen Mehrwert schaffen können. Die Rolle des Testers hat sich in den letzten Jahren drastisch verändert, und man kann sich ein wenig entmutigt fühlen; es gibt so viele Dinge zu lernen! Ich hoffe, dieser Blogbeitrag hat Ihnen ein paar Anregungen gegeben, wie Sie Ihre Fähigkeiten in diesem Bereich verbessern können. Bitte teilen Sie uns Ihre Ideen mit, wie Tester einen Mehrwert schaffen.

Im nächsten Blogbeitrag werden wir über die einzigartige Neugier von Testern sprechen und darüber, wie wir diese für kritisches Denken über das Produkt und exploratives Testen nutzen. Wir hoffen, Sie beim nächsten Mal wieder hier begrüßen zu dürfen!