9. Dezember 2011

Die Bugs sind keine Bugs - aber was dann?

IT Projekte sind immer wieder eine Herausforderung, vor allem auch in der Rolle als Dienstleister. In diesem Beitrag wird das Testen auf Kundenseite beleuchtet.
Bevor ein System auf dem Testsystem beim Kunden installiert wird, wird dies intern getestet, je nach Kundenanforderung sehr ausführlich. Dennoch sollte der Kunde, um das System schlussendlich abnehmen zu können, ebenfalls testen. Das steht idealerweise auch im Angebot, im Projektplan und allen weiteren Dokumenten und man hat ein entsprechendes Bug-Tracking-System im Einsatz. 

Nun beginnt der Kunde also zu testen. Und erfasst Issues. Tatsächlich sind  es aber keine Bugs, sondern Issues:
  • Der Kunde weiss oftmals nicht, wie das System zu bedienen ist und glaubt, ein bestimmtes Verhalten des Systems sei ein Bug - richtigerweise ist es aber ein Bedienungssfehler.
  • Der Kunde bedient mit dem Beginn des Testens zum ersten Mal das System. Zuvor hat er sich beispielsweise in einer Präsentation eines Zwischenreleases den Status zeigen lassen oder er hat nur Screenshots vom Design/oder Wireframes gesehen. Immer wieder erhalte ich dann Issues wie „Der Schriftzug ist zu dominat, wir hätten ihn gerne etwas kleiner“ oder „Können Sie diese Buttons blau einfärben?“.
Solche Issues sind in der Regel aus Sicht des Projektteams kein Fehlverhalten des Systems. Entweder wurde es nicht bis ins letzte Detail spezifiziert oder man sieht, dass beispielsweise das Design mit „realen Inhalten“ doch nicht so ganz passt. Hier einige Tipps, wie mit einer solchen Situation umgegangen werden kann:

  • Schulung VOR Testbeginn planen und durchführen: Damit hat der Kunde beim Testen bereits das KnowHow wie das System zu bedienen ist
  • Design-Issues mit dem Kunden besprechen. Hier helfen die Designvorlagen, der Styleguide und die Browser, auf die optimiert werden soll. Sind es tatsächlich Fehler, so sollen diese behoben werden. Sind es Wünsche so können diese als Change Requests aufgenommen werden. Ist es nirgends definiert, so muss mit dem Kunden eine Lösung gefunden werden (z.B. Kostenteilung etc.)
  • Bei grosser Unsicherheit: Testunterstützung beim Kunden vor Ort anbieten und die Testpersonen beim Testen begleiten. Bedinungsfehler können direkt angeschaut und eliminiert werden.
  • Gemeinsame Definition von Bugs: Was soll der Kunde im Bugtracking System erfassen? Wie wird ein Fehler beschrieben. Allenfalls einige Beispiele von guten Fehlerbeschreibungen zeigen.
  • Transparente Kommunikation während der Testphase: Aufzeigen, wie ein Issue eingeschätzt wird, gemeinsam mit dem Kunden definieren, wann was korrigiert wird und wann ein neuer Release/Patch geliefert wird. Hier helfen z.B. Testpläne, Releasepläne, wöchentliche Meetings oder wenn notwendig sogar tägliche Telkos
  • Ressourcen und Puffer (Kosten, Zeit) für Fehlerbehebungen einplanen

Ich habe bereits die Erfahrung gemacht, dass es oftmals mehr Designissues gibt als funktionale Fehler. Für den Kunden sind diese auch oft schwerwiegender. Verständnis seitens Projektleiter gegenüber dem Kunden aber auch gegenüber des Projektteams ist entscheidend in dieser Phase. So kann der Projektleiter sicherstellen, dass das Projekt auch in der "letzten" Phase vor Going Live auf Kurs bleibt.

Keine Kommentare:

Kommentar veröffentlichen