Testing durch 4-Augen-Prinzip

Warum muss eine Software durch spezialisierte Tester geprüft werden?

Warum kann man den Systemtest nicht durch den Entwickler vornehmen lassen?

Gerade jetzt, nach der Weihnachtszeit drängt sich der Vergleich mit einem mehrgängigen Menü auf:

Sie haben eine Vorspeise, eine Hauptspeise und einen Nachtisch für Gäste ausgesucht. Sie versuchen sich an Rezepten, die neu sind, denn Sie wollen die Gäste ja überraschen.

Wenn im Rezept steht, dass Sie mit „reichlich Dill“ abschmecken sollen, wieviel ist dann „reichlich“. Oder der „Schuss Rotwein“ – wieviel ist das? Wenn Sie schon häufiger gekocht haben, werden Sie diese Frage beantworten können mit „Das habe ich im Gefühl“.

Sie brauchen niemanden neben sich, der Ihnen sagt, ob die Suppe die richtige Konsistenz hat, oder die Kartoffeln gar sind.

Aber bei der „Zubereitung von Software“? Haben Sie da auch alles im „Gefühl“?

Gerade wenn es um die Frage geht, ob die Anforderungen des Kunden auch so umgesetzt wurden, wie er es sich wünschte, kann eine zweite Meinung die Chance erhöhen, auf Anhieb den Kundenwunsch komplett umzusetzen.

Wenn es nicht um eine Neuentwicklung geht, sondern um eine Softwareerweiterung, sind Sie als Entwickler vielleicht so sehr auf die neuen Funktionen konzentriert, dass Sie alte Funktionalität übersehen und dann versehentlich zerstören oder entfernen.

Dies macht deutlich, wie wichtig ein detaillierter Testplan und ein unabhängiger Tester sind. Wir bieten Ihnen an der Stelle gern unsere Erfahrung und unsere Werkzeuge, um Testpläne zu erstellen und zu pflegen. Diese Testpläne können dann regelmäßig durchgeführt werden, und das Produkt so auf gleichbleibende Qualität geprüft werden.

Wenn Sie Interesse oder weitere Fragen haben, erreichen Sie uns unter contact@augmenvis.de und besuchen Sie uns auf http://www.qa4software.de/

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.

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.

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.

Software-Testing – Warum und Wie?

Warum Software-Testing?

Wenn vom Software-Test die Rede ist, kommen häufig Fragen auf, warum explizite Tests erforderlich seien. Man habe doch beim Entwickler gesehen, dass die Software die gestellte Aufgabe erfüllt und auch im Prototypen sieht doch alles gut aus.
Software-testing
Software-Tester bei der Arbeit

Das muss doch reichen?

Die „Zunft“ der Software-Tester und Test-Verantwortlichen sieht diese Punkte als zwingende Testteile, doch sind noch weitere Fragestellungen im Software-Test zu beachten.
Zunächst wollen wir uns darauf einigen, dass ein Test immer einen Vergleich zwischen einem Soll-Zustand und einem Ist-Zustand darstellt.
Der Soll-Zustand sind die Anforderungen, die an die Software gestellt werden, der Ist-Zustand ist das zu liefernde / gelieferte Software-Produkt.
Die Anforderungen sind zum Teil impliziter Natur („die Software soll nicht abstürzen“, „die Software soll die umgebende Hardware nicht beschädigen“, „die Software soll sicher sein“, „die Software soll intuitiv bedienbar sein“).
Diese Anforderungen werden häufig nicht formuliert oder näher spezifiziert.

Wie funktioniert Software-Testing?

In der Spezifikation, dem Lastenheft findet man jedoch die expliziten Anforderungen.
Auf Basis Ihrer Anforderungen entwickeln wir für sie den Testplan.
Dieser Testplan soll reproduzierbare Testergebnisse liefern, sowohl jetzt wie auch in 5 Jahren.
Abgrenzen muss man noch den Begriff des Testens von der Fehlersuche:
Der Test ist ein Soll-/Ist-Vergleich, dessen Detailgrad von der Tiefe des Testplans abhängig ist. Der Test kann Abweichungen („Bugs“) zu Tage führen, die der Entwickler dann untersuchen kann. Ein Test ist aber in der Regel keine detaillierte Fehlersuche oder eine Bereitstellung einer Lösung. Diese obliegt dem Entwickler, der Tester kann lediglich einen Vorschlag machen.
Dies dient der Wahrung des 4-Augen-Prinzips und der Objektivität des Testers.
Umfang des Software-Testing
Angebotsübersicht zur Software-Qualitätssicherung