Der Acolad-Blog

Das Testen von Plattformen – eine Kette mit vielen Gliedern

Geschrieben von Acolad team | 24.05.2018 07:00:00

Das Systems Science Institute von IBM berichtet, dass die Kosten einer Behebung eines in der Implementierungphase georteten Programmfehlers etwa 6 mal höher ausfällt als in der Entwurfsphase – und 15 mal höher als in der Testphase. Können Sie sich vorstellen, wie viel Geld durch einen sorgfältigen Testprozess ab der einleitenden Entwicklungsphase gespart werden kann?

Hier geht es aber um mehr als nur die Behebung von Programmfehlern oder das Orten fehlerhafter Codezeilen, die nicht nach den Vorstellungen der Entwickler funktionieren. Das Testen ist zur Gewährleistung einer optimalen Leistung und Effizienz des Systems unerlässlich – von den Funktionalitäten des Produkts über die Nutzbarkeit für Endbenutzer bis hin zu endgültigen Geschäftsanforderungen und –zielen. Ob es sich dabei um ein internes Projekt oder eine durch einen Partner bereitgestellte Lösung handelt – jede Software muss wie jedes neue Produkt vor seiner Markteinführung auf Herz und Nieren geprüft werden.

Was benötigen Sie, bevor Sie mit der Funktionsprüfung beginnen können?

Als Projektmanager, werden Sie einen detaillierten Plan benötigen. Sie müssen eine klaren Zeitplan für alle Stakeholder erstellen, Schwerpunkte definieren und akkurate Prüfbestimmungen erstellen. Sie müssen ebenfalls wissen, wer die Tests durchführen wird, welche genaue Rolle diese innehalten werden und wann sie für diese Aufgabe freigestellt werden können.

Als Tester ist Ihre Rolle umso wichtiger, wenn nicht die Wichtigste. Eine guter Tester ist eine Klasse für sich –und je nachdem, ob Sie diese Rolle als Geschäftsinhaber, Content Editor oder im Rahmen jeder anderen Position ausführen: Sie müssen genau wissen, wann und wie Sie den Test durchführen müssen und welche Bereiche gesondert untersucht werden sollen. Als fest zugeordneter Tester, müssen Sie eine klare Vorstellung über die Lösungsanforderungen haben, sowohl funktioneller als auch non-funktioneller Natur. Sie sollten die unterschiedlichen Bedürfnisse der verschiedenen Benutzer der Plattform kennen und sie an Ihrem Testvorgang teilhaben lassen.

Stellen Sie sich einmal vor, dass eine Software bereitgestellt wurde. Welche Schritte sollten hier als Nächstes unternommen werden? Im Rahmen des Testens folgt nun eine Checkliste:

  • Was wurde bereitgestellt und noch wichtiger: was nicht?
  • Was sind die Anforderungen in den Bereichen, die ich testen werde?
  • Wie und wo teste ich: Kann ich mich im System einloggen, kann ich den Testvorgang über unterschiedliche Browser durchführen?
  • Wie kann ich Programmfehler und Veränderungen melden und an wen wende ich mich bei Fragen?
  • Stehen Richtlinien zur Verfügung, um die Tester zu unterstützen?

Wäre es nicht hilfreich, eine Nachricht einer Bereitstellung mitsamt solch einer Checkliste zu versenden? Im Idealfall sollte es das.

Testphasen und die verschiedene Rollen: Wer testet, und weshalb?

Für jedes überschaubare Projekt würde man folgende Tester-Rollen erwarten:

  • Entwickler
    • Was: Testen der eigenen Arbeit anhand von Komponententests, grundlegenden Funktionsprüfungen und Peer-Reviews
    • Wann: Durch die Entwicklung hindurch
  • Funktionsanalyst
    • Was: Plausibilitätsprüfung, Funktionsprüfungen, Nutzbarkeits- und Beständigkeitstests
    • Wann: Vor und nach jedem Release (auch bei Releases in der internen Entwicklerumgebung)
  • Content Editor
    • Was: Nutzbarkeitstests
    • Wann: Nach jedem Release in der Editor-Umgebung
  • Produktinhaber:
    • Was: Plausibilitätsprüfung, Funktionsprüfungen
    • Wann: Nach jedem Release in einer Umgebung ohne Entwicklerfunktionen

Es mag überflüssig erscheinen, einen Funktionstester alles überprüfen zu lassen, nachdem der technische Leiter ein bestimmtes Feature oder eine Funktionalität bereits abgesegnet hat. Besonders wenn man weiß, dass die Entwickler bereits ein Peer-Review für dieses spezielle Feature bzw. Funktionalität ausgeführt haben. Dabei sollte bedacht werden, dass Entwickler während des Testens und der Überprüfung ein unterschiedliches Ziel verfolgen. Bei der Überprüfung, werden sie sicherstellen, dass der Code in Ordung ist (an dieser Stelle könnten wir einen einzelnen Blogeintrag über die Definition eines guten Codes einbringen) und auch das tut, wofür es entwickelt wurde. Das bedeutet nicht notgedrungen, dass es das tut, wofür es funktionell gedacht war, dass es intuitiv ist oder im Rahmen der gesamten Lösung auch funktioniert. Desweiteren, werden Tests von Menschen durchgeführt – und Menschen können nun mal Fehler begehen. Dies ist auch der Grund warum es so wichtig ist, weitere Qualitätsbewertungen über alle Testphasen hinweg durchzuführen.

Dasselbe gilt für den Produktinhaber, der am Ende ebenfalls viele Test durchzuführen hat. Der Funktionsanalyst könnte einen Fehler übersehen haben, es könnte eine Anforderung fehlen oder nach genauerem Hinsehen auch Veränderungen nötig sein.

Die Testskette ist lang aber auch äußerst wichtig, demnach sollte an dieser Stelle nicht gespart werden. Wenn der Vorgang nicht fachgemäß ausgeführt wurde und dadurch bestimmte Fehler nicht zeitnah entdeckt wurden und so den Entwicklungsprozess verlangsamen, könnte dadurch die gesamte Lösung gefährdet werden.