Qualitäts- und Testmanagement

Software ist in allen Bereichen der modernen Betriebsführung im Einsatz (zum Beispiel Buchhaltung, Betriebsabläufe, etc.). In vielen Fällen übernimmt sie zentrale Aufgaben oder liefert Ergebnisse von juristischer Relevanz. Dem entsprechend hoch sind die Anforderungen an die Qualität (Richtigkeit, Funktion, Sicherheit, Performance, Last, etc.). Mängel oder gar Ausfälle verursachen hohe Kosten und langfristig einen erheblichen Imageschaden. Deshalb liegt es im Interesse Ihres Unternehmens die Qualität der Software vor der Einführung zu überprüfen.

Dies nicht zu tun ist fahrlässig!

Wir begleiten die Software-Einführung in Ihrem Unternehmen; sei es eine Neuentwicklung oder eine anzupassende Standardsoftware. Unser Leistungsspektrum beginnt bei der Analyse und endet bei der „in Produktivnahme“. In diesem Umfeld übernehmen wir die Beratung und Ausführung:


Aufbau und Einführung der Qualitätssicherung in der Softwareentwicklung

Die Qualitätssicherung (QS) umfasst „alle geplanten und systematischen Tätigkeiten, die innerhalb des Qualitätsmanagementsystems verwirklicht sind, um angemessenes Vertrauen zu schaffen, dass eine Einheit die Qualitätsforderungen erfüllen wird“ (DIN EN ISO 8402). Einfacher ausgedrückt, soll sich jemand darum kümmern, dass ein Produkt auch erfüllt was man von ihm erwartet.
Mit dem Einsetzen einer Qualitätssicherung sind dann oft hohe Erwartungen verknüpft, die je nach Projektbedingungen nur eingeschränkt zu erfüllen sind. Denn

  • es gibt keine vordefinierte, auf alles anwendbare Qualitätssicherung, die man in der Hoffnung einsetzen kann, dass damit alle Probleme gelöst sein werden.
  • Qualitätssicherung braucht Unterstützung, kostet Zeit, Geld und aus Sicht der Projektleitung Nerven. Denn Sie ist nicht nur dazu da um zu testen und zu prüfen, sondern auch um Probleme aufzudecken und diese anzumahnen.
  • Qualitätssicherung kann nicht alleine von den Mitarbeitern der Qualitätssicherung geleistet werden. Die Qualitätssicherung ist auf die Mithilfe und das Spezialwissen der Fach- und Entwicklungsseite angewiesen.
  • Qualität muss erst definiert (messbar beschrieben) werden, bevor sie gesichert werden kann
  • Qualitätssicherung braucht qualifiziertes und erfahrenes Personal
  • es ist unmöglich und unwirtschaftlich alle Qualitätsabweichungen (Fehler) eines Produkts zu finden. Primäres Ziel der Qualitätssicherung ist es, Fehler aufzufinden bzw. zu vermeiden, welche die Nutzung des Produkts einschränken oder unmöglich machen.
  • wirtschaftliche Gesichtspunkte und knappe Zeitvorgaben schränken die Möglichkeiten der Qualitätssicherung stark ein

Daraus könnte die Schlussfolgerung gezogen werden, dass Qualitätssicherung aufwendig ist, nicht viel nutzt und zudem noch viel kostet. Dies ist der Fall, wenn sie planlos und nicht zielgerichtet durchgeführt wird. Besonders kosten- u. zeitsparend –bezogen auf das Gesamtprojekt- ist die Qualitätssicherung, wenn sie frühzeitig mit quantitativ und qualitativ angemessenem Personal einsetzten kann. Fehler können so frühzeitig gefunden werden. Das Verhältnis der Fehlerbehebungskosten zum Entdeckungszeitpunkt mit fortschreitendem Projektverlauf steigt nicht linear, sondern exponentiell an. Ausreichende Vorbereitungszeit dient ebenfalls der Kosten- und Zeitersparnis, weil dadurch die Qualitätssicherungsmaßnahmen zielgerichtet geplant und dokumentiert werden können. Idealerweise beginnt die Qualitätssicherung noch vor (konstruktive QS) oder mit Projektbeginn (konstruktive und analytische QS).
Um einen sinnvollen Kosten-Nutzen-Effekt zu erzielen muss deshalb für jedes Software-Entwicklungs-Projekt ein speziell auf die Eigenheiten des Produkts zugeschnittener Qualitätssicherungsplan (QS-Plan) erstellt werden.


Erstellung des Qualitätssicherungsplans

Der Qualitätssicherungsplan (QS-Plan) beschreibt den Umfang der Qualitätssicherungsmaßnahmen eines Projekts. Er beinhaltet

  • für die Qualitätssicherung, die Ausgangsdaten, einen Verweis auf Produktbeschreibung, Qualitätsmerkmale, ie Rahmendaten des Projektplans und die daraus resultierende Organisation der QS (Ziele, Gefahren und Risiken), die Abgrenzung dessen was, wann, wie qualitätsgesichert werden kann/muss so wie die notwendigen Hilfsmittel
  • für das Testmanagement, die Testkonzepte, die Verweise zur Testfallermittlung, Testdatenerstellung, Testdurchführung und Testauswertung, die Testablaufplanung und das Testende Kriterium
  • für das Fehlermanagement, das Statuskonzept und den Ablaufplan der Fehlerverfolgung
  • für das Änderungsmanagement, das Statuskonzept und den Ablaufplan der Änderungsanforderungen
  • für das Berichtswesen, Definition der Dokumentenvorlagen und der Berichte

Der QS-Plan ist ein lebendes Dokument. Er muss entsprechend den tatsächlichen Projektgegebenheiten aktualisiert werden und gilt für den gesamten Projektzeitraum.


Testplanung

Das Testmanagement plant Tests und führt sie in der Regel auch selbst durch. Zu den Planungsleistungen zählen:

    • Testkonzepte:
      Testkonzepte sollen die geplanten Tests grob aber umfassend beschreiben. Sie sollen sich immer nur auf eine testbare Einheit beziehen (z.B. Import Programm, Anwender Oberfläche, Datenbank, etc.) Folgende Informationen sollten im Konzept mindestens enthalten sein. (Konzeptbezeichnung – Eindeutige Konzeptbezeichnung)

      • Testaufgabe – Welches Ziel verfolgt das Konzept?
      • Abhängigkeit – Welche Tests aus anderen Konzept müssen erfolgreich durchgeführt worden sein, bevor Tests des aktuellen Konzepts sinnvoll getestet werden können
      • Qualitätsmerkmale -Welche Qualitätsmerkmale werden mit dem Konzept geprüft?
      • Erforderliche Tester – Welche Tester sind für die Testdurchführung notwendig?
      • Testvorbereitung – Welche Vorbereitungen müssen getroffen werden?
      • Testdurchführung – Wie wird der Test durchgeführt?
      • Testfallermittlung – Wie müssen die Testfälle ermittelt werden, um Testaufgabe und Qualitätsmerkmal zu erfüllen?
    • Testablauf:
      Damit die geplanten Tests im Rahmen des Gesamtprojektplans bleiben, muss ein Ablaufplan für die Tests erstellt werden. Die Einhaltung der geplanten Abläufe ist allerdings stark abhängig von der ausgelieferten Qualität des Produkts. Bei mangelhafter Qualität wird der Testablaufplan, wie auch der Gesamtprojektplan nie einzuhalten sein.
    • Dokumentenprüfung:
      Die Dokumentenprüfung ist ein Test der Planung. Dadurch sollen frühzeitig fehlende Informationen, Fehler, Widersprüche und Ungereimtheiten in den Anforderungen und Konzepten aufgedeckt und Missverständnisse ausgeräumt werden. Besonders effektiv ist die Dokumentenprüfung im Rahmen einer frühzeitigen und strukturierten Testfallermittlung, da hier auch Aspekte betrachtet werden, die beim reinen lesen nicht offensichtlich sind.
    • Testfallermittlung:
      Die Testfallermittlung ist Vorraussetzung für jeden Test. Um Testfälle ermitteln zu können benötigt man eine Beschreibung der Anforderungen und Funktionalitäten des Produkts um diese überhaupt überprüfen zu können. Testfälle sollen bestätigen oder widerlegen, dass das Produkt sich der Beschreibung entsprechend verhält. Dies erreicht man über die Ermittlung von positiv Testfällen (Das Produkt wird ordnungsgemäß und ohne Falscheingaben bedient) und negativ Testfällen (Fehler werden durch Falscheingabe oder Fehlbedienung provoziert). Insbesondere für die Ermittlung der negativ Testfälle ist die Sichtweise des DAU (dümmster anzunehmender User) einzunehmen, auch wenn dies einem technisch oder fachliche versierten Testfallermittler schwer fallen wird. Grundsätzlich sollte so wenig wie möglich als selbstverständlich oder selbsterklärend angesehen werden. Es sei denn man kann von einem guten Kenntnisstand der späteren Anwender ausgehen.Testfälle können strukturiert und unstrukturiert ermittelt werden. Das unstrukturierte Testen ist die übliche Vorgehensweise mit der ein durchschnittlicher Mensch ein Produkt jeglicher Art testen würde. Dabei nutzt er seine Erfahrung und spielt eine für den Menschenverstand fassbare, aber in der Abdeckung der Möglichkeiten oft unvollständige Anzahl von Kombinationen durch. Er probiert i. d. R. aus, dass etwas bei sachgerechter Benutzung funktioniert wie erwartet und in selteneren Fällen, ob etwas bei Fehlbedienung nicht funktioniert.
      Bei der strukturierten Testfallermittlung werden Methoden angewandt, mit denen theoretisch die komplette Kombination an Testfällen ermittelt werden kann.
  • Testdatenerstellung:
    Die Testdatenerstellung folgt der Testfallermittlung. In den seltensten Fällen besteht ein Testfall nur aus einer oder mehreren Aktionen. Meistens müssen vor oder durch die Aktion (z.B. Dateneingabe) Werte eingegeben werden. Diese werden, wenn keine Zufallswerte verwendet werden sollen, im Rahmen der Testfallermittlung erstellt. Für jeden ermittelten Testfall ist mindestens ein Testdatensatz zu erstellen. Häufig müssen für einen Testfall mehrere Testdatensätze verschiedener Ausprägung erstellt werden.
    Es ist zwingend notwendig, dass jeder Testdatensatz eindeutig und jederzeit einem Testfall zugeordnet werden kann. So können die Testdaten bei Änderungen der Testfälle (z.B. durch eine Konzept-Änderung oder Konzept-Erweiterung des Produkts) leicht geändert werden.

Der QS-Plan ist ein lebendes Dokument. Er muss entsprechend den tatsächlichen Projektgegebenheiten aktualisiert werden und gilt für den gesamten Projektzeitraum. Zu den Ausführungsleistungen zählen:

    • Testautomatisierung:
      Die Entscheidung für oder gegen die Testautomatisierung muss bei der Testplanung festgelegt werden. Es sollte genau abgewägt werden, wann eine Testautomatisierung sinnvoll ist. Die Vorteile und Nachteile von manuellen Test und automatisierten Test sind in der nachfolgenden Tabelle gegenübergestellt.
      Bei weniger als fünf Regressionstests ist die Automatisierung meist die aufwändigere Variante, wegen der nicht unerheblichen Vorarbeiten. Die Testautomatisierung kann verschieden erfolgen. Es können Batchläufe sein. Oder kleine Programme zum Vergleich von Ausgabedateien. Es kann ein Oberflächen Testtool verwendet werden, mit dem per Record-Playback Testfälle aufgenommen werden, die –soweit es keine Änderungen der Eingabemasken gab- beliebig oft wiederholt werden können. Da Änderungen an den Eingabemasken im Entwicklungszeitraum eher die Regel sind, ist es besser ein Testsystem zu Programmieren (Framework), das möglichst einfach an Änderungen angepasst werden kann.
      Vorteile manuelle Tests:

      • Aufzeigen von Problemen bei der Benutzerfreundlichkeit
      • Prüfung der Ausfallsicherheit bzgl. sehr unwahrscheinlicher Benutzeraktionen
      • frühzeitige Erkennung von Akzeptanzproblemen

      Nachteile manuelle Tests:

      • Personalintensiv

      Vorteile automatisierte Tests:

      • Erhöhung der Testqualität durch einen besseren Abdeckungsgrad des Tests
      • Verkürzung der Zeit des Testdurchlaufs
      • automatische Dokumentation von Testläufen
      • effizientes Testen bei Massen- und Stresstests
      • entscheidende Reduzierung des Testaufwands bei Folge Versionen durch Wiederholbarkeit
      • Nutzung der Maschinenlaufzeiten als Testzeit (anstelle der Arbeitszeit der Mitarbeiter)
      • Durch strikte Modularisierung in Testobjekte können bereits vorhandene Testdaten in späteren Testphasen wieder- bzw. weiterverwendet werden.

      Nachteile automatisierte Tests:

      • Aufwändig in der Vorbereitung
      • Zur Erstellung des Testprogramms sind Programmierkenntnisse notwendig
      • Ggf. Erwerb eines Test-Tools notwendig

 

    • Testausführung:
      Bei der Testausführung werden alle oder Teile der zuvor ermittelten Testfälle in Abhängigkeit der Testablaufplanung unter Nutzug der erstellten Testdaten ausgeführt.
      Für die Testausführung ist eine Ausführungsanweisung notwendig, die es einer mit dem Thema nicht vertrauten Person ermöglichen Tests Auszuführen. Ausführungsanweisungen sind Checklisten, Dokumente, oder dokumentierte Testprogramme, die alle notwendigen Durchführungsschritte enthalten.
      Die Testfälle können manuell oder automatisiert ausgeführt werden. Die Ergebnisse sind zu dokumentieren.

 

    • Testdokumentation:
      Eine Testausführung ohne Dokumentation ist von geringem Wert und erschwert die Fehleranalyse. In der Regel sollte das Ergebnis jedes Testschrittes dokumentiert werden. Dies ist bei der automatisierten Testausführung unproblematisch, soweit es programmiert wurde. Bei der manuellen Testausführung scheitert die durchgängige Testdokumentation oft an der Disziplin des Testers oder dem Zeitdruck, dem er unterliegt. Die Testdokumentation ist die qualifizierte Grundlage des Test(abschluss)berichts.

 

    • Testbegleitung:
      Die Testbegleitung ist die beratende Hilfestellung und Unterstützung von Testlaien z.B. Mitarbeitern der Fachabteilung oder auch die Betreuung und das Management der Tester in einem Testlabor.

 

  • Abschlussbericht:
    Der Abschlussbericht enthält eine qualifizierte Aussage über die Qualität des Produkts. Grundlage des Abschlussberichts sind die Testdokumentationen der ausgeführten Tests und die noch offenen Fehler.

Testfallermittlung mit der Fachabteilung

Manuelle Testdurchführung

Testautomatisierung (Oberflächen, Funktions- und Lasttests)

Fehlermanagement

Das Fehlermanagement definiert einen Prozess zur Erfassung, Verfolgung und Behebung von Fehlern. Ein Fehler ist eine Abweichung von der Planung. Fehler werden in Fehlerberichten erfasst. Diese werden in einer geeigneten elektronischen Fehlerverwaltung gesammelt und einem strukturierten Prozess zur Verfolgung der Fehlerbeseitigung zugeführt. Ein Fehlerbericht sollte neben einer verständlichen Beschreibung auch mindestens folgende Informationen enthalten:

  • Kurzbeschreibung (Ist/Soll)
  • Entdecker
  • Entdeckungszeitpunkt
  • Version die getestet wurde
  • Umgebung die getestet wurde

 

Die Fehlerverwaltung muss über die gesamte Projektlaufzeit kontrolliert werden, damit Fehler zeitnah bearbeitet werden. Für die Fehlerverwaltung und das Änderungsmanagement wird ein Ablaufplan mit diversen Status definiert, die den Bearbeitungsstand dokumentieren. Die Berechtigungen der jeweiligen Statuswechsel können und sollten Personen bzw. Personenkreisen zugeordnet werden. Nachfolgend ist ein Beispiel für einen Ablaufplan dargestellt.

Änderungsmanagement

Das Änderungsmanagement definiert einen Prozess zur Erfassung, Verfolgung und Umsetzung von Änderungsanforderungen. Eine Änderungsanforderung ist wie ein Fehler eine Abweichung von der Planung. Im Unterschied zum Fehler, der ungewollt ist, ist die Änderungsanforderung gewollt. Die Änderungsanforderung wird gestellt um die Planung zu verbessern oder ist z.B. auch notwendig um das Planungsziel noch zu erreichen. Änderungsanforderungen werden in Berichten erfasst. Diese können ebenfalls in der elektronischen Fehlerverwaltung oder einer eigenen elektronischen Verwaltung gesammelt und einem strukturierten Prozess zur Verfolgung der Umsetzung zugeführt werden. Ein Änderungsanforderungsformular sollte neben einer verständlichen Beschreibung auch mindestens folgende Informationen enthalten:

  • Kurzbeschreibung
  • Anfordernder
  • Anforderungszeitpunkt
  • relevante Version
  • relevante Umgebung

Die Änderungsanforderungsverwaltung muss ebenfalls über die gesamte Projektlaufzeit kontrolliert werden, damit Änderungsanforderungen zeitnah bearbeitet werden. Für die Fehlerverwaltung und das Änderungsmanagement wird ein Ablaufplan mit diversen Status definiert, die den Bearbeitungsstand dokumentieren. Die Berechtigungen der jeweiligen Statuswechsel können und sollten Personen bzw. Personenkreisen zugeordnet werden. Nachfolgend ist ein Beispiel für einen Ablaufplan dargestellt.

Dokumentation und Berichtswesen

Das Berichtswesen dient der Archivierung und Aufarbeitung aller Informationen, die das Projekt betreffen. Der Bericht sollte folgende Informationen enthalten:

  • Wer hat getestet?
  • Wann wurde getestet?
  • Welche Version wurde getestet?
  • In welcher Systemumgebung wurde getestet?
  • In welcher Testumgebung wurde getestet?
  • Was wurde getestet? (zu welchem Konzept gehört der Test?)
  • Ergebnis des Tests? (ggf. mit Erläuterung)