Tests und Qualität in der Software: "fertig" soll "funktioniert" heißen
"Es ist fertig" und "es funktioniert" sind verschiedene Sätze: Die Demo läuft perfekt, und das echte Leben bricht sie — das leere Feld, der Doppelklick, die langsame Verbindung im Laden, zwei Leute, die gleichzeitig speichern. Du musst kein QA-Ingenieur sein, um verlässliche Software zu verlangen: Du musst wissen, welche Testebenen es gibt, welche dir gehört und wie du meldest, was du findest.
5. November 20255 Min. LesezeitIn diesem Artikel
"Es ist fertig" und "es funktioniert" sind verschiedene Sätze, und der Unterschied zeigt sich immer im schlechtesten Moment: Die Demo lief perfekt, aber am ersten echten Tag ließ jemand ein Feld leer, ein anderer klickte doppelt auf "Speichern", die Verbindung im Laden war langsam, und zwei Leute bearbeiteten gleichzeitig dieselbe Bestellung — und das System, das "fertig war", verteilte den ganzen Vormittag Fehler.
Softwarequalität ist nicht Perfektion — sie ist durch Tests verdientes Vertrauen: die begründete Gewissheit, dass das System das echte Leben aushält und nicht nur die Demo. Und obwohl die technischen Tests Sache des Entwicklers sind, gibt es eine Ebene, die niemand für dich übernehmen kann, und Fragen, die du stellen darfst. Dieser Guide gibt dir die komplette Karte in Klartext.
Warum "fertige" Software scheitert
Der Entwickler testet naturgemäß den Happy Path: den Ablauf, in dem alles richtig, in Reihenfolge, mit guter Verbindung und einzeln ausgefüllt wird. Das echte Leben ist der permanente Unhappy Path — unvollständige Daten, ungeduldige Nutzer, langsame Netze, gleichzeitige Nutzung —, und jede ungetestete Kombination ist ein Fehler, der auf seine Premiere im Produktivbetrieb wartet, vor einem Kunden. Tests existieren, um diese Fehler privat zu erleben, wenn die Korrektur billig ist, statt öffentlich, wenn sie Verkäufe und Ruf kostet.
Die Testebenen, in Klartext
| Ebene | Was sie prüft | Wer sie macht |
|---|---|---|
| Automatisierte Tests | Dass jedes Codestück seine Aufgabe erfüllt — und es nach jeder Änderung weiter tut | Der Entwickler; du bestätigst nur, dass es sie gibt |
| Funktionale Tests | Dass jede Geschichte der Anforderungen von Anfang bis Ende funktioniert | Das Entwicklungsteam, gegen dein Anforderungsdokument |
| Abnahmetest | Dass das System DEINEM echten Betrieb dient, mit deinen Leuten und Daten | Du und dein Team — das kann euch niemand abnehmen |
| Lasttests | Dass es das erwartete Volumen aushält (gleichzeitige Nutzer und Daten) | Der Entwickler — relevant bei erwarteten Spitzen oder hohem Volumen |
Deine Rolle: der Abnahmetest
Die Fälle, die alle vergessen
- Die schlechte Verbindung: Was passiert bei langsamem Internet oder Abbruch mitten im Speichern? — Eine klare Meldung und kein Datenverlust trennen das Professionelle vom Zerbrechlichen.
- Die Datenextreme: die Liste mit null Einträgen und die mit zehntausend; der Zwei-Buchstaben-Name und der mit achtzig — Extreme brechen, was der Durchschnitt verzeiht.
- Die Gleichzeitigkeit: zwei Leute bearbeiten dasselbe zur selben Zeit — wer gewinnt, wer erfährt es? In Teamsystemen passiert das am ersten Tag.
- Das echte Gerät: das alte Handy deines Lageristen und das billige Tablet der Küche — Software wird auf den Geräten getestet, auf denen sie leben wird, nicht nur auf dem Laptop des Entwicklers.
Bugs: so meldest du sie, damit sie schnell behoben werden
- Die genauen Schritte: was du getan hast, in Reihenfolge, von wo — "Bestellungen geöffnet, 'García' gesucht, zweites Ergebnis geöffnet, auf Bearbeiten getippt".
- Erwartet vs. passiert: "Ich erwartete die Kundenakte; es erschien ein weißer Bildschirm" — beide Hälften, immer.
- Der Beweis: Screenshot oder kurzes Video, plus Gerät und Uhrzeit — die Hälfte aller "nicht reproduzierbaren" Bugs löst eine gute Aufnahme.
- Die ehrliche Schwere: unterscheide "blockiert den Betrieb" von "stört" und von "Detail" — der Anbieter, bei dem alles dringend ankommt, priorisiert am Ende nichts.
Qualität nach dem Launch
Der Launch beendet das Thema nicht — er wechselt seine Phase. Verlange drei Dinge fürs Leben im Betrieb: Fehlerprotokollierung (das System zeichnet seine eigenen Ausfälle auf, sodass der Anbieter Ursachen behebt, statt an Symptomen zu raten), einen vereinbarten Supportkanal mit Reaktionszeiten (was dringend ist, wer antwortet, wie schnell) und eine einkalkulierte Stabilisierungsphase — die ersten echten Wochen bringen immer Anpassungen, und wer das vorher weiß, erlebt sie nicht als Scheitern; die vollständigen Projektzeiten stehen in wie lange App-Entwicklung dauert und der allgemeine Rahmen im Guide zur eigenen App.
Häufige Fragen
Wie viel des Budgets sollte in Tests fließen?
In ernsthaften Projekten verbrauchen Tests zwischen einem Viertel und einem Drittel des Gesamtaufwands — verteilt auf die automatisierten Tests des Entwicklers und die funktionalen Runden. Erwähnt ein Angebot Tests überhaupt nicht, ist es nicht billiger: Es ist derselbe Test, nur bezahlt von deinen Kunden im Produktivbetrieb. Die richtige Frage beim Angebot ist nicht "Was kosten die Tests?", sondern "Was umfasst euer Qualitätsprozess?" — und dem Schweigen misstrauen.
Sollte der Entwickler nicht einfach ohne Bugs liefern?
Software ganz ohne Bugs existiert nicht — was existiert und einforderbar ist, ist der Unterschied zwischen vertretbaren Bugs und schlampiger Arbeit: Die Hauptabläufe der Anforderungen müssen vollständig funktionieren (nicht verhandelbar), Grenzfälle dürfen dokumentierte offene Anpassungen haben, und Bugs in der Gewährleistung werden kostenlos behoben. Dieses Wort — Gewährleistung — verdient einen Platz in deinem Vertrag: eine Frist (60-90 Tage sind üblich), in der Mängel am Gelieferten gratis behoben werden.
Was sind automatisierte Tests, und muss ich sie bezahlen?
Es ist Code, der den Code prüft: Kontrollen, die in Sekunden von selbst laufen, bei jeder Änderung. Ihr Wert liegt nicht im Launch, sondern im ganzen Leben danach: Ohne sie kann jede künftige Änderung still brechen, was schon funktionierte — und niemand merkt es vor dem Kunden. Du bezahlst sie nicht als Extra — sie gehören zu gut gemachter Arbeit; was du tun solltest, ist fragen, ob es sie gibt, denn ihr Fehlen macht jede künftige Wartung zum Glücksspiel.
Wann ist es bereit für den Launch? Es taucht immer noch etwas auf.
Mit vorher definierten Kriterien, nicht mit Gefühlen am Ende: Alle Geschichten des Anforderungsdokuments funktionieren, der Realitätsdurchgang mit deinem Team lief tagelang ohne Blocker, die vergessenen Fälle dieses Guides wurden getestet, und die offenen Bugs gehören nur zur Kategorie "stört oder Detail" — mit Korrekturtermin. Auf die absolute Fehlerfreiheit zu warten heißt, nie zu starten; mit bekanntem Blocker zu starten heißt, das Vertrauen des Teams zu verbrennen. Die gesunde Linie liegt genau dazwischen.