22. Februar 2022
Eine agile Arbeitsweise wird in Projekten immer wichtiger, das Anpassen von Arbeitsweisen und das schnelle Reagieren auf sich ständig wandelnde Anforderungen sind ein häufiger Wunsch unserer Kunden.
Wir haben die Erfahrung gemacht, dass besonders in größeren und älteren Anwendungen jene Arbeitsweisen und Anforderungen an das Produkt manchmal etwas festgefahren sind.
Oft gibt es Funktionen, die wenn sie modifiziert werden, an einem anderen Ende etwas unbrauchbar machen; Alles, was neu hinzukommt, ist ein weiterer Risikofaktor für eventuelle Blocker und Release-Verschiebungen.
Dabei spielt es keine große Rolle, ob eine neue Funktion falsch verstanden wurde, oder ob an einer Stelle ein offenes Ende (lose end) übersehen wurde – Missverständnisse können die Wurzel allen Übels sein.
So einfach ist es aber nicht…
Es wäre einfach zu behaupten, dass gute Kommunikation das Problem an jener Wurzel packen könne und ein Allheilmittel sei – Hierbei essenziell ist (unserer Meinung nach), die Endkunden und die Nutzer* der Software miteinzubeziehen, um alle noch so unwahrscheinlichen Szenarien durchzuspielen. Tester* müssen individuelle, noch so kleine Funktionen immer im Gesamtbild und Zusammenspiel mit dem Produkt sehen können.
In der Praxis haben wir die Herausforderungen bei der Erstellung von User Stories in agilen Projekten immer wieder erlebt. Oft sind die Anforderungen an das Produkt in größeren und älteren Anwendungen festgefahren und der Code ist so alt, dass die aktuellen Entwickler* ihn nicht mehr komplett verstehen. Dies kann dazu führen, dass Änderungen an einer Stelle des Codes Auswirkungen auf andere Teile des Produkts haben und somit weitere Risikofaktoren darstellen.
Um diese Herausforderungen zu bewältigen, haben wir gelernt, dass es wichtig ist, die Endkunden und Nutzer* der Software miteinzubeziehen, um mögliche Missverständnisse und Szenarien im Vorfeld abzufangen. Als Tester* müssen wir immer das Gesamtbild im Blick haben und die richtigen Fragen stellen, um gegebenenfalls die User Stories anzupassen.
In der Praxis…
Ein Beispiel aus der Praxis ist der Fall eines neuen Feldes auf einer Mobile-Anwendung, der auf verschiedenen Geräten unterschiedlich angezeigt wird. Auf den ersten Blick mag diese Funktion trivial und einfach zu testen erscheinen, doch bei genauerem Hinsehen stellen sich viele Fragen: Skaliert sich der Text in diesem Feld auch immer? Wie wird das Feld auf verschiedenen Geräten angezeigt? Wie ist die Lesbarkeit bei verschiedenen Auflösungen? Passt die Funktion ins Gesamtbild der Anwendung?
Daraus ergibt sich…
Es zeigt sich, dass jede noch so kleine Funktion in agilen Projekten genau betrachtet werden muss, um spätere Nacharbeit und Zeitverluste zu vermeiden. User Stories in agilen Projekten sind zwar flexibel, doch es ist wichtig, sie sorgfältig zu erstellen und gegebenenfalls anzupassen, um erfolgreich zu sein.
Hier zeigt sich, jede noch so kleine Funktion muss granular betrachtet werden, dies kann in späteren Iterationen sehr viel Nacharbeit und Zeit sparen.
Als Tester* gilt es die richtigen Fragen zu stellen, um, gegebenenfalls, die Stories den tatsächlichen Anforderungen anzupassen. User Stories sind in agilen Projekten schließlich nicht in Stein gemeißelt.
Wenn Sie mehr dazu erfahren möchten oder an einer direkten Unterstützung interessiert sind, kontaktieren Sie uns gerne.
Wir von HiQ Projects freuen uns auf den Austausch und ein unverbindliches Gespräch mit Ihnen.
* Um einen besseren Lesefluss zu ermöglichen, nennen wir hier nur eine Form, meinen aber alle Geschlechter (m/w/d) und möchten Niemanden ausschließen.
