Spezifikationen und Testing

Meine bisherigen Blogbeiträge zum Thema „Qualität von Spezifikationen und Anforderungen“ gehören zu den meistgelesenen Artikeln.

Heute habe ich mich mit dem Thema „Testen von Software“ befaßt, und mir insbesondere den Certified Tester – Foundation Level Syllabus angesehen, der vom→ ISTQB (International Software Testing Qualifications Board) herausgegeben wird.

Dort stehen einige interessante Informationen über die Qualität von Spezifikationen, auf die ich heute kurz eingehen will.

Testen von Software

Es gibt mehrere Verfahren, um Softwaretests zu designen, und, um die Werte zu finden mit denen man die Funktionsfähigkeit der Software testet. Wenn Sie zum Beispiel eine Heizungsschaltung herstellen, die bei 15 Grad einschaltet, und bei 22 Grad ausschaltet, würden Sie das Verhalten Ihrer Software in der Nähe dieser Temperaturen messen.

Mit der Equivalence Partitioning Methode testen Sie gleichgroße Intervalle, um die Schaltpunkte herum, wie z.B. die Temperaturen 13, 18, 24 Grad. Bei der Boundary Value Analysis Methode, testen Sie eher die Grenzwerte, bei denen geschaltet wird, da dort die meisten Fehler zu erwarten sind, wie z.B. 14 und 23 Grad.

Das Decision Table Testing läuft wie folgt ab (und da erkennen Sie dann sicher auch gleich die wichtige Rolle einer guten Spezifikation):

Decision tables are a good way to capture system requirements that contain logical conditions, and to document internal system design. They may be used to record complex business rules that a system is to implement. When creating decision tables, the specification is analyzed, and conditions and actions to the system are identified. The input conditions and actions are most often stated in such a way that they must be true or false (Boolean).

Bei dieser Testmethode werden also logische Bedingungen aufgestellt, die sich aus der Spezifikation ergeben. Diese Bedingungen werden getestet, und können sich auch komplexe Systeme beziehen.

Anforderungen an die Spezifikation

Gute Spezifikationen und Anforderungen müssen unterschiedlichen Kriterien genügen. In dem Kapitel Weiterführende Informationen unten finden Sie einige Artikel, in denen ich verschiedene Aspekte schon einmal behandelt habe.

Wenn Sie an die obigen Testmethoden denken, sollten Sie im Hinterkopf behalten, daß Ihre Spezifikation nicht nur die Grundlage für die Softwareentwickler ist. Vielmehr bildet sie sehr viel später im Prozess auch die Grundlage für Tests. Das bedeutet, daß die Qualität einer Software u.a. auch von der Spezifikation abhängt.

Viele Produktmanager konzentrieren sich (meiner Erfahrung nach) auf die Beschreibung der Nutzungsszenarien, und sie befassen sich eher auf hoher Ebene mit den betriebswirtschaftlichen Aspekten einer Software.

Wenn Sie sich die obigen Testmethoden noch einmal vergegenwärtigen, sind folgende Punkte wichtig:

• Die einzelnen Anforderungen müssen konkret ausgearbeitet sein. In der Spezifikation zur obigen Heizungssteuerung sollten zum Beispiel die Schaltpunkte konkret genannt werden, und es sollte auch das Verhalten zwischen den Schaltpunkten beschrieben sein. Dabei dürfen gerne auch sehr konkrete Leistungsvorgaben gemacht werden.
• Eine Spezifikation stellt eine konkrete Beschreibung dar, wie die Kundenanforderungen umgesetzt sein sollen. Da hiervon konkrete Leistungsmerkmale abhängen, deren Einhaltung auch geprüft wird, ist es wichtig, daß die Anforderungen komplett sind. Im obigen Beispiel ist es ratsam, daß der Kunde die Schaltpunkte definiert hat, und daß es sich dabei nicht um reine Annahmen handelt.
• Nach einer Spezifikation wird entwickelt, und getestet. D.h., daß die Qualität unmittelbar festgelegt wird. Da sich Leistungsbestandteile noch während der Entwicklungszeit ändern können, sollten Sie darauf achten, daß Sie die Spezifikation aktuell halten.

Weiterführende Informationen

… auf www.Produkt-Manager.net

In den folgenden Artikeln finden Sie weiterführende Informationen zum heutigen Thema:

• → Anforderungen müssen konkret formuliert werden
• → Bewertung von Neuproduktideen
• → Technical Debt, and Test Categorization

Kontakt

Das Original dieses Artikels ist auf →Der Produktmanager erschienen (©Andreas Rudolph). Regelmäßige Artikel gibt es über die (→Mailingliste), oder indem Sie →mir auf Twitter folgen. In der Online Version finden Sie hier die versprochenen weiterführenden Links:

This entry was posted on Mittwoch, November 17th, 2010 at 7:54 pm. It is filed under Agile&Scrum, Thema des Tages and tagged with Anforderungen, Rollin. You can follow any responses to this entry through the RSS 2.0 feed.