Das ideale Bugticket und seine Rolle in der Softwarequalitätssicherung

Heute beschäftigen wir uns mit dem idealen Bug-Ticket.

Das ideale Bugticket existiert nicht… denn der Wunsch aller Software-Entwickler – und das schließt die Qualitätssicherung mit ein – ist eine fehlerfreie Software.
Da dieser Wunsch wohl ein Traum bleiben wird, wollen wir uns mit der Frage befassen, welche Angaben ein solches Bugticket umfassen sollte.

 Angaben im idealen Bugticket

  • Überschrift – die Überschrift sollte präzise auf den ersten Blick die Auswirkung und Ursache eines Fehlers darstellen.
    Ein schlechtes Beispiel wäre wohl „Datenverlust in Applikation“
    Gut hingegen „Datei wird nicht überschrieben, wenn Button Speichern gedrückt wird“
  • Die Beschreibung – sie sollte detailliert erklären, was der konkrete Fehler ist. Außerdem muss sie eine Beschreibung enthalten, wie der Fehler reproduziert werden kann. Welche konkreten Schritte sind zu unternehmen.
    Dies ist zwingend erforderlich für den Entwickler, der den Fehler finden soll, und für den Tester, der nachher die Behebung des Fehlers feststellen muss.
    Ein Fehler, der nicht reproduzierbar ist, kann nicht behoben werden!
    Vergessen Sie nicht zu erwähnen, in welcher Version der Fehler auftrat. Eine Behebung findet manchmal Wochen oder Monate später statt, und der Fehler ist auf dieser Version dann schon „zufällig“ durch jemand anderen behoben worden.
  • Arbeiten Sie im Projekt mit einer Komponenten-Einteilung, oder sonstigen Zuweisung?
    Dann tun Sie Ihren Kollegen einen Gefallen, und wählen Sie gleich die richtige Komponente aus. Eine falsche Komponente sorgt im Zweifelsfall dafür, dass ein Ticket nicht bearbeitet werden kann.
  • Haben Sie eine bestimmte Konfiguration Ihres Programms, die erforderlich ist, um den Fehler zu reproduzieren?
    Nutzen Sie die Möglichkeit, Dokumente an das Bugticket anzuhängen.
    Dasselbe gilt für Logdateien, auch diese sind häufig hilfreich bei der Fehlerfindung
  • Einteilung eines Fehlers in Bezug auf die Schwere:
    In manchen Ticketing-Systemen ist nur es möglich, eine Wahl zwischen „Hoch“, „Mittel“, „niedrig“ zu treffen.
    Andere Systeme hingegen erlaube eine Einteilung in 2 Dimensionen: Dringlichkeit und Schwere des Fehlers. Diese Einteilung werden wir zu einem späteren Zeitpunkt detailliert behandeln.An dieser Stelle nur soviel: Die Dringlichkeit gibt an, wie schnell ein Fehler behoben werden muss („spät“, „sofort – die Testabteilung kann sonst nicht weiter arbeiten“). Die Schwere des Fehlers hingegen gibt an, mit welchen Folgen ein Fehler verbunden ist (kritischer Fehler – „Datenverlust“, kosmetischer Fehler – „Tippfehler“).Auch ein Tippfehler kann ein release verhindern, zum Beispiel, wenn die Email-Adresse des Unternehmens falsch eingetragen ist.

Bug-Triage – was soll das?

In diesem Artikel widmen wir uns der „Bug-Triage“.
Es handelt sich dabei um einen Teil-Prozess, der Software-Entwicklung, der in den späteren Projektphasen zum Tragen kommt.
Eine Triage wird abgehalten, um die anfallenden Bug-Tickets nach Schwere einzuteilen bzw. die bisher getroffenen Einschätzungen zu revidieren.
Der Begriff ist entliehen aus der Beurteilung von Verletzten in Großschadenslagen. Das medizinische Personal muss hier sinnvoll eingesetzt werden, da es mehr Patienten gibt als man gleichzeitig behandeln kann. Daher wurde dieses Verfahren entwickelt, um schnell festzustellen, welche Patienten dringend Hilfe bedürfen – wegen lebensgefährlicher Verletzung, und welche Patienten nur leicht verletzt sind.
Und in der Software-Entwicklung?
Hier ist eine Bug-Triage anzuberaumen, wenn die Zeit bis zum Liefertermin nicht mehr ausreicht, um alle offenen Bugtickets bearbeiten zu können. Dies ist leider häufig der Fall. Es wird immer wieder Fehler geben, die man nicht rechtzeitig beheben kann.
Zum Glück haben wir in der Software-Entwicklung manchmal die Alternative, ein Release zu verschieben, aber das ist weder die Entscheidung der Qualitätssicherung noch die Entscheidung der Entwickler.
In der Bug-Triage sitzen deshalb typischerweise mindestens folgende Rollen vereint an einem Tisch:
  • ein Vertreter der Software-Qualitätssicherung – er kann Auskunft über die einzelnen Bugtickets geben, und einschätzen, wie schwerwiegend ein Fehler ist
  • ein Vertreter der Entwicklung – er kann Auskunft darüber geben, wie aufwändig ein Fehler zu beheben ist, und ob ggf. Seiteneffekte zu beachten sind, die der Qualitätssicherung noch nicht bekannt sind
  • eine Vertreter des Projekt-Managements – er kann abschätzen, ob man einen Fehler im Produkt eher akzeptieren kann als einen verschobenen Liefertermin – oder umgekehrt.
Manchmal wird auch explizit noch der Product Owner, der die Produktverantwortung im Haus trägt, diesen Treffen beiwohnen.
Ziel dieser Treffen ist es, sich möglichst schnell auf einen Weg zu einigen, wie mit den Patienten – also den einzelnen Fehlern – umgegangen werden soll. Welcher Fehler ist „lebensgefährlich“ und wird daher sofort behandelt? Welche Fehler ist „hinnehmbar“, und die Behandlung kann auf später vertagt werden?
Um das Treffen effizient zu gestalten, sollte allen Parteien genügend Gelegenheit gegeben werden, die Bugreports vorab zu lesen, und eine Klassifikation im Sinne eines Schweregrads und Aufwands vornehmen zu können. So können einzelne Analysen im Treffen vermieden werden.
Üblicherweise wird man die Bewertung eines Bugtickets in Bezug auf Schwere und Dringlichkeit überarbeiten. Zusätzlich wird man einen Schwellwert setzen, bis zu dem Fehler noch bearbeitet werden – bzw. welche Fehler im Release noch enthalten sein werden.
Wann ist eine solche Bug-Triage sinnvoll?
Die Triage wird in dem Moment erforderlich, wenn man merkt, dass die Projektzeit „knapp“ wird, wenn also der Liefertermin bei Fehlerfreiheit nicht garantiert werden kann.
Was sind die Risiken, wenn man diese Triage nicht durchführt?
Die Partei, die im Unternehmen den stärksten Einfluss hat, wird siegen.
  • die Software-Qualitätssicherung könnte das optimale Produkt fordern, ohne Rücksicht auf den Liefertermin
  • die Entwicklung arbeitet möglicherweise nicht an den wichtigen Bugtickets
  • das Projekt-Management muss ein Produkt liefern, welches mehr Fehler besitzt als erforderlich

Umfang der Testaktivitäten

Testen ist aufwändig, und scheint zunächst keinen zusätzlichen Nutzen zu bergen. Die Idee ist nicht, dass man zusätzlichen Ertrag erzeugt, sondern Schaden im Vorfeld vermeiden kann.
Doch wie viel Aufwand soll ins Testing investiert werden?
Diese Frage kann nur das Produktteam in seiner Gänze beantworten.
Eine pauschale Antwort lässt sich auf diese Frage nicht geben.
Der Umfang der Software-Tests hängt davon ab, wie viel Zeit investiert werden kann – auf der einen Seite – und auf der anderen Seite, wie hoch der Schaden ist, wenn sich im ungetesteten Teil Fehler finden. Einer Raumsonde, die Sie auf die Reise zum Mars schicken, können Sie schlechter ein Software-Update einspielen als dem Web-Shop, den Sie auf der eigenen Homepage verwenden…
Als Software-Tester / Test-Manager habe ich mir über die Jahre angewöhnt zu behaupten, dass nur Code, der durch dedizierte Test-Team-Mitglieder überprüft (und abgenickt!) wurde, als funktionierend anzusehen.
Im Umkehrschluss heißt das: Alles, was ein Tester sich nicht angeschaut hat, ist als defekt anzusehen!
Das mag im ersten Moment hart und zynisch klingen, rettet aber vor unangenehmen Überraschungen…
Insofern empfehle ich, dass der komplette Produktumfang zumindest einmal stichpunktartig geprüft werden sollte.
Je näher der Programmteil mit solchen Teilen verknüpft ist, die einer geplanten Änderung unterlagen, desto größer ist die Chance, dass sich hier Fehler ergeben. Und, je mehr Fehler sich in einem Bereich finden, desto „lohnender“ ist es, sich diesen Bereich näher anzuschauen.
Auf der einen Seite haben wir also nun die Bereiche identifiziert, die besonders wichtig zu testen sind. Wenn Sie, auf der anderen Seite, ein Produkt erweitern, gibt es sicherlich gibt es auch in Ihrer Software Programmteile, die schon seit Jahren unverändert gut laufen. Bei diesen Programmteilen kann man sich erlauben, die Tests in geringerer Intensität durchzuführen.
In meiner Rolle als Test-Managers besteht die Aufgabe auch darin, in der zur Verfügung stehenden Zeit die optimale Testabdeckung anzustreben. Daher werde ich mich hier immer wieder, gerade zu Anfang des Projekts, intensiv mit dem Entwicklungs-Leiter und dem Projekt-Manager beraten, wieviel Zeit für welche Test-Aktivitäten investiert werden kann, und wo diese Zeit am sinnvollsten investiert ist.
Auch das ist ein Prozess, der erlernt werden will.
Und wenn das Team sich zuviel vornimmt?
Dem Produkt-Verantwortlichen obliegt es dann ggf., einen Liefertermin anzupassen, den Projektumfang zu reduzieren oder mit einem (potentiell) fehlerbehafteten Produkt zu leben.
Um es nicht so weit kommen zu lassen, sollte die Entwicklung die Software-Qualitätssicherung, das Testing als Teil der notwendigen Arbeit akzeptieren.

Test-Ebenen und Test-Akteure

Software-Test-ToolboxDas Testen der Software kann sowohl durch den Lieferanten / Hersteller geschehen, wie auch durch den Kunden, der seinen Einsatzzweck umgesetzt sehen will.
Auf Seiten des Herstellers wird der Test dann noch in verschiedene Ebenen unterteilt.

Testebenen

  • Unit-Test / Komponenten-Test

    Dies ist die Ebene, die dem Quellcode am nächsten ist. Es werden einzelne Software-Module getestet. Ziel des Tests ist es, dass die einzelnen Module die geplante Funktionalität für sich bereit stellen können.
    Diese Art von Test obliegt typischerweise dem Entwickler. Wobei wir auch hier gern für Sie da sind und Hilfestellung zu leisten. Dafür setzen wir ein Gerüst auf und implementieren erste Tests.

  • Integrations-Test

    Hier werden einzelne Komponenten miteinander getestet. Ziel dieses Tests ist es, die definierten Schnittstellen zwischen den Komponenten zu testen. Diese Teststufe ist ebenfalls noch recht nah am Code. Sie umfasst aber mehrere Komponenten und damit ggf. schon mehrere Entwickler. Dies ist immer auch abhängig von der Größe des Teams.

  • System-Test

    Dieser Test umfasst das Gesamt-System, und findet auf einer Test-Umgebung statt, kann also noch durch das liefernde Unternehmen abgebildet werden. Es werden sowohl funktionale wie auch nicht-funktionale Anforderungen überprüft.

Dem Kunden obliegt letztlich der
  • Abnahme-Test

    Die Durchführung erfolgt nicht mehr anhand von Testdaten auf einer Testumgebung, sondern in der Produktiv-Umgebung, mit realen Daten.

Wir sind in der Lage, Sie als Hersteller während der Entwicklung zu begleiten und Ihnen bei der Test-Entwicklung und -Durchführung zu unterstützen.
Aber auch Kunden, die eine Sonder-Entwicklung in Auftrag gegeben haben,  helfen wir gern. Und stellen sicher, dass das Lastenheft umfassend überprüft wird.
Durch unsere langjährige Erfahrung können wir Ihnen in beiden Fällen helfen.  Besonders beim Abbauen der Sprachbarrieren, die zwischen den häufig technisch geprägten Entwicklungs-Abteilungen und den Fachabteilungen bestehen. Dadurch erreichen Sie das richtige Ergebnis in kürzerer Zeit!

Das Handwerkszeug des Projektteams

In diesem Post soll es um das Handwerks-Zeug aller Akteure in der Software-Entwicklung gehen.
Welche Tools benötigen die Akteure nun, um ihre Aufgaben zu erfüllen?
Wo notiert der Product Owner seine Anforderung? Wo speichert der Entwickler seinen Quellcode? Und worauf greift der Tester zurück, wenn er das Produkt installieren will?
Es gibt mindestens 3 Werkzeuge, die für ein Gelingen vorhanden sein sollten. Weitere Werkzeuge können sinnvoll sein, abhängig von der Situation.
  1. Das Ticketing-System,

    auch als „Bug-Tracker“ bezeichnet, ist eigentlich viel mehr als eine Sammlung
    Es ist die zentrale Anlaufstelle, um alle Änderungswünsche „mundgerecht“ zerlegt auszutauschen:
    * Der Product-Owner kommuniziert seine Wünsche
    * Die Qualitätssicherung meldet Programmfehler („Bugs“), die während vor der Veröffentlichung, dem Release des Produkts aufgefallen sind
    * Der Support meldet Programmfehler, die von Kunden berichtet wurdenJedes Ticket besitzt seine eigene Geschichte, und man kann im Prozess verfolgen, wer ein Ticket bearbeitet hat, und ob bzw. wie es gelöst wurde.Das Ticket-System bildet sozusagen den Dreh- und Angelpunkt der Planung und gibt detaillierten Aufschluss über die Historie bzw. die zukünftige Planung.

  2. Das Repository, auch als Projektarchiv bezeichnet

    Es beinhaltet den nachvollziehbaren Versionsstand einer Software.
    Hier werden alle Quelldateien der Entwicklung eingestellt und alle Änderungen nachvollzogen. Dies ist sozusagen Ihr Kapital, Ihr Projektschatz.
    Sie sind in der Lage Änderungen bis zum Beginn des Projekts zurückzuverfolgen und, falls erforderlich, wieder rückgängig zu machen.

  3. Der Build-Server

    Im Rahmen der Nachverfolgbarkeit ist der Build-Server die Umgebung, die aus einem Software-Stand aus dem Repository immer wieder dieselbe Version an Software liefern kann – auch nach Jahren!Nur die Software, die vom Build-Server gebaut worden ist, kann als vertrauenswürdig und reproduzierbar angesehen werden.Einmal fertig konfiguriert, liefert der Build-Server eine Software-Version, die Sie direkt auf Ihrer Zielumgebung installieren können.

Theoretisch ist es natürlich auch möglich, die Anforderungen per Email zu senden, anstatt Bugtickets zu schreiben, dem Entwickler zu zeigen, was „schief läuft“. Man nimmt dann allerdings in Kauf, dass man nach einigen Jahren nicht mehr weiss, wie man sich mal geeinigt hat. Auf ein Ticketingsystem hat jeder Zugriff, die Mails sind typischerweise nur für persönlich durch einen Mitarbeiter zugreifbar.
Und auch ohne Repository kann man die Daten archivieren: Man erstellt einfach ZIP-Dateien mit dem Tageswerk. Nur fragen Sie sich dann, wann denn die Änderung X eingeflossen ist. Spätestens, wenn Sie mehrere Entwickler auf einem Projekt haben, wird es jedoch unübersichtlich!
Ein Build-Server ist sicherlich die Komponente, die am ehest verzichtbar ist. Eine Software „von Hand“ compiliert und ausgeliefert werden. Allerdings wird man vermutlich Schritte vergessen, die Reihenfolge der Schritte verändern oder vergessen, eine Datei zu übertragen. Und dann haben Sie die Software beim Kunden, und sie läuft nicht.
Glauben Sie nicht? Alles schon erlebt…

Schritte der Software-Entwicklung

Für diejenigen Leser, die sich mit der Software-Entwicklung noch nie beschäftigt haben, möchte ich nun einen kurzen Einblick in die Schritte der Software-Entwicklung liefern.
Dieser Einblick ist deswegen relevant, damit man sich vor Augen führen kann, welche Werkzeuge (die wir als nächstes beleuchten) erforderlich sind, um eine Software zu entwickeln.

Die Schritte in der Software-Entwicklung:

  1. Schritt – Anforderung – Aufgabenstellung
    Die Software-Entwicklung erhält eine Anforderung in einer allgemeinverständlichen Sprache („Wir brauchen eine Software, die … erledigt“)
  2. Die Software-Entwicklung nutzt eine sogenannte Hochsprache, z.B. C, C++, C# oder Java, um die Anforderung in Quellcode umzusetzen.
    Der Quellcode ist noch nicht direkt auf der sogenannten „Zielplattform“ ausführbar.
  3. Mittels eines Compilers, der Teil eines Build-Systems sein kann, wird der Quellcode in „Maschinencode“ übersetzt.
    Der Maschinencode ist zwar vom Prozessor ausführbar, kann aber nicht mehr ohne großen Aufwand, von Menschen verstanden werden.
    Zudem sprechen verschiedene Prozessoren unterschiedliche Sprachen.
    Das ist – grob gesagt – einer der Gründe, warum Sie nicht einfach Windows 10 auf einem iPhone installieren können

Der so hergestellte Quellcode kann nun mit einem Installationsprogramm gepackt werden und dann über die eigene Homepage oder einen App-Store für Kunden bereitgestellt werden.

Die Rollen in der Software-Entwicklung

In diesem Blog-Post beleuchten wir die verschiedenen Akteure.
Diese Rollen sind Ihnen wahrscheinlich wohlbekannt, sie sollen dennoch einmal kurz umrissen werden, letztlich auch, damit die Namensgebung klar wird.

Die Rollen sind im Wesentlichen die folgenden:

1. der Product Owner / der Produktverantwortliche
Der Produktverantwortliche bestimmt die Zielrichtung, in die ein Projekt entwickelt werden soll. Diese Zielrichtung kommuniziert er in Form eines Lastenheft an die Entwicklung, damit diese für ihn das Produkt entwickelt.
2. Der Entwickler
Er setzt das Lastenheft um, um eine bestehende Software zu erweitern, oder um eine Software von Grund auf zu entwickeln.
Bis auf das Lastenheft ist er frei in der Wahl seiner Mittel.
3. Der Qualitätssicherer / Tester
Die Software-Qualitätssicherung ist dafür verantwortlich, sicherzustellen, dass das Lastenheft umgesetzt wurde. Bei einem bereits bestehenden Produkt stellt er darüber hinaus sicher, dass die alte Funktionalität immer noch gegeben ist.

Je nach Größe eines Projekts kommen noch verschiedene Rollen zum Tragen, sei es eine Dokumentationsabteilung, eine Support-Abteilung, eine Marketing-Abteilung.
Je größer das Projekt, desto notwendiger ist eine Projektsteuerung, besetzt durch einen Projekt-Manager.

Die oben explizit genannten Rollen stehen in ständigem Austausch miteinander, um gegebenenfalls Änderungen am Zielprodukt vornehmen zu können, wenn sich die Umstände ändern.