Tests in der Softwareentwicklung
Fehler und wie Sie diese vermeiden können
Häufige Argumente gegen ein extensives Testen in der Software Entwicklung lauten oft, dass dies nicht notwendig sei, weil im eigenen Unternehmen sehr viel Wert auf qualitatives Arbeiten gelegt wird. Dadurch wäre es möglich, bei den Software Tests Geld zu sparen. Bei genauerer Betrachtung ist jedoch schnell klar, dass diese beiden Punkte sich sehr schnell widerlegen lassen.
Folgen: Fehlende Features und unzufriedene End-User
Denn bei der Kommunikation zwischen dem Kunden und dem Entwickler können in den verschiedenen Schritten Missverständnisse entstehen, sodass am Ende bei der releasten Anwendung Features fehlen oder sie nicht das kann, was sie sollte. Zudem kann man den menschlichen Faktor nicht vernachlässigen, d. h. Menschen machen bei bester Arbeit auch immer wieder Fehler. Außerdem können Veränderungen in einem bestehenden System zu Fehlfunktionen an anderer Stelle führen, die erst auftauchen, wenn ein End-User sich darüber beschwert.
Und hiermit sind wir schon bei eine der Folgen, wenn Unternehmen beim Testen sparen wollen. Fehler können zu Unzufriedenheit beim Kunden und damit zu einem Imageverlust führen. Hinzu kommt, dass die nach dem Release auftretenden Bugs möglichst schnell gefixt werden müssen. Die Entwickler sind während dieser Zeit gebunden und können nicht an der Entwicklung neuer Features weiterarbeiten, sodass sich die Weiterentwicklung des Projekts verzögert und damit Geld kostet, das durch das Testen eingespart hätte werden sollen.
Do‘s: Rechtzeitiger Start und dezidierte Rollenverteilung
All dies macht klar, dass Testen ein notwendiges Korrektiv in jeder Software Entwicklung ist. Doch was sollten Sie bei Software Tests beachten und was sollten Sie vermeiden? Wichtig ist es, die Testfälle rechtzeitig, d.h. bereits bei Erstellung der User Storys zu erstellen. Im besten Fall ist dafür ein unabhängiges Test-Team zuständig, das nicht zu nahe an der Entwicklung beteiligt ist, um auszuschließen, dass eine gewisse Betriebsblindheit entsteht. Gleiches gilt bei der Testdurchführung. Am besten testet niemand die eigenen Testfälle, sondern immer die, die ein anderer erstellt hat. Zusätzlich wird dadurch vermieden, dass durch den Product Owner der das Release genehmigen und damit alle Testfälle genehmigen muss, ein Nadelöhr entsteht, was zu Verzögerungen führen kann.
Essenziell ist es, auf eine gute Ausarbeitung der Testfälle zu achten. Das bedeutet, dass die Testfälle auf Grundlage der User Storys erstellt und bestenfalls alle dort aufgeführten Schritte abgedeckt werden. Das Testing sollte auch direkt nach der Umsetzung der User Story durch den Entwickler beginnen, um das Release Datum einhalten zu können. Zu jedem Test gehört zudem ein Test-Reporting, in dem genau festgehalten wird, was funktioniert hat und was nicht, um einen Überblick über die Fehler in einem Entwicklungssprint zu behalten. Eine große Hilfe kann eine Automatisierung von Testfällen für Standardanwendungsfälle, z.B. „Ich kann einen Text downloaden“ oder bei Fehlern sein, die immer wieder auftauchen.
20% des Projektvolumens für Software Tests einplanen
Natürlich sollte das Testen nicht überhandnehmen, eine Testabdeckung von 95% macht alle Kosteneinsparungen zunichte, da eine solche Quote nur durch intensives Testen erreicht werden kann. 20% des Projektvolumens sind ein guter Richtwert, an dem man sich bei der Einführung eines Testverfahrens orientieren kann. Sinnlos ist es jedoch, durch weniger Testen Geld einsparen zu wollen, da sich das durch den möglichen Imageverlust, die Ressourcenbindung bei Entwicklung für das Bugfixing und den damit verbundenen zeitverzögerten Release einer nachgelagerten Applikation nicht lohnt.
