Agiles Testen: Die Dinge zu Ende bringen!

Seit einigen Jahren arbeite ich als Testerin in agilen Projekten. In unseren Projekten probieren wir neue Wege aus, um das Testen in den Entwicklungszyklus zu integrieren und unseren Kunden idealerweise eine komplette Projektlösung anzubieten. Meiner Ansicht nach wäre das perfekte Angebot, mit jedem Entwicklungszyklus eine funktionierende Software zu erstellen, die den Status 'Done' hat. Und zwar nicht nur aus der Sicht der Entwicklung, sondern auch aus der Sicht des Kunden. In der Praxis haben wir diesen Punkt bereits erreicht, aber für einen zahlenden Kunden ist das Testen eine Verantwortung, die man nicht einfach in die Hände von Fremden legt. Also wird ein unabhängiges Testteam an einem anderen Ort eingesetzt, das die endgültige Entscheidung trifft. In dem Projekt, an dem ich derzeit arbeite, führen wir in jedem Entwicklungszyklus Unit-, System- und Funktionstests durch, und keine Funktionalität wird freigegeben, ohne dass sie zuvor gründlich abgenommen wurde. Ein kompletter Abnahmetest scheint ein bisschen viel Aufwand zu sein, da unser Kunde seine eigenen Abnahmetests durchführt, nachdem wir geliefert haben. Aber es hat sich auf jeden Fall als vorteilhaft erwiesen. Wir arbeiten an einem Projekt für eine große Eisenbahngesellschaft in den Niederlanden und die Anforderungsanalysten des Kunden sahen zunächst nicht den zusätzlichen Nutzen eines zusätzlichen Testers im Entwicklungsteam. Aber nach einiger Zeit gewöhnten sie sich daran, zu allen Details einer Anforderung befragt zu werden, so dass diese im Laufe der Zeit klarer und weniger zweideutig wurden. Nachdem ich ein besseres Verständnis des Systems erlangt hatte, begann dies sogar in beide Richtungen zu gehen. Die Analysten kommen jetzt zu mir, um neue Funktionen zu besprechen und zu entwickeln.Anfangs war die Arbeit des Testteams des Kunden sehr intensiv, aber aufgrund unserer umfangreichen Testbemühungen schien dies fast nutzlos zu sein. Die Anzahl der Probleme, die vom Kunden kommen, ist vernachlässigbar und der Schweregrad aller Probleme ist gering (die Anzahl der Probleme war 10 mit jeder zweiwöchigen Veröffentlichung). Derzeit hat der Kunde immer noch sein eigenes Abnahmetestteam, aber die Zeit, die für das Testen unserer Software aufgewendet wird, wurde auf ein Minimum reduziert. Auf diese Weise werden Ressourcen gewonnen, die für das Testen anderer Anwendungen verwendet werden können.Als ich anfing, waren sogar unsere eigenen Entwickler skeptisch, was meinen Mehrwert anging. Aber mit der Zeit haben sie sich mit meiner Rolle im Projekt angefreundet. Wir haben herausgefunden, dass durch das Nachdenken über die Testbarkeit einer Funktion und die gemeinsame Ausarbeitung der Testfixtures Probleme mit der gewählten Technologie oder den Anforderungen in einem sehr frühen Stadium gefunden werden, wenn die Anpassung der Strategien noch sehr einfach ist. Auch das Verständnis für die Wünsche des Kunden wächst während dieses Prozesses, so dass wir alle einen besseren Job machen können. Ich denke, dass ich mich als Tester sehr stark auf das gesamte System aus einer funktionalen Sicht konzentriere, während die meisten Entwickler sich auf einen bestimmten Teil des Systems konzentrieren, der von ihrer Arbeit betroffen ist, und zwar aus einer eher technischen Perspektive. Es versteht sich von selbst, dass die Kombination dieser Sichtweisen von großem Wert für die Gesamtqualität des Produkts ist. Ich glaube, dass unser Ansatz funktioniert, weil wir uns bemühen, mit dem Kunden und nicht für den Kunden zu arbeiten. Diese Idee basiert jedoch vollständig auf Vertrauen und ich denke, die Menschen müssen das erst in der Praxis herausfinden, bevor sie sich tatsächlich trauen, sich darauf zu verlassen. Aber mit mehr Praxisbeispielen, die unsere Strategie untermauern, können wir schon bald den feuchten Traum eines jeden Projektmanagers erfüllen und qualitativ hochwertige Software ohne die lästige und zeitraubende Phase der Abnahmetests entwickeln.