Teil 01 | 02 | 03 | 04 | 05 | 06 | 07 | 08 | 09 | Kapitelauszug aus "Software-Qualität in PHP-Projekten", 2. Auflage. Erschienen im Hanser-Verlag, April 2013.
Strategische Argumente für die Einführung testbasierter Entwicklung
Für jedes Projekt ist das Maß der Testautomatisierung und -abdeckung aus betriebswirtschaftlicher Sicht mit Berücksichtigung der Team-Motivation korrekt zu bestimmen.
Die Einführung testbasierter Entwicklung ist nicht alleine ein technisches Vorgehen zur Sicherung von interner Softwarequalität. Testbasierte Entwicklung induziert weitere Verfahren im Umfeld der Software-Entwicklung, die eine qualitätsvolle Software fördern:
-
Durch eine testbasierte Entwicklung ermöglicht das Software-Team eine nachhaltige Weiterentwicklung des Systems. Insbesondere Fehler durch Seiteneffekte werden während der Weiterentwicklung vermieden. Auch bei komplexen Systemen ist die gesamte Funktionalität im Erweiterungs- beziehungsweise Anpassungsfall gesichert.
-
Eine testbasierte Entwicklung führt zu einer aktiven Auseinandersetzung mit möglichen Risiken. Ein transparenter Umgang mit Risiken ist für den Auftraggeber genauso wertvoll wie für das Software-Team.
-
Durch eine testbasierte Entwicklung sinken die Betriebs- und Wartungskosten. Notwendige Anpassungen können schneller vorgenommen werden als in Systemen, in de- nen eine hohe technische Schuld aufgebaut worden ist.
-
Der Abnahme- und Freigabeprozess wird für den Auftraggeber erleichtert. Durch das automatisierte Testen von fachlichen Extremfällen gewinnen alle Projektbeteiligten mehr Sicherheit im laufenden Betrieb.
Eine testbasierte Software-Entwicklung führt im Ergebnis zu einer wartbaren und im Betrieb sicheren Software.
Qualität und Nachhaltigkeit als Teil des Leistungsversprechens
Besteht zwischen dem Auftraggeber und dem Software-Team noch keine Vertragsbeziehung – und hat auch vorher noch keine bestanden –, so findet die Preisfindung „auf der grünen Wiese“ statt.
Als Software-Team setzen Sie mit Ihrem ersten Angebot, dass die initialen Mehraufwände für eine testbasierte Entwicklung enthält, einen neuen Kostenrahmen. Dennoch kann es sein, dass sie die Preiserwartung des Auftraggebers beziehungsweise der Auftraggeberin deutlich übertreffen. Das kann unterschiedlich begründet sein:
-
Aufgrund eines Vorgängerprojekts mit einem anderen Software-Team hat der Auftrag- geber eine niedrigere Preiserwartung.
-
Andere, konkurrierende Unternehmen legen ein Angebot vor, welches geringere initiale Kosten aufweist als ihres.
Um Irritationen an dieser Stelle beim Auftraggeber beziehungsweise bei der Auftraggeberin zu vermeiden, ist das Ergebnis der testbasierten Entwicklung im Angebot darzustellen.
Die Leistungsbeschreibung referenziert nicht nur auf die Implementierung der Anforderungen, sondern erläutert auch die Qualität der Software.
Das Maß an Qualität wird im Angebot mit den vom Auftraggeber beziehungsweise von der Auftraggeberin genannten Zielen verknüpft.
Ergänzen Sie in Ihrer Beschreibung des Lieferumfangs die Beschreibung der Softwarequalität Ihres Projekts. In den meisten Fällen wird ein Auftraggeber beziehungsweise eine Auftraggeberin in seiner beziehungsweise ihrer Ausschreibung nicht benennen, wie lange ein vergleichbares Vorgängersystem gearbeitet hat. Erfragen Sie diesen Wert – und stellen Sie auch diese Informationen in den Zusammenhang testbasierter Entwicklung.
Verdeutlichen Sie – mindestens in der mündlichen Verhandlung – die Auswirkungen für Erweiterungen im Regelbetrieb, die sich durch eine hohe interne Softwarequalität ergeben.
Initiale Mehraufwände, die sich für den Auftraggeber lohnen
Suchen Sie das persönliche Gespräch über das Angebot. Nehmen Sie den Einwand, testbasierte Entwicklung sei zu teuer, vorweg:
Die initialen Kosten werden höher sein. Aber das ist okay. Rechnet man die Betriebs- und Wartungskosten für die nächsten Jahre ein, ist das System preiswerter für Sie. Sie erhalten mehr Handlungsspielraum im laufenden Betrieb!
Das genaue Vorgehen wird im nachfolgenden Abschnitt erläutert. Erklären Sie den Ent- wicklungsprozess und das Ergebnis testbasierter Entwicklung. Eine Tabelle wie Tabelle 10.5 können Sie mit dem Auftraggeber während des Gesprächs am Flipchart entwickeln.
| Einfache Software-Entwicklung | Testbasierte Software-Entwicklung | |
| Vorgehen | Manuelle Tests |
Unit Tests (80%) Integrationstest zu Schnittstellen Manuelle Tests |
| Betrieb |
Oft Hotfixes nach Releases Schnittstellenfehler spät erkannt |
Bessere Absicherung des Gesamtsystems |
| Erweiterungen |
Technischer Relaunch nach vier Jahren zwingend Release-Zyklus: 3 Monate |
Ziel: stetig, stabil weiterentwickeln Ziel: schneller releasen (alle 1.5 Monate) |
Tabelle 5: Flipchart-Beschreibung einer einfachen sowie einer testbasierten Entwicklung
Die entsprechenden Argumente sind für den jeweiligen Fall anzupassen. Gleichzeitig kann diese Diskussion den Einstieg in die Erfassung möglicher Risiken und den Umgang damit bieten.
Diese Diskussion hilft beiden Parteien: Sie verstehen besser die Zielsetzungen und Befürchtungen Ihres Auftraggebers. Dieser merkt gleichzeitig, dass Sie sich für seine Belange interessieren und diese unterstützen möchten. Stellen Sie gleichzeitig dar, welche Entwicklungsmethoden die Zielsetzung des Auftraggebers beziehungsweise der Auftraggebe- rin unterstützen. Spürbar wird für den Auftraggeber beziehungsweise die Auftraggeberin Ihre Haltung und Ihr Qualitätsanspruch. Beides sind gute Voraussetzungen für eine fruchtbare, kooperative Zusammenarbeit.
Kommentar schreiben