Betreff:Aw:Verknüpfung von Teststatus und Projektstatus im Reporting von IT-Projekten
Hallo Stefan,
aus meiner Sicht muss erst mal beides (Entwicklung und Test) im Status auftauchen, da in einem Softwareentwicklungsprojekt beides Aktivitäten sind, welche Kosten verursachen.
Für die weiter Antwort gehe ich von folgendem Setup aus:
Projekt mit Teilprojekt Entwicklung und Teilprojekt Test
Natürtlich kann man sich auf den Standpunkt stellen: Test ist eine QS Maßnahme auf die Anforderungsimplementierung. Reportet man also die Anforderungen entlang ihrem Lebenszyklus, kommt man (etwa) zu den Stufen:
Analyse, Design, Umsetzung, QS-Gate Systemtest passiert, QS-Gate Integrationstest passiert, Produktion
Dann würde das Projekt einen Status (unter Leitung des TP Entwicklung) abgeben. Die Testaktivitäten wären dann nur eine Zulieferung an das TP Entwicklung.
In der Realität ist es aber meist so, dass das TP Entwicklung hauptsächlich bis einschließlich Umsetzung reportet und das TP Test reportet dann einen extra Teststatus. Das ist unbefriedigend, weil beide TPs von Anfang bis Ende beschäftigt sind:
Test beginnt schon direkt nach Projektauftrag! In einem guten Projekt machen die Testanalysten schon vor dem Designstart eine QS auf die Anforderungen (fachliche Spezifikation) auf Testbarkeit. (Annahme: Wenn Testbarkeit gegeben, dann auch die Umsetzbarkeit).
Startet die Entwicklungstruppe das Design der Anforderungsumsetzung, dann startet die Testtruppe mit dem Testkonzept, Testobjektbestimmung und Testfallerstellung für die Teststufen. Die Ressourcenplanung macht man in der Regel so, dass beide sich wieder zum ersten Testbeginn treffen (Meilenstein "Entwicklung fertig", MS "Systemtest Start").
Bei iterativen Ansätzen muss man natürlich etwas feiner planen.
Man sieht aber schnell, dass Test schon vor Testbeginn eine ganze Reihe von Aktivitäten hat, welche in den üblichen Kategorien
- Scope (Status, Eskalationsbedarf, Entscheidungsbedarf)
- Zeit (Status, Eskalationsbedarf, Entscheidungsbedarf)
- Budget (Status, Eskalationsbedarf, Entscheidungsbedarf)
- ggf. Ressourcen (Status, Eskalationsbedarf, Entscheidungsbedarf)
- Risiken, Maßnahmen (Status, Eskalationsbedarf, Entscheidungsbedarf)
in einem Statusbericht zu berichten.
Zusätzlich wird man im Testverlauf ein spezielles Reporting sehen wollen, welches die Testergebnisse anzeigt:
- Anzahl Testfälle, Anteil erfolgreich, nicht erfolgreich, noch nicht gestartet
- Anzahl offene Abweichungen leicht, mittel, schwer
- Kenngrößen wie Fixdauer, etc.
Zweck ist die Abschätzung, ob die Abnahme durch den Kunden zeitgerecht erfolgen wird. (In der Regel: So lange schwere Abweichungen da sind, wird nicht abgenommen)
Das Thema Qualitätssicherung (für die nicht-Test-Themen) sollte auch berücksichtigt werden. Ob es dazu einen eigene Statusbericht gibt oder ob einfach der Abschluss der Meilensteine der anderen Teilprojekte verweigert wird ist projektabhängig festzulegen. Wenn die Projektteilnehmer schon bekannt und bewährt sind, braucht man in der Regel weniger Reporting.
Soweit von meiner Seite.
Viele Grüße
Alexander |
Forum 