QualitätsSicherungsDoku

Die Qualitätssicherungsdokumentation wird von MarcelBruch und MartinMonperrus? bewertet.

Folgende Artefakte sollten als Dokumentation der QS vorhanden sein:

QS-Dokumentation

• Form: Eigenständiges Dokument
• Umfang:
  • Teil 1 (QS allgemein): 3-10 Seiten
    • es soll nur reingeschrieben werden, was auch tatsächlich gemacht wird => kein “Over-Commitment”!
    • mehr unter Inhalt (s.u.)
  • Teil 2 (Testfälle): in angemessener Ausführlichkeit
    • mehr unter Inhalt (s.u.)

Bemerkung: Zwischen der ersten und der finalen Version soll der 1. Teil (QS allgemein) regelmäßig aktualisiert werden, sofern dieser in der ersten Version noch nicht ausführlich genug war (Überprüfung durch und nach Ermessen der Gruppenbetreuer) bzw. sich Änderungen ergeben haben.

• Inhalt Teil 1 (QS allgemein):
  • Beschreibung der QS-Ziele
  • Beschreibung eines Plans, wie die genannten Ziele erreicht werden können
    • Welche Artefakte unterliegen der QS?
      • Dokumente, Code, Tests, Sonstiges
    • Welche QS-Maßnahmen werden für welches Artefakt durchgeführt?
      • Vorgehen/Ablauf der QS-Maßnahme
      • Wer, was, wann, wie, wie oft, wann fertig, wie protokolliert
      • z.B. Reviews, Code Conventions, Nutzung besonderer Werkzeuge, Tests, Metriken etc.
• Inhalt Teil 2 (Testfälle):
  • Tests
    • Beschreibung der Testumgebung (Hardware, Software, Betriebssystem etc.)
    • welche Testarten (z.B. Systemtests, Integrationstests, Unittests, Abnahmetests, aber auch Lasttests, Stresstests etc.)
    • pro Testart Beschreibung des Vorgehens (wer, was, wann, wie, wie oft, Testendekriterium, Testmethode (Herleitung der Testfälle), Testzyklus, Fehlerdatenbank)
    • für Systemtest: Dokumentation der Testfälle
      • Name
      • Setup, Eingabedaten (konkrete Testfälle, keine abstrakten), Vorgehen, benutzte Softwareversionen (Stubs, Treiber, Object-under-Test)
      • Soll-Ergebnis
      • Ist-Ergebnis (inkl. Ausführungsdatum)
      • was deckt der Testfall ab (z.B. Use Case, nichtfunktionale Anforderung, Use-Case-Scenarien, etc., zwecks Traceability)

Abnahmetest

• Form:
  • schriftlich
  • Als eigenständiges Dokument oder als zusätzliches Kapitel im oder Nachtrag zum Pflichtenheft oder auch als Bestandteil der QS-Dokumentation
  • Abnahmeprotokoll (muss vom Auftraggeber abgesegnet werden )
• Zeitplan:
  • Unterschriebenes Abnahmeprotokoll: nach Abnahme spätestens 1.10.
• Inhalt Abnahmetestdokument:
  • Inhalt muss mit Auftraggeber und Gruppenbetreuer abgestimmt werden
  • Genaue Definition der Abnahmetests
    • Testort (z.B. beim Auftraggeber)
    • Abnahmezeitpunkt (Auch Zeitpunkt des Abnahmeprotokolls)
    • Testumgebung
      • Mit Definition entsprechender Deadlines falls vom Auftraggeber eine spezielle Testumgebung/spezielle Testdaten etc. benötigt werden
    • Beschreibung der Testfälle (ggf. Verweis auf bereits existierende Testfälle aus der QS-Dokumentation, sofern dieses Dokument auch dem Auftraggeber bekannt ist)
• Inhalt Abnahmeprotokoll:
  • In Abnahmeprotokoll wird die Abhname protokolliert
    • Welche Teile des Projekts erfolgreich abgenommen wurden (Akzeptanz durch den Kunden)
    • Welche Teile des Projekts evtl. mangelhaft sind (nicht dem Pflichtenhelft entsprechen)
    • Unterschrift des Kunden und der SE-Gruppe

Pflichtenheft

• Form: Erweiterung des Pflichtenhefts
• Zeitplan
  • Abgabe als Teil des Pflichtenhefts
• Inhalt:
  • Qualitätsmanager soll (als Rolle) bestimmt werden. Seine Verantwortung liegt in der Überwachung der QS-Bemühungen und der (Überwachung der) Erstellung der QS-Dokumente.
  • Priorisierung der Qualitätsmerkmale (z.B. nach ISO 9126)
  • Definition des Abnahmetests (s.o., kann auch getrenntes Dokument sein)

Regressionstestsuite

• Zeitplan:
  • 1. Version mit 1. Auslieferung
  • Aktualisierungen bei jeder Auslieferung
  • Überprüfung durch und nach Ermessen der Gruppenbetreuer
• Inhalt:
  • Testsuite mit Regressionstests
  • Manuelle und/oder automatisierte Tests
  • Anzahl der Tests:
    • Entsprechend den festgelegten Qualitätsanforderungen/Testendekriterium und geschätzem Verhältnis von Risiko/Nutzen
    • Ausreichend viele, um der Gruppe Vertrauen in den eigenen Code zu geben (funktionale Überdeckung)
  • Sollen in regelmäßigen Abständen ausgeführt werden (je nach Automatisierungsgrad täglich/wöchentlich/vor jedem Release)
  • Ergebnishistorie
    • Wann wurden welche Tests ausgeführt, Ergebnis
    • Wann gehörten welche Tests zur Testsuite/wann wurden welche Tests hinzugefügt/entfernt
    • Form: beliebig formal oder informal, ggf. nach Absprache mit den Gruppenbetreuern

Anmerkungen

Sofern bereits erstellte Dokumente Teile dieser Anforderung abdecken, können diese Dokumente abgegeben werden. Beispiele hierfür sind Dokumente, die vom Auftraggeber gefordert werden, oder JavaDoc? für JUnit-Tests. Beschreibungen, die auf eine Gruppe von Tests zutreffen müssen nur einmal gemacht werden. Beispielsweise, wenn ein Setup für mehrere Tests gilt, muss es nicht bei jedem einzelnen Testfall wiederholt werden.