“Test case driven software development” – das ist ein Trend der durchaus seine Berechtigung hat. Es geht darum, Testfälle schon in der Anforderungsspezifikation zu entwickeln und die Entwicklung der Lösung an diesen Testfällen auszurichten. Auch Designdokumente können an solchen früh entwickelten Testfällen geprüft werden – und der Entwickler weiß jederzeit, was bei der Implementierung in bestimmten Fällen (nicht in allen) herauskommen soll.
Allerdings scheinen manche große Software-Dienstleister den Sinn der Sache anders zu interpretieren. Sie fordern von ihren Kunden riesige Mengen von Testdaten, möglichst produktionsnah, und erwecken den Eindruck, dass es ohne solche Daten gar nicht möglich sei, die Anforderungen, insbesondere die nicht-funktionalen, der Kunden zu erfüllen.
Braucht man, um z.B. performante Anwendungen zu entwickeln, tatsächlich Testdaten aus der Produktion? Werden nicht vielmehr die Grundlagen für die Erfüllung solcher Anforderungen bereits in der Design-Phase gelegt, lange vor den ersten Performance-Tests, und wird performantes Verhalten nicht mehr durch erfahrene Entwickler und Datebank-Experten gesichert.
Man gewinnt den Eindruck, manche Anbieter kümmern sich während des Designs und der Realisierung nur um Funktionalität und “testen” die Performance dann während der Abnahme und Produktivsetzung in die Lösung hinein – Frust beim Anwender ist dann genauso vorprogrammiert (im wahrsten Sinne des Wortes) wie suboptimale Lösungen – denn was im Design falsch gemacht wurde, kann auf diese Weise nur geflickt, aber niemals wieder ausgebügelt werden.