Heute geht es um das Thema „Testen“. Es gibt Projekte bei denen Testen bedeutet, dass der Entwickler in der Anwendung „unkoordiniert“ herumklickt. Aber wenn man wirklich sauber Testen möchte, muss man auf verschiedenen Ebenen aktiv werden.
Die Softwareentwicklung besteht neben der Programmierung noch aus weiteren Ebenen. Diese sind notwendig, um den verschiedenen Stakeholdern Elemente an die Hand zu geben, über die diese Sprechen können. Entscheidungen werden auf abstrakteren Ebenen getroffen und von verschiedenen Rollen in der Entwicklung verfeinert, bis schlußendlich die Programmierung durchgeführt wird.
Beispielhaft kann man das V-Modell heran nehmen, wenn man einige Abstraktionsebenen betrachten will.
- Anforderungsdefinition
- funktionaler Systementwurf
- technischer Systementwurf
- Komponentenspezifikation
Die entsprechenden Testmöglichkeiten entsprechen dann:
- 1. <- Abnahmetest
- 2. <- Systemtest
- 3. <- Integrationstest
- 4. <- Komponententest
Jetzt stellt sich die Frage was die ganzen Tests bringen. Schließlich kosten diese erst einmal Geld und reduzieren zum Teil die Performance bei der Entwicklung. Aber auf der anderen Seite machen Menschen Fehler und diese können durch Test früher entdeckt werden. Die Mehrkosten können durch frühergefundenen Fehler problemlos kompensiert werden – genauer spart man sogar noch Kosten ein. Wie so oft zahlt sich eine frühzeitige Planung auch bei der Softwareentwicklung aus. Hierzu gibt es ein relativ bekanntes Diagramm, dass aus einem Vortrag von Stefan Priebsch entnommen wurde.
Ein wichtiger Punkt ist weiter, dass die einzelnen Testebenen nicht durch einen Entwickler ausgeführt werden. Verständlicherweise werden die eigenen Kreationen weitaus weniger kritisch betrachtet wie dies eigentlich sein sollte und daher muss ein zweiter Entwickler oder besser noch eine unabhängige Partei den Test durchführen. Als Faustregel kann man festhalten, das je weiter man sich vom eigentlichen Quellcode entfernt, desto weiter kann man den Test zu einer 3. Partei geben. Unittests werden normalerweise durch den Entwickler verfasst und durchgeführt – oder spätestens durch ein CI System. Dies gilt auch für die Integrationstests, die aber schon durch einen 2. Entwickler geschrieben werden können. Spätestens beim System- oder Abnahmetest sollte aber ein dedizierter Tester tätig werden. Am besten ist beim Abnahmetest eine eigene Abteilung oder eine externe Testfirma. Diese Spezialisten können auf einen breiten Wissensfundus aus der Testerfahrung zurückgreifen. Ein einzelner Tester ist hier relativ eingeschränkt und ein Entwickler schon fast ungeeignet.