Geschriebene SW testen
-
Nein, man kann weitaus mehr testen. Dann ergibt sich aber sehr schnell ein eigenständiges Projekt ´TEST´, das ein eigenes Budget erfordert, weil viel Manpower, Wissen und oft auch eigenständige Testsoftware erforderlich wird. Die Möglichkeiten manueller Tests sind begrenzt auf das, was vom Entwickler ohnehin gemacht werden sollte.
Ein solcher Testaufwand hängt allein von der möglichen Schadenshöhe im Fehlerfall und dessen Wahrscheinlichkeit ab. Die Autoren Sneed, Baumgartner, Seidl haben das in ihrem Buch ´Der Systemtest´ sehr gut beschrieben. Auch sie sagen, dass 100% Fehlerfreiheit nicht erzielbar ist.
Man muss Software-Hardware-Anwender-Dienste als eine komplexe menschgemachte und gesteuerte Maschine begreifen. Dann wird einsichtig: Die Maschine kann nicht jederzeit unter allen Bedingungen vollständig fehlerfrei laufen, weil Menschen eben Fehler machen.
Ich möchte mich hiermit aus dieser Diskussion verabschieden.
-
der trick ist, den code so zu strukturieren, dass er sich gut unittesten lässt. das schöne ist, dass der code dadurch auch viel einfacher, verständlicher und lesbarer wird. bedingt halt, dass du so früh wie möglich damit beginnst, auch die tests zu schreiben - im idealfall noch bevor du die implementierung schreibst. dann merkst du nämlich schon bei designen des codes, wenn du gefahr läufst, spagetti-code zu schreiben (klassen mit zu vielen abhängigkeiten, zu lange methoden mit zu vielen parametern, zu große klassen etc).
ich empfehle das buch Clean Code.