Qualitätssicherung erst nach dem Abschluss eines Entwicklungsprojekts? Das war einmal. Denn egal ob im agilen Umfeld, im Rahmen des klassischen Wasserfallmodells oder bei Mischformen: Mit dem Testen wird heute bereits frühzeitig begonnen. Manche Probleme zeigen sich jedoch erst, wenn der End-User das System anwendet. In unserem Fall geht es dabei um Fachbereiche (etwa aus Marketing oder Sales), die eine Software (z. B. ein CRM-System) in ihrer täglichen Arbeit nutzen sollen.
Plötzlich stehen dann Fragen im Raum: „Warum funktioniert mein Prozess nicht mehr?“ „Wo sind meine gewohnten Eingabemasken?“ „Warum muss ich jetzt diesen unnötigen Schritt machen?“ Das Resultat? Frustration. Die Software wird beispielsweise als zu komplex wahrgenommen. Die Akzeptanz fehlt. Und im schlimmsten Fall leiden die Produktivität und die Effektivität der Software-Einführung.
Software-Akzeptanz im Fokus
Hier lohnt es sich, kurz auf die Bedeutung von Quality Assurance im Prozess einzugehen. Denn es geht heute um mehr als nur klassische Qualitätssicherung. Der Fokus liegt vielmehr darauf, Akzeptanz und Verständnis für die Software zu schaffen.
Das bedeutet: Eine Software soll so gestaltet sein, dass sie die Bedürfnisse der End-User erfüllt. Dafür muss der entsprechende Fachbereich jedoch als aktiver Teil des Teams eingebunden werden. Nur so fühlt er sich gehört – und nicht außen vorgelassen, nachdem die Anforderungen von Business-Analysten dokumentiert und an das Entwicklungsteam weitergereicht wurden.
Doch zu oft werden Fachbereiche während eines Projekts nur sporadisch über Fortschritte informiert. Und am Ende fühlen sie sich vor den Kopf gestoßen, weil nichts mehr so funktioniert wie gewohnt. Die Folge: Ablehnung der Software, gesenkte Produktivität und letztlich auch finanzielle Verluste für das Unternehmen.
Wie kann Qualitätssicherung dabei helfen, Akzeptanz zu schaffen?
Fachbereiche werden als End-User oft nur zu Beginn des Projekts in die Anforderungserhebung einbezogen – und am Ende sehen sie nur das fertige Produkt. Feedback kann dann kaum noch in den Entwicklungsprozess einfließen und Anpassungen sind schwer umzusetzen.
Agilität bietet hier bereits Vorteile. Denn Releases erfolgen schneller – und es wird laufend Feedback eingeholt. Doch es gibt noch mehr Potenzial: Warum nicht den Fachbereich fest in das Sprint-Team integrieren und ihn auch für Tests mitverantwortlich machen?
So wird der Fachbereich aktiv in die Entwicklung eingebunden. Dabei kann er sicherstellen, dass die Software seine täglichen Prozesse unterstützt, anstatt zu einer zusätzlichen Belastung zu werden.
Aktiver Beitrag des Fachbereichs zur Qualitätssicherung:
Die Integration des Fachbereichs kann in verschiedenen Phasen vor dem Go-Live erheblichen Mehrwert bieten:
- Fester Bestandteil des User-Story- und Anforderungs-Refinements: Wenn Missverständnisse und Fragen bei der Ausarbeitung der User Stories auftauchen, kann sie der Fachbereich sofort klären.
- Integration als Teammitglied: Entscheidungen können gemeinsam getroffen werden – und die Sicht des Fachbereichs ist immer präsent.
Frühe Einbindung in den Testing-Prozess
Beim Thema Testing denkt man oft an den User Acceptance Test (UAT), bei dem der Fachbereich das fertige Produkt testet. Doch hier liegt der Fehler: Das Feedback, das in dieser späten Phase gegeben wird, ist oft ein Indikator für die Akzeptanz der Software. Doch grundlegende Änderungen sind zu diesem Zeitpunkt nur noch schwer umzusetzen.
Stattdessen sollte der Fachbereich in den Testing-Prozess eingebunden werden, sobald erste Produktinkremente fertig sind. Dies kann deutlich früher als beim finalen UAT geschehen. So lassen sich bereits in der Entwicklungsphase erste Tests durchführen und wertvolles Feedback einholen. Dem Entwicklungsteam gibt das die Möglichkeit, Anpassungen rechtzeitig vorzunehmen und Fehler zu beheben, bevor sie den End-User frustrieren.
Doch trotz einer frühzeitiger Einbindung bleibt der UAT ein wichtiger Meilenstein am Ende des Entwicklungsprozesses. Hier sollte ein erweiterter Kreis aus dem Fachbereich einbezogen werden, um sicherzustellen, dass möglichst viele Perspektiven in das abschließende Feedback einfließen.
Fazit: Der Fachbereich als fester Teil des Teams
Die Integration des Fachbereichs als festes Teammitglied hat zahlreiche Vorteile. Denn wenn er regelmäßig in Meetings und Entscheidungsprozesse eingebunden ist, entsteht ein Gefühl der Zugehörigkeit. Und da er auf diese Weise direkten Einfluss auf die Entwicklung nehmen kann, steigt die Akzeptanz der Software. Schließlich ist sie am Ende so gestaltet, dass sie End-User in ihrer täglichen Arbeit unterstützt – anstatt sie zu erschweren.
