Tests / Qualitätssicherung - aber wie?

[Philipp Hasenfratz]

Halihallo Andreas

Ich bin jetzt schon so einige Monate an einem PHP-Projekt, und werde das bald fertigstellen. Jetzt mache ich mir Gedanken über eine Quzalitätssicherung, bzw. über ein systematisches Testen der Software, um möglichst viele Fehler - die sicher vorhanden sind - aufzuspüren.

Für das nächste Mal würde ich empfehlen, die hochgelobten Testcases bereits während dem
Umsetzen festzulegen; erspart einiges an Zeit.

Nur wie stelle ich das an? Habe da Sachen gehört dass das Testen eines Programms oft 40% und mehr der kompletten Entwicklungszeit in Anspruch nimmt - nur was macht man in der ganzen Zeit?

Plaudern, Kaffe trinken, Rauchen, wie in den verbleibenden 60% :-)

Soviel zu der Anwendung. Ich habe gelesen, dass es bei großen Projekten richtige Programme geschrieben werden, die die zu testende Software dann halt auf Herz und Nieren überprüfen -

richtige Programme. Mal sehen, Microsoft XP, Office, Oracle? - Hm. Meistens kann man froh
sein, wenn man überhaupt zum testen kommt, die Software wird meist schon vor Abschluss
der Testphase auf den Markt geschmissen. Naja, egal...

Wie macht Ihr das? Oder muss man sowas direkt in den Code integrierern?

Kann man ja und ich halte das auch für sinnvoll. Es gibt einfach ausgedrückt zwei
Arten der Programmierung:

a) Einfach mal alles umsetzen, sodass es halbwegs smothly funktioniert und dann Fehler
   mühsam suchen, oder...
b) Von anfang an ein durchdachtes und sehr strickte arbeitendes Testsystem in den Source
   packen, sodass man gar keine Fehler machen darf (z.B. Input-Parameter check und andere
   Low-Level-Fehler).

letzteres dient IMHO dazu, sich selber einen gewissen Programmierstil aufzuzwingen, der
den Anforderungen eines "auf den ersten Blick" fehlerfreien gerecht wird und einem von
lästigem Fehlersuchen abhält.

Das Auffinden von Fehlern ist jedoch in den meisten Fällen dadurch noch lange nicht
abgedeckt und es geht hier um die Feststellung genau _dieser_ Fehler.

Die letztgenannte "Fehlerklasse" liesse sich zum grossen Teil über die bereits genannten
Mechanismen auffinden, aber am Ende des Endes braucht es einen _Menschen_ der die
Software testet. Die intelligentesten Testmodule und -Extensionen sind auch nur so gut,
wie das Programm selber, wenn sie von derselben Person geschrieben sind. Natürlich ist
das definieren von testconditions ein ganz anderes Problem und somit lassen sich wirklich
Fehler finden, aber sie decken nicht alle Fälle ab, besonders die _Interaktion_ Mensch zu
Computer lässt sich sehr schlecht in testconditions abbilden. Deshalb ist für mich das
Testen am "Lebenden Objekt" genauso wichtig, wie das testen mit toter Materie (Software
Code).

Oftmals geht es einfach um:

Input ergibt Output, vergleiche Output mit Erwartungswert, Softwarefehler bei
Nichtübereinstimmung. Aber leider ist Software oft komplex, logisch nicht gut getrennt
und nicht atomar (mit atomar meine ich, dass zu einem Input eben nur ein Output möglich
ist, der also von keinen externen Einflüssen wie z.B. andere Module abhängt), das macht
das Auffinden von Fehlern zu einem grossen Unterfangen.

Die werden alle mit möglichst vielen Angaben geloggt. Dann kann ich den Fehler evtl. reproduzieren.

und bereits auf Herz und Nieren getestete Codebestandteile können vom logging ausge-
nommen werden um die Ressourcen zu schonen. Aber das ist auch mit Vorsicht zu geniessen,
denn meistens fehlt einem bei einem Fehler dann _genau diese Information_.

Was könnte man noch machen? Wie kann ich qualitativ hochwertigen Code sicherstellen? Wie kann ich Code testen?

Nun, vielleicht noch dies:
Du hast selbst gesagt, dass die Entwicklung dem Ende naht, ich nehme an, dass das System
in den etwas eingeschränkten Umgebung (sprich, keine relle Kundendaten, nur eigene
Testdaten) bereits akzeptabel läuft, denn sonst wirst du es bereits korrigiert haben.
Den Grossteil des Testings hast du ja bereits hinter dir und unbewusst vollzogen. Du
musst dir jetzt IMHO den Kopf darüber zerbrechen, um was für eine Art Fehler es sich noch
handelt bzw. wie du diese am besten Auffinden kannst. Denn hier geht es um keine
trivialen Fehler in der Software und die nicht trivialen Fehler findet man nicht leicht.

Manchmal hilft es übrigens schon den Quelltext auf Papier zu sehen, denn ein anderes
Medium gibt andere Möglichkeiten. Mir zumindest geht das Auffinden von Fehlern auf
Papier wesentlich einfacher.

Und noch ein Erfahrungswert: Testing ist nötig, aber der ganze Rummel um maschinelles
Testing halte ich auch für etwas übertrieben. Oftmals hilft es, wenn man einfach mal mit
seiner Software spielt und die ganzen Prozesse mit halbwegs realem Hintergrund
durchspielt, man findet oftmals schneller Fehler, dafür ist dieses Testing sehr
oberflächlich. Das maschinelle, automatische Testing birgt einige Gefahren, die man damit
umgehen kann und umgekehrt. Ich vote für ein hybrides Testing (nicht auf eine Technik
beschränken).

Und noch was, was jedem einleuchten dürfte: Gute Dokumentation, gute Schnittstellen(
-beschreibungen) sind das A und O und unterbinden bereits 20% Fehler, dazu ein strictes
Programmieren, wo low-level-Fehlerbehandlung schon integriert ist und jedesmal abbricht,
wenn "schlampig" Programmiert wurde (oder z.B. die benötigte Datei nicht existiert
o.ä.), weitere x %... Dann eine gute, klar strukturierte und gekapselte (nicht zwei
Problemkreise in einem Modul behandeln) Modellierung...

Mach dich darauf gefasst, dass mit der Zeit noch mehr Fehler auftauchen, denn eine
Software ist eines nie: Perfekt.

Auch wenn ich nicht viel neues gesagt habe, hoffe ich doch, dass zumindest die Gedanken,
die ich zum Thema habe/hatte klar dargestellt sind und hoffentlich helfen.

Viele Grüsse

Philipp