Wenn Bugs für richtig Ärger sorgen

Blog offline

Dieser Artikel stammt aus unserem Blog, der nicht mehr betreut wird. Für Neuigkeiten zu oose und interessante Inhalte zu unseren Themen, folgt uns gerne auf LinkedIn.

Vor einigen Tagen ging ein Comic bei XING um, das großen Anklang fand:

[caption id="attachment_49045" align="alignleft" width="501"] Quelle: monkey-user.com[/caption]

Zuwerfen von Bugs

Wir sehen hier die Auswirkungen der strikten Trennung von Test und Entwicklung und das sinnbildliche Zuwerfen von Bugs. Beides sind für mich keine Zutaten für gute Softwarequalität. Aber darum soll es an dieser Stelle gar nicht gehen.

Interessant ist vielmehr – und darum soll es gehen – die augenscheinliche Unzufriedenheit, die bei den Entwicklern durch das Zuwerfen der Bugs entsteht. Aus meiner Erfahrung heraus ist dies etwas, das grundsätzlich überall passieren kann, wo Test und Entwicklung involviert sind. Unabhängig vom Vorgehensmodell ist es eher die Regel, dass Bugs von einer Person gefunden werden, die in dem Moment die Rolle des Testers innehat. Wie dieser Bug von wem wie kommuniziert wird, ist häufig entscheidend für den Umgang mit dem Bug.

Fünf Dimensionen unseres Sozialverhaltens

Warum aber ist das so? Um dies zu beantworten, kann uns die Neurowissenschaft in Person von David Rock weiterhelfen. David Rock beschreibt in seinem Buch „Brain at work“ ein Modell namens SCARF. Dieses Modell geht davon aus, dass es fünf Dimensionen gibt, die unser Sozialverhalten beeinflussen:

Status
Certainty / Sicherheit
Autonomy / Autonomie
Relatedness / Verbundenheit
Fairness

Jede Interaktion kann hinsichtlich dieser Dimensionen als Bedrohung, neutral oder Belohnung eingeordnet werden. Grundsätzlich sind Menschen an einer Belohnung interessiert und bewerten Situationen negativ, wenn es einen Ausschlag Richtung Bedrohung gibt.

Scarf Modell

Wenden wir dieses Modell auf die Kommunikationssituation zwischen Entwicklungs- und Test-Abteilungen oder Test-Team an, stellen wir fest, dass ein Bug auf allen fünf Ebenen eine Bedrohung im Sinne des SCARF Modells sein kann.

Als Entwickler kann ich meinen Status gefährdet sehen (wie konnte mir so ein Fehler nur passieren?),
es kann für Unsicherheit sorgen (gemäß des Fehler Hot Spot Prinzips: Hoffentlich sind hier nicht noch mehr),
es kann die Autonomie einschränken (ich brauche externe Hilfe, um das Problem zu lösen),
es kann die Verbundenheit senken (Sollen die es doch besser machen, ich mache einfach mein Ding)
oder es kann auch als unfair empfunden werden (Warum kritisieren die ständig meine Arbeit? Und eigentlich ist das ja auch gar kein Fehler).

Wenn ich um diese Situationen weiß, dann hilft es mir, meine Kommunikation oder die Art und Weise der Zusammenarbeit anzupassen. Wenn ich beispielsweise jemanden vorwarne, dass und vor allem warum da ein Bug kommt, dann kann dies einiges an Unsicherheit nehmen. Genauso kann es für eine höhere Verbundenheit sorgen, wenn das Team zusammen an einem Ort sitzt und es offensichtlich wird, dass die gleichen Ziele verfolgt werden.

Und dies kommt nicht nur der Zusammenarbeit zugute, sondern auch der Softwarequalität.