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.

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