Ein Leitfaden für Anwender, Product Owner und Produktmanager
Wer in Softwareprojekten arbeitet, kennt die Situation: Ein Anwender meldet, dass etwas „falsch“ ist. Für ihn ist die Sache klar. Die Anwendung verhält sich nicht wie erwartet. Im Entwicklungsteam beginnt hingegen oft die Diskussion: Ist das tatsächlich ein Fehler? Ist das eine neue Anforderung? War das überhaupt jemals so vereinbart?
Genau an dieser Stelle zeigt sich, dass nicht jede Abweichung von den Erwartungen eines Anwenders automatisch ein Bug ist. Für die tägliche Arbeit von Product Ownern, Produktmanagern und Entwicklungsteams lohnt es sich daher, die Begriffe sauber voneinander zu trennen. Nicht aus akademischen Gründen, sondern weil die Einordnung unmittelbare Auswirkungen auf Priorisierung, Aufwandsschätzung und Verantwortlichkeiten hat.
Bug, Defect und Feature Request
Im Sprachgebrauch werden die Begriffe oft durcheinander verwendet. Für die praktische Arbeit hat sich jedoch folgende Unterscheidung bewährt.
Ein Bug liegt vor, wenn sich die Software anders verhält als in den abgestimmten Anforderungen beschrieben. Das bedeutet nicht zwangsläufig einen Absturz oder eine Fehlermeldung. Auch scheinbar kleine Abweichungen sind Bugs.
Beispielsweise wurde vereinbart, dass eine Projektliste standardmäßig nach Projektnummer sortiert wird. Nach dem Release wird die Liste jedoch standardmäßig nach Erstellungsdatum sortiert angezeigt. Die Anwendung funktioniert technisch einwandfrei, das Verhalten weicht aber von der vereinbarten Anforderung ab. Damit handelt es sich um einen Bug.
Ein Defect liegt dagegen vor, wenn die Anwendung von einer berechtigten Erwartung des Anwenders oder Stakeholders abweicht, diese Erwartung aber nie als Anforderung festgelegt oder an die Entwicklung kommuniziert wurde.
Aus Sicht eines Anwenders ist dieser Unterschied oft kaum erkennbar. Der Anwender weiß normalerweise nicht, welche Details tatsächlich vereinbart wurden und welche nicht. Für ihn ist beides schlicht ein Fehler. Für Product Owner und Produktmanager ist die Unterscheidung jedoch wichtig, da sie in der Regel Einblick in Anforderungen, Spezifikationen und Abstimmungen haben.
In der Praxis können Defects unterschiedliche Ursachen haben. Zwei häufige Ausprägungen sind das Anforderungsdefizit und die Verhaltenslücke (englisch Behaviour Gap).
Bei einem Anforderungsdefizit wurde ein relevanter Anwendungsfall oder eine fachliche Erwartung in den Anforderungen nicht ausreichend beschrieben oder sogar vollständig übersehen. Die Entwicklung hat die vorhandene Spezifikation korrekt umgesetzt, die Spezifikation selbst war jedoch unvollständig.
Ein typisches Beispiel ist eine Exportfunktion, bei der festgelegt wurde, welche Daten exportiert werden sollen, jedoch nicht, wie mit sehr großen Datenmengen umzugehen ist. Sobald die ersten Anwender mehrere Tausend Datensätze exportieren möchten, zeigt sich, dass ein wichtiger Anwendungsfall nie betrachtet wurde.
Eine Verhaltenslücke liegt vor, wenn sich die Anwendung zwar entsprechend der Anforderungen verhält, dieses Verhalten jedoch nicht den tatsächlichen Erwartungen oder gängigen Nutzungsmustern der Anwender entspricht.
Beispielsweise unterscheidet eine Suchfunktion zwischen Groß- und Kleinschreibung. Dieses Verhalten wurde nie spezifiziert und ist technisch korrekt umgesetzt. Viele Nutzer erwarten heute jedoch eine nicht case-sensitive Suche. Die Software erfüllt die dokumentierten Anforderungen, verfehlt aber die praktische Nutzererwartung.
Ein Defect bedeutet daher nicht zwingend, dass die Entwicklung einen Fehler gemacht hat. Oft zeigt er vielmehr, dass die Beteiligten unterschiedliche Vorstellungen vom gewünschten Verhalten hatten oder dass wichtige Anforderungen während der Analyse nicht ausreichend herausgearbeitet wurden.
Ein Feature Request beschreibt schließlich eine neue Funktion oder eine Erweiterung bestehender Funktionalität. Die Software verhält sich dabei genauso wie vereinbart.
Wenn Anwender beispielsweise zusätzlich zur bestehenden Sortierung nach Namen auch nach Erstellungsdatum sortieren möchten, dann handelt es sich nicht um einen Fehler, sondern um einen Erweiterungswunsch.
Dadurch entsteht eine Hierarchie, die aus Product-Owner-Sicht häufig sehr hilfreich ist:
- Bug → Anforderung verletzt
- Defect
- Anforderungsdefizit → Anforderung unvollständig oder fehlend
- Verhaltenslücke (Behaviour Gap) → Anforderung erfüllt, aber Nutzererwartung nicht
- Feature Request → neue Funktion oder Erweiterung
Warum die Unterscheidung?
Eine gute Einordnung hat weit mehr als nur terminologische Bedeutung.
Zum einen ist es die Priorisierung. Ein Bug signalisiert, dass eine bereits zugesagte Funktion nicht korrekt umgesetzt wurde. Dadurch besteht unmittelbar die Gefahr, dass Anwender ihre Arbeit nicht wie vereinbart erledigen können.
Ein Requirement Gap oder Defect im oben beschriebenen Sinne kann zwar ebenfalls sehr relevant sein, stellt aber oft eine neue Erkenntnis über die tatsächlichen Nutzerbedürfnisse dar. In vielen Organisationen werden daher Bugs zunächst höher priorisiert als solche fachlichen Lücken. Natürlich gibt es Ausnahmen. Ein nicht spezifizierter, aber geschäftskritischer Anwendungsfall kann wichtiger sein als ein kosmetischer Bug.
Zum zweiten ist die Unterscheidung wichtig um Verantwortlichkeiten und Kosten richtig zuordnen zu können.
Insbesondere bei der Zusammenarbeit mit externen Dienstleistern spielt diese Unterscheidung häufig eine erhebliche Rolle.
Liegt ein Bug vor, wurde eine vereinbarte Anforderung nicht korrekt umgesetzt. Die Verantwortung liegt dann typischerweise bei der Entwicklung beziehungsweise beim Auftragnehmer. Die Behebung erfolgt häufig im Rahmen von Gewährleistung, Wartung oder des ursprünglichen Leistungsumfangs.
Liegt dagegen lediglich eine nicht spezifizierte Nutzererwartung vor, hat die Entwicklung nach den vorhandenen Anforderungen korrekt gearbeitet. In diesem Fall handelt es sich faktisch um eine neue oder präzisierte Anforderung. Der Aufwand für Analyse, Umsetzung und Test wird üblicherweise dem Auftraggeber zugerechnet.
Gerade deshalb sollte ein Product Owner vorsichtig sein, jeden gemeldeten Fehler automatisch als Bug zu klassifizieren.
Wie ein guter Bugreport aussehen sollte
Unabhängig davon, ob sich später herausstellt, dass es sich um einen Bug, einen Requirement Gap oder einen Feature Request handelt, sollte die ursprüngliche Meldung immer möglichst neutral formuliert werden.
Ein häufiger Fehler besteht darin, bereits die Ursache beschreiben zu wollen:
Die Datenbank speichert die Daten nicht.
Der Anwender weiß in der Regel gar nicht, ob tatsächlich die Datenbank die Ursache ist.
Deutlich hilfreicher ist eine reine Beobachtung:
Nach dem Speichern erscheint die Meldung „Erfolgreich gespeichert“. Nach dem Neuladen der Seite ist der Datensatz / die Änderung jedoch nicht (mehr) vorhanden.
Ein guter Report beschreibt zunächst nur die Fakten:
- Was wurde getan?
- Was wurde erwartet?
- Was ist stattdessen passiert?
- Unter welchen Bedingungen trat das Problem auf?
Gerade bei Web-Anwendungen sind die konkreten Schritte zur Reproduktion oft wichtiger als jede technische Analyse.
Statt zu schreiben:
Das Projektmodul funktioniert nicht.
ist folgende Beschreibung deutlich wertvoller:
Als Projektleiter öffne ich Projekt 4711. Nach Klick auf „Status ändern“ wähle ich den Wert „Freigegeben“ und speichere. Anschließend erscheint eine Erfolgsmeldung. Nach Aktualisierung der Seite steht der Status wieder auf „In Bearbeitung“.
Zusätzliche Informationen wie Browser, Benutzerrolle, URL, Zeitpunkt des Auftretens oder Screenshots helfen dem Team bei der Analyse erheblich. Besonders hilfreich sind Angaben dazu, ob das Verhalten immer oder nur sporadisch auftritt.
Die Aufgabe des Product Owners
Anwender sollten nicht gezwungen sein, zwischen Bug, Defect und Feature Request zu unterscheiden. Sie melden eine Beobachtung. Das ist völlig ausreichend.
Die eigentliche Einordnung ist Aufgabe des Product Owners oder Produktmanagers.
Dazu gehört insbesondere die Frage:
Weicht das Verhalten von einer abgestimmten Anforderung ab oder lediglich von einer Erwartung?
Erst nachdem diese Frage beantwortet wurde, sollte die weitere Klassifizierung erfolgen.
Ein guter Bugreport beschreibt daher zunächst beobachtbares Verhalten und vermeidet vorschnelle Schuldzuweisungen. Er liefert genügend Informationen, damit Product Owner und Entwicklung den Sachverhalt objektiv bewerten können. Die anschließende Einordnung als Bug, Requirement Gap oder Feature Request wird dadurch erheblich einfacher und Konflikte zwischen Fachbereich, Auftraggeber und Entwicklungsteam werden reduziert.
Am Ende ist ein guter Bugreport nicht nur eine Fehlermeldung, sondern ein möglichst präziser fachlicher Bericht über eine Beobachtung. Genau das macht ihn wertvoll.
This post is also available in:
