Inhalt
Topic:.TestDrvDvlp.
Klassische Herangehensweise: Ordentliche Planung und Ausführung, danach sollte alles gehen.
Erfahrungen aus der Praxis: Systeme sind etwas komplexer, es werden bei der Planung Zusammenhänge übersehen. Gewünschte Tests beschreiben zugleich Anforderungen bzw. hängen damit eng zusammen. Das ist auch die Grundidee des bekannten V-Modells.
Folgend kommt lediglich eine Stichpunktsammlung, die zukünftig noch erweitert wird.
Topic:.TestDrvDvlp.holistic.
Requirements testing
Viele Einzeldetails, lange Liste wird getestet -> Tendenz zum engineering system
vs. ist das ein System -> human thinking
Topic:.TestDrvDvlp.unit.
Ein System (= Endprodukt) aollte aus Komponenten und Modulen aufgebaut sein, die für sich definierbar, beschreibbar und auch testbar sind. Das ist das Paradigma der Modularen Programmierung.
Unit-Test: Test des einzelnen Moduls (der Unit, Einheit), kann eine einzelne Operation in einer class sein, aber auch eine größere Einheit, die andere Units aufruft. Getestet wird aber immer eine Operation. Betrachtet wird die Reaktion der Unit nach außen, ggf. gehören dazu (nach außen geführte) innere Zustände dazu.
IntegrationsTest: Testfälle mit einem bestimmten Zusammenbau, Gesamtverhalten, ggf. aber auch mit Betrachtung innerer Zustände (die als Gesamtverhalten aufgefasst werden).
Systemtest: Würde ich eher als Produkttest bezeichnen, da das Wort System in zu vielen Zusammenhängen verwendet wird (es ist hier nicht das Betriebssystem gemeint).
Kundentest: So wie es der Kunde sehen will oder er selbst testet.
Topic:.TestDrvDvlp.mdl.
1) Algorithmen im Modell testen -> Test der Systemintegrität
2) Deployment in the hardware, the target -> Test the really behaviour.
Die zwei Stufen haben nicht direkt etwas mit Unit/Integration und Systemtest zu tun.
Topic:.TestDrvDvlp.holisticSw.
Eines darf nicht passieren: Es wird genau das und so programmiert, dass genau das Geforderte funktioniert, alles andere ist egal. Diese Herangehensweise, von mir auch als Phänomenologische Softwareentwicklung bezeichnet, legt das Augenmerk nur auf die nach außen zu erfüllenden Funktionen. Dass das System in sich stimmig sein muss, spielt da keine Rolle.
Notwendig ist immer eine ganzheitliche Betrachtung der Dinge. Wenn das einzelne Feature funktioniert, dann ist das System ggf. noch nicht gut. Wenn das System nicht gut ist, und es wird passend nachgebessert, dann geht das einzelne Feature viellicht nicht mehr, weil es (noch) nicht in das System passt sondern angeflanscht war.
Topic:.TestDrvDvlp.testdeterm.
Eine Anforderung (Requirement) ist gleichzeitig ein Test. Ein Requirement muss testbar sein. Die Formulierung des Tests schäft möglicherweise, oder oft, die genaue Vorstellung vom Requirement.
Topic:.TestDrvDvlp.docudeterm.
"Was sich nur schwerlich dokumentieren lässt sollte geändert werden." Offensichtlich ist da ein Softwaresystem geschaffen, was zur Überkomplexitiät neigt, viele Einzelheiten, in sich nicht stimmig ist.
Ändert man eine solche Software, aus der Intension der (nicht-) Dokumentierbarkeit heraus, dann wird man dabei eher nicht auf all die vielen Feautures achten, die das System bisher bestimmt haben. Denn genau diese verhindern, dass die Software ganzheitlich ist. Man wird sie nicht ignorieren, sondern die Features selbst zu einem System zusammenbringen. Im Gutfall passen alle Features in ein gemeinsames System, dann waren auch sie durchdacht. Für Features, die man erbringen muss (keine Diskussion darüber möglich) muss man dann wieder extra Aufwändungen spendieren, aber trotzdem muss der Rest ein ganzheitliches System ergeben. Hört sich etwas abstrakt an.
Bei der Dokumentation ist feststellbar, wo und wie sich ein Softwaresystem ergibt. Möglicherweise (oder unbedingt) sollte man im Nachhinein Klassendiagramme und Use-Cases zeichnen (UML) oder diese überarbeiten.
Das eine oder andere Feature wird dann mit der Ganzheitlich-Überarbeitung erst einmal nicht mehr funktionieren. Das ist gut so, keine Rücksichtsnahme auf systemstörende Realisierungen! Diese Features sind dann, wenn man das System hat, wieder basierend auf diesem System einzubauen. Möglicherweise handelt es sich dabei aber auch um Altlast-Features, die mal reingekommen sind, die faktisch aber keiner braucht. Das Festzustellen ist auch etwas Arbeitsaufwand.