Test: Business-Software auf dem Prüfstand

Das Testen der Business-Software Lösung kann mit unterschiedlichsten Möglichkeiten und Varianten angegangen werden. Der Test der Business-Software jedoch ist und bleibt einer der wichtigen Eckpfeiler und eine der entscheidenden Massnahmen zur Qualitätssicherung. Um eine effiziente, den Ressourcen-Einsatz optimierte und systematische Durchführung der Tests zu gewährleisten sind einige Punkte zu beachten. Spannend und des öfteren in Projekten erkennbar sind die gegenläufigen Kurven, einerseits die mit fortschreitender Zeit abnehmende Einflussmöglichkeit (in der Graphik grün gekennzeichnet) auf die Ergebnisse und andererseits das immer grössere Interesse (oranger Linienverlauf) daran. Spätestens mit den ersten nicht korrekt funktionierenden Funktionen der Business-Software Lösung steigt die Aufmerksamkeit der Anwender und damit der Projektverantwortlichen rasch an. Mit einem strukturierten und bewussten Test-Vorgehen wird die Qualität der Anwendung positiv unterstützt und ist somit eine der massgebenden Aufgaben zur Sicherstellung hoher Qualitätsansprüche.

Test-Interessensverlauf

Das Test-Konzept

„Komm wir testen mal“ ist zwar auch eine mögliche Testvariante, in der Praxis bewährt es sich jedoch, zuerst das Vorgehen zu strukturieren, definieren und verbindlich zu regeln. Dazu eignet sich in aller Regel ein Test-Konzept. Das Test-Konzept wird idealerweise in enger Zusammenarbeit zwischen dem Systemlieferant, dem Anwender und dem Betreiber erstellt. Wichtig ist, die nächsten Schritte erst in Angriff zu nehmen, wenn die wesentlichen Inhalte des Test-Konzepts von allen beteiligten Parteien genehmigt sind. Das Test-Konzept kann beispielsweise umfassen:

  • Test-Ziele, Objekte und Arten
  • Test-Rahmen und Organisation, Definition der Fehlerklassen
  • Test-Infrastruktur (System, Daten, Hilfsmittel)
  • Test-Beschreibungen

Diese – sich an konventionellen Projektmethoden orientierende – Möglichkeit entspricht natürlich noch keiner vollständigen Übersicht, liefert aber bereits mit wenigen Aspekten eine gute Ausgangslage für das Test-Konzept. Insbesondere innerhalb agiler Projektmethoden können einzelne Elemente im ‚konventionellen‘ Test-Konzept in Frage gestellt werden. Wie die nachfolgend zitierte Studie der swissQ aufzeigt, sehen unabhängig von diesem Aspekt 91.4% weiterhin Bedarf an Testspezifikationen und Testfällen (Quellenangabe). Bleiben wir noch kurz bei Erkenntnissen im Zusammenhang mit unterschiedlichen Projektmethoden. Wie der Trends & Benchmarks Report Schweiz der swissQ in Zusammenarbeit mit dem Institut für Technologiemanagement der Universität St. Gallen zeigt, steigen die Wasserfall-Vorgehensmodelle wieder an. Die angewandten Vorgehensmodelle sind gemäss der Umfrage aus dem Jahre 2013 wie folgt verteilt (in Klammer die Werte der Umfrage aus dem Jahre 2012):

  • 53% (40%) Wasserfall
  • 49% (51%) Agil
  • 20% (22%) Iterativ
  • 10% (16%) RUP
  • 10% (12%) Hermes

Weitgehend unabhängig dieser Vorgehensmodelle kann festgehalten werden, dass das Test-Konzept beschreibt, wie die Tests – und unter welchen Bedingungen – erfolgen sollen. Dabei werden die zu prüfenden Bereiche festgelegt, dokumentiert, in einem Review geprüft und durch eine definierte Stelle genehmigt. Darüber hinaus ist im Test-Konzept zu beschreiben, welche Art von Tests (einzelne Komponenten, Integration, Teil- oder Gesamtsystem) durchgeführt werden. Ebenfalls in diesem Konzept zu definieren sind die Test-Daten, welche für die Durchführung eingesetzt und zur Verfügung gestellt werden müssen.

Die Test-Infrastruktur

Als Grundlage für die Durchführung der Prüfungen ist eine Test-Infrastruktur zu erstellen. Diese soll die effiziente und nach Drehbuch vorbereitete Durchführung ermöglichen und die parallel dazu stattfindende Dokumentation sicherstellen. Die Situation kann es erfordern, dass die Test-Infrastruktur vollständig losgelöst von der operativen Lösung funktionieren muss. Auf jeden Fall soll diese Überlegung bereits bei der Evaluation einer neuen Business-Software ins Projekt einfliessen. Die einzusetzende Test-Infrastruktur ist in der Konzeptphase zu definieren und ermöglicht damit die effiziente Durchführung der Prüfungen. Eine weitere wichtige Tätigkeit in dieser Phase ist die Bereitstellung der Testfälle und der für die Tests notwendigen Daten. Die Daten sollen qualitativ hochwertig sein, was bedeutet, dass sie zu den Testfällen passen und in sich stimmig sind. Oft eignen sich dazu Daten aus dem Live-Betrieb (operativ genutzte Daten).

Die Test-Durchführung

Sind alle Vorkehrungen getroffen und ist das System soweit bereitgestellt, dass eine erfolgsversprechende Prüfung stattfinden kann, erfolgen die Tests gemäss dem vorgängig erstellten Test-Konzept auf der dafür bereitgestellten Infrastruktur. Die Durchführung ist für die Sicherstellung der Business-Software Qualität von hoher Bedeutung. Wie bei vielen anderen Aufgaben, ist auch in dieser Phase wichtig, folgende Aspekte nicht aus den Augen zu verlieren:

  • Es geht nicht um die Suche nach ‚Schuldigen‘, es geht um das Erkennen von Fehlern und dem Einleiten von Verbesserungen.
  • Die Perspektive des zukünftigen Anwenders berücksichtigen und in den Fokus der Arbeiten setzen.
  • Eine erweiterte Automatisierung kann einen wesentlichen Beitrag zur effizienten Durchführung leisten.
  • Die Rahmenbedingungen für die beteiligten Personen sind möglichst optimal zu gestalten. Dies bedeutet auch, dass Tests wo immer möglich in Teams durchgeführt werden, in welchen alle Interessensgruppen vertreten sind.

Der Test umfasst sowohl die Prüfung ‚gegen‘ die erfassten Anforderungen (Lastenheft, Anforderungskatalog), die Abbildung der SOLL- Geschäftsprozesse, der Use Cases, der Interaktionen mit anderen Systemen (beispielsweise aus den Systemkontext-Diagrammen) wie auch weitere Anforderungen wie Redundanz, Verfügbarkeit, Integrität, Sicherheit und Weitere. Und warum steht da prüfen ‚gegen‘? Um ‚gegen etwas‘ testen zu können, ist das ‚etwas‘ vor der Durchführung der Tests festzulegen. Aufgrund der durchgeführten Prüfung wird die IST-Situation erfasst und mit den im Voraus definierten, erwarteten Test-Ergebnissen (SOLL-Situation) verglichen. Die Abweichungen zwischen IST und SOLL werden gemäss den ebenfalls im Voraus gemeinsam festgelegten Fehlerklassen klassifiziert. Mögliche Fehlerklassen sind:

  • Fehlerklasse 1: Betriebsverhindernde Mängel, dies bedeutet, dass mit diesem Testergebnis keine operative Betriebsaufnahme möglich ist.
  • Fehlerklasse 2: Betriebsbehindernde Mängel, dies bedeutet, dass falls eine operative Betriebsaufnahme erfolgen sollte, für die Anwender einzelne – in sich geschlossene – Einschränkungen zu akzeptieren sind.
  • Fehlerklasse 3: Nicht betriebsbehindernde Mängel, dies bedeutet, dass der Leitung die Betriebsaufnahme mit gutem Gewissen beantragt werden kann.

Zur Erinnerung, die Durchführung von Tests umfasst sowohl die Prüfung gegen funktionale wie gegen nicht-funktionale Anforderungen.

Mit einem strukturierten und bewussten Test-Vorgehen wird die Qualität der Business-Software positiv unterstützt und ist somit eine der massgebenden Aufgaben zur Sicherstellung hoher Qualitätsansprüche. Der Test-Prozess startet in einer frühen Projektphase, benötigt einen nicht unwesentlichen Anteil der zur Verfügung stehenden Ressourcen und ist eine gute Investition in eine gut funktionierende und akzeptierte Business-Software Lösung.

Veröffentlicht am 18. Dezember 2014

Kommentar schreiben