Business Analysten (beziehungsweise Requirements Engineers) und Tester sind bekanntlich nicht immer gleicher Meinung. Hinter dem diplomatischen Lächeln auf dem Gang herrscht oft Unverständnis für die Taten des Gegenübers. Der Tester würde es in der Business Analysten Rolle sowieso anders machen und umgekehrt. Solche Gedankenexperimente werden jedoch nur selten wahr. In diesem Beitrag berichte ich, wie mir das Privileg zuteil wurde beide Rollen innerhalb kurzer Zeit einnehmen zu dürfen und was ich daraus lernen konnte.
Der Sprung ins kalte Wasser - Testing im neuen Projekt
Neu im Projekt zu sein ist meiner Meinung nach immer aufregend. Man lernt die Projektteams, -strukturen, -tools und -vorgehensweisen kennen. Als Tester durfte ich Testfälle aus bestehenden Anforderungen (Requirements) generieren. An sich eine klare Aufgabenstellung. Allerdings ist mir nach einigen Wochen aufgefallen, dass man als Tester unter sich ständig ändernden Anforderungen doch ein wenig zu leiden hat:
- Testfälle müssen immerzu aktualisiert werden
- Der Umfang ist nicht immer von Anfang an (bei der Erstellung des Testfälle) klar
- Testfälle müssen archiviert werden, da diese auf gelöschte Anforderungen verweisen.
Sowas schreit nach enger Zusammenarbeit zwischen Business Analyse (BA) und Test. Die BAs waren jedoch immerzu eng angebunden und gingen selten auf meine Verbesserungsvorschläge bezüglich der Anforderungen ein. Zumindest war das mein Eindruck. Dieser sollte sich jedoch in einigen Monaten von Grund auf ändern, denn mir wurde mitgeteilt, dass ich in kurzer Zeit für die Anforderungen im Projekt verantwortlich sein würde.
Aus dem Regen in die Traufe - Auf in die Business Analyse
Voller Elan machte ich mich in meiner neuen Rolle ans Werk die Anforderungen endlich den Wünschen der Tester anzupassen. Nebst den Testern kamen aber bald auch andere Stakeholder auf mich zu, mit Änderungswünschen an den spezifizierten Anforderungen. Plötzlich sollten meine Anforderungen es allen recht machen:
- Quality Engineers
- Tester
- Entwickler
- System-Integratoren
- Produkt Manager
- Projektleiter
Ich musste beim Inhalt der Anforderungen nun also einen Konsens zwischen allen Stakeholdern finden. Ganz plötzlich erschienen mir die Wünsche der Tester als beträchtlich weniger bedeutend, als noch in meiner letzten Rolle. Auch ich hatte nun viel zu wenig Zeit, um mich um die Bedürfnisse und Wünsche der Tester zu kümmern - musste diese sogar verneinen. Es tat mir dementsprechend leid die Tester vertrösten zu müssen, oder ihre Änderungswünsche (Detailverliebtheit!?) zurückzuweisen.
Ich habe mir vorgestellt wie wenig begeistert die Tester von meinem Vorgehen sein mussten. Nachdem ich erfuhr, dass ein Engpass im Testing enstanden ist, ahnte ich bereits, dass mir ein Wechsel zurück zum Test Team bevorstand.
Back to the Roots - Wieder Testing
Nun lag mein Fokus wieder auf den Testfälle mit welchen ich wieder Anforderungen testen sollte. Es dauerte nicht lange und meine Anliegen gegenüber den BAs nahmen zu. Doch diesmal wusste ich wieso die Anforderungen so geschrieben wurden. Eines guten Tages machte ich mir Gedanken wie es zu diesem "Missverständnis" zwischen BAs und Testern gekommen ist und was man dagegen tun könnte. Ich will hierbei gerne auf zwei Themen präziser eingehen.
Die richtige Kommunikation und Empathie sind schon die halbe Miete
Kommunikation
Man hört es immer wieder. Die Kommunikation sei sehr wichtig. Man nimmt es sich vor, so viel wie möglich miteinander "zu reden". Leider bleibt es nur bei dem guten Vorsatz, vor allem unter Zeitdruck.
Als Tester habe ich mich immerzu darüber beschwert, dass von den BAs nicht genug Zeit in die Kommunikation investiert wird. Entscheidungen waren mir nicht immer verständlich oder sind erst spät im Team angekommen. Änderungen an Anforderungen wurden von uns bemerkt, anstatt von den BAs kommuniziert zu werden.
Als BA hatte ich leider nicht genügend Zeit um Entscheidungen über und Änderungen an den Anforderungen ausführlich zu kommunizieren. Wie man es dreht und wendet, diese Aufgabe darf man nicht vernachlässigen. Es wird oft als selbstverständlich angesehen und fliesst deshalb nicht in die Planung ein. In meiner Rolle als BA werde ich in Zukunft eine ausführliche Kommunikation gegenüber den Testern einplanen.
Empathie und (Un)nachgiebigkeit
Den Austausch der Sätze "Ich bin mit dir einverstanden." oder "Das kann ich nachvollziehen." habe ich im Projekt oft beobachtet, leider kein einziges Mal zwischen Testern und BAs. Es ist natürlich nicht einfach Verständnis für etwas aufzubringen, vor allem wenn es dem eigenen Interesse widerspricht. Mit dieser Situation gehe ich auf zwei Arten um:
- Auch wenn es manchmal schwerfällt, man sollte immer versuchen eine Situation aus dem Blickwinkel des Gegenübers zu betrachten. Dies kann man natürlich nur, wenn man die Situation dieser Person kennt. Man muss also viele Fragen stellen und geduldig zuhören. Nachdem man sich einen Überblick über die Situation verschafft hat, kann man Entscheidungen besser nachvollziehen. Hierfür habe ich in meiner BA Rolle eine wöchentliche Fragestunde für die Tester eingeführt, um ihnen meine Entscheidungen näher zu bringen oder gewisse Änderungen an den Anforderungen zu kommunizieren.
- Im Englischen gibt es den Begriff "Resilience". Dieser steht für Nachgiebigkeit, Ausdauer und Widerstandsfähigkeit. Ich interpretiere es so, dass man an dem Kern seiner Ideen festhalten sollte, jedoch auch in gewissen Situationen nachgeben bzw. sich anpassen kann. Man sollte sozusagen nachgiebig und gleichzeitig unnachgiebig sein. Nachdem ich aus der Business Analyse ins Testing Team zurückkehrte, versuchte ich nach diesem Prinzip zu handeln. Ich platzierte meine Ideen bei den BAs und holte zeitnah Feedback über diese ein. So blieb ich auf dem Laufenden was Änderungen an den Anforderungen betraf und konnte Entscheidungen der BAs besser verstehen.
Durch die beiden oben genannten Massnahmen konnte ich meine Ideen bei dem gegenüberliegenden Team (als BA beim Testing Team und als Tester beim BA Team) einbringen und gleichzeitig eine kollegiale Beziehung aufbauen, welcher mir erlaubte eine konstruktive Zusammenarbeit zu betreiben.
Business Value im Auge behalten
Auch wenn BAs nicht immer mit den Testern einverstanden sind (und umgekehrt) sollte man am Ende immer den Business Value im Auge behalten. Manchmal verzettelt man sich in Kleinigkeiten und verliert das Ziel aus dem Auge. Am Ende kommt es doch darauf an ein gutes Produkt nach Kundenwunsch zu liefern. Und hierfür sollte das ganze Projektteam an einem Strang ziehen. Somit haben Tester und BAs doch mehr gemeinsam als gedacht, nämlich das Produkt, auf das am Ende beide Rollen gleichermassen stolz sein können.