olly - Fotolia
Der agile Testprozess: Warum man Tests immer wieder wiederholt
Es ist nicht agil, einen Testprozess immer wieder zu wiederholen. Doch es ist ein häufiges Problem. Agile Tests sollten daher überdacht werden.
Es kommt immer wieder vor, dass Tests wiederholt werden müssen. Wie lässt sich das Problem in der agilen Softwareentwicklung beheben?
Ich habe in den vielen Jahren, die ich in agilen Entwicklungsteams arbeite, immer wieder erfahren müssen, dass ich den Testaufwand zwei-, drei- oder sogar viermal wiederholen musste. Mit anderen Worten: Im eingesetzten agilen Testprozess testete ich die gleiche Sache mehrmals in einer Reihe ähnlicher, aber dennoch unterschiedlicher Serverumgebungen.
Dies sind keine unterschiedlichen Plattformen oder Versionen. Es sind verschiedene Server, die Continuous Deployment und Integration beherbergen. Der finale Testserver sollte dabei dem Produktionsserver so ähnlich wie möglich sein. Produktionsserver werden nur selten getestet, selbst bei automatisierten Tests. Der Grund, warum ich die Tests wiederhole, ist die Anhäufung von unbrauchbaren Testdaten, welche die Leistung und/oder Anwendungsfunktionen beeinflussen.
Das schlimmste, was ich allerdings je erlebt habe, sind Tests auf drei Servern innerhalb von drei oder weniger Tagen. Dennoch traten die Fehler auf keinen der drei Server, aber im produktiven Umfeld auf. Ich konnte nicht verstehen, warum ein dupliziertes Produktionsserver-Setup und eine praktisch identische Datenkonstruktion nicht für Qualitätssicherungstests möglich sind. Dies würde die Notwendigkeit beseitigen, unnötige Tests über mehrere Server zu wiederholen, während die Anwendung kontinuierlich bereitstellt und integriert wird. Ich würde nicht mehr als zweimal testen müssen – einmal für die Qualitätssicherung und einmal im Produktivbetrieb oder einer exakten Kopie der Produktionsumbegung.
Ist es agil, Testausführungen mehrmals zu wiederholen? Wenn ich immer wieder auf Servern teste, die keine Produktionsserver sind, lohnt sich dann die doppelte Arbeit, der doppelte Stress und die doppelt investierte Energie? Ich würde auf die Fragen mit nein antworten.
Doppelte Arbeitsaufgaben reduzieren
Ich glaube wirklich, dass sich der produktive Einsatz auf sichere, effektive Weise testen lässt. Man kann einen agilen Testprozess auf dem aktuellen Produktionsserver machen, womit es möglich ist, eine exakte Kopie zu testen. Auf diese Weise testen Qualitätssicherungstester die Qualität der Anwendung einmal in der Testumgebung der Qualitätssicherung und einmal mit der Kopier der Produktionsumgebung. Warum sollten die Qualitätssicherungstests nicht auf einen reduziert werden? In der Produktionskopie sollten Entwicklungsskripte enthalten sein, um sicherzustellen, dass der erwartete Code nach dem finalen Deployment vorhanden und intakt ist.
Der agile Testprozess sollte keine doppelten Arbeitsaufgaben umfassen. Das reduziert die Arbeitsproduktivität, Effizienz und Qualität. Entwickler ärgern sich ständig über sich wiederholende Aufgaben und ihre Motivation sinkt mit der Zeit. Die Qualität verbessert sich nicht, wenn Aufgaben schnell und ineffizient ausgeführt oder wiederholt werden müssen.
Agile Teams und Entwicklungsabteilungen benötigen fokussierte und sorgfältige Ressourcen. Sie sollten daher Qualität und Effektivität verbessern. Außerdem sollte man auf richtigen Systemen oder exakten Kopien des tatsächlichen Produktionssystems testen, um Code-Qualität und Testausführungsergebnisse zu verbessern.
Folgen Sie SearchEnterpriseSoftware.de auch auf Twitter, Google+, Xing und Facebook!
Erfolg mit Low-Code-Plattformen
Mit No-Code-/Low-Code-Entwicklungsplattformen lässt sich Software unter Verwendung visueller Design-Tools generieren. Unternehmen müssen ergänzend feste Standards setzen und in die Weiterbildung ihrer Mitarbeiter investieren, um optimale Apps mit den Plattformen entwickeln zu können. Diesem Ziel widmet sich der vorliegende E-Guide.
