Tactic-based Testing

Neben den Vorträgen am ASQF Testing and Safety Day hatten auch einige Firmen die Möglichkeit mit einer Ausstellung für ihre Dienstleistung zu werben. An einem Stand bin ich über den Begriff Tactic-based Testing (taktikbasiertes Testen) gestolpert. Der Begriff ist auch (bisher) kein offizieller Begriff im Umfeld des Softwaretests (kein Eintrag beim ISTQB-Glossar).
In vielen Unternehmen, die Software entwicklen, um damit Hardware zu steuern (Geldautomaten, Handys, medizinische Geräte, etc.) wird heute schon mit modellbasiertem Testen gearbeitet. Diese Testmodelle haben den Vorteil, dass alle Testfälle von der Software generiert werden. Teilweise (je nach Fähigkeit des Werkzeuges oder Optimierung der Werkzeugkette) können diese Testfälle auch automatisch ausgeführt werden.
Bei einfachen Fällen, wie dem Blinker am Fahrzeug (Zustände: Blinker aus, Blinker rechts, Blinker links, Warnblinken und wenig Zustandsübergänge) können die Testfälle auch vollständig ausgeführt werden. Bei komplexeren Systemen ist die vollständige Testausführung nicht immer möglich. In diesem Fall kann man der Software für das Testmodell eine Tactic (z. B. aus Zustandsdiagrammen) vorgeben. Die Testfälle werden anhand dieser Vorgaben generiert.

Systemtest im agilen Entwicklungsprozess - Vortrag ASQF Testing Day

Einen interessanten Vortrag auf dem Testing Day hielt Dr. Hehn von Methodpark zum Thema Systemtest im agilen Entwicklungsprozess. Als Diskussionsgrundlage, mit Bezug zu einem realen Projekt, wurde die agile Methode SCRUM heangezogen (Wikipedia: Scrum).
Der Systemtest in agilen Projekten fristet immer noch ein stiefmütterliches Dasein. Wird er erst ganz zum Ende des Projektes durchgeführt, kann dies natürlich viel zu spät sein (man kann die Erkenntnisse nicht mehr in der Software berücksichtigen - z. B. Performanceprobleme). Also ist es eine Notwendigkeit, schon früher im Softwareprojekt den Systemtest zu berücksichtigen.

Folgende Thesen bzw. Anregungen enthielt der Vortrag:

• Schon im ersten Sprint werden für den Systemtest Testkonzepte erstellt.
• Da in jedem Sprint (ab Sprint 2) auch Systemtests durchgeführt werden, werden diese idealerweise automatisiert (Skripte erstellen ab Sprint 1).
• Der Systemtest wird im Prinzip der Legobausteine entwickelt. In jedem Sprint wird der Systemtest mit neuen Bausteinen erweitert (er wächst also mit).
• Die Ausführung des Systemtests findet im Folgesprint statt.
• Idealerweise entwickelt ein "Systemtest-Team" parallel zur Implementierung den Systemtest (vor allem die automatisierten Bestandteile)
• Der Anteil der automatisierten Tests sollte idealerweise 60% betragen. 30% wären ein Minimum.

Damit sieht die Vorgehensweise so aus:

Ansatz: Systemtest im agilen Entwicklungsprozess

Leider bestand nach dem Vortrag keine Gelegenheit mehr mit dem Referenten zu diskutieren. Deshalb ein paar Gedanken und Fragen an dieser Stelle:

• Prinzipiell erst mal ein guter Ansatz, der den Systemtest im agilen Projekt verankert. Und mit den Testaktivitäten sollte von Anfang begonnen werden.
• Stört ein separates "Systemtest-Team" nicht den Ansatz der agilen Projekte? Alle Teammitglieder sollten doch "voll integriert" sein. Sind die Systemtester dann nicht Störfaktoren im Daily Scrum?
  Ich meine schon. Der Systemtest sollte durch ein Mitglied des Scrum-Teams wahrgenommen werden.
• Warum schon zu Beginn der Entwicklung den hohen Aufwand der Automatisierung tragen? Die erstellten Bauteile unterliegen vermutlich noch vielen Änderungen. Deshalb müssen die bereits erstellten automatisierten Tests permanent angepasst werden. Wer will diesen Aufwand (Kosten) schon tragen?
  Testautomatisierung ja. Aber zu einem späteren Zeitpunkt, oder?
• Warum den Systemtest erst im Folgesprint duchführen? Es wird weiterentwickelt, auch wenn der Test große Probleme offenbaren würde. Die Entwicklung würde z. B. erst in Sprint 3 auf die Probleme aus Sprint 1 reagieren.
  Damit: am Ende des Sprints den Systemtest durchführen.

Lebenslanges Lernen - Keynote ASQF Testing DAY

Am 19.04.2011 fand in Nürnberg der Testing und Safety DAY des ASQF (http://www.asqf.de/) statt. Neben den zwei Tracks (5 Vorträge jeweils zu den Themen Test und Safety) gab es eine gemeinsame Keynote von Prof. Dr. Jürgen Mottok von der Hochschule Regensburg Lebenslanges Lernen im Spannungsfeld von Agilität und Disziplin.

Nachfolgend einige seiner Botschaften:

• Von den drei wichtigen Lernansätzen ist der Konstruktivismus der erfolgsversprechende.
  Das bedeutet: "Wissen entsteht nur auf der Grundlage eigener Erfahrung."
• Wissen kann nicht vom Lehrer auf den Lernenden übertragen werden.
• Jeder gestaltet sein Lernprozess selber. Dieser entwicklet sich individuell.
• Wissen entsteht nur durch Handeln.
• Menschliche Interaktion ist wichtiger als umfangreiche Dokumentation.
  (Bestätigung eines Leitsatzes aus dem agilen Manifest)
• Ein vielversprechender Lernansatz ist das Gruppen Puzzle. Eine Beschreibung und weitere interessante Methoden findet man unter http://www.methodenpool.uni-koeln.de/
• Wer unter Angst lernt, lernt die Angst (Hinweis auf Manfred Spitzer)
• Werte unterstützen das Lernen und die Leistung. Werte sollten im Team gemeinsam definiert werden.
• Die Software Factory ist ein Irrglaube.
• Zum Lernen braucht man ein gewisses Spannungsumfeld
• Um die Retrospektive (Bestandteil Scrum) effizienter zu gestalten, hat er in seinen Projekten gute Erfahrungen mit persönlichen Lernlogbüchern (jedes Mitglied des Entwicklungsteams führt eines) gemacht.

Ich hatte zu einem späteren Zeitpunkt noch die Möglichkeit mit ihm ein paar Punkte persönlich zu diskutieren:
Durch Folien oder bei gesprochenem Wort nimmt der Empfänger der Botschaften nur ca. 20% auf. Durch eigenes und gecoachtes Handeln kommt man zu einer Wissens-Erwerbsqoute von ca. 80%.
Damit findet der sogenannte Know-how Transfer oft nicht statt. Denn dazu müsste der Lehrende intensiv den Lernenden coachen (man beachte was dies für die Übergabe von Aufgaben bei einem Mitarbeiterwechsel bedeutet).
Bei diesen Annahmen stellte ich in Frage, wie große Unternehmen mit permanenter Fluktuation einen CMMI Level 5 erreichen und dauerhaft sichern wollen, worauf ich die Antwort bekam, das hinter den indischen Unternehmen mit CMMI Level 5 schon ein großes Fragezeichen zu machen ist...

Gedanken zur diesen Botschaften:
- Checklisten mit Aufagen- und Prozessbeschreibungen sind zwar gut, aber...
- Mitarbeiter entwickeln durch selbst durchgeführte Testaktivitäten zum guten Tester/Testmanager (die Theorie ist Beiwerk)

Kano-Modell - Bewertung von Kundenanforderungen

Das Kano-Modell ist ein einfaches Modell zur Bewertung von Kundenanforderungen. Entwickelt hat dies Dr. Kano an der Universität von Tokio. Dabei werden die Anforderungen an ein Produkt in drei Hauptkategorien eingeteilt:

1. Basisfunktionen
2. Leistungsfunktionen
3. Begeisterungsfunktionen

Das Modell geht davon aus, das die Kundenzufriedenheit umso höher ist, je mehr Leistungs- und Begeisterungsfunktionen ein Produkt (eine Software) enthält. Unterschreitet ein Produkt eine gewisse Anzahl an Basisfunktionen sind die Nutzer unzufrieden, was letztlich dazu führt, dass ein Produkt nicht genutzt wird.

Das Modell eignet sich auch dafür, Märkte zu analysieren. Dazu vergleicht man z. B. die Produkte verschiedener Anbieter und klassifiziert die Funktionen nach dem Schema des Kano-Modells.

Als Beispiel nachfolgend eine kleine Analyse der Funktionen von Smartphone-Apps zu den sogenannten Location-based Services wie Foursquare, Google Maps mobile (mit den Funktionen Places/Latitude/Hotpot), Qype, Gowalla, Facebook Places etc. :

1. Basisfunktionen
1. Zeige interessante Orte in der Nähe
2. Zeige eine bestimmte Kategorie von Orten (Restaurants, Apotheken, Kirchen, Fahrradhändler etc.)
3. Zeige Bewertungen anderer Besucher dieser Orte (auch wenn solche Bewertungen mit Vorsicht zu genießen sind, dienen sie doch als Anhaltspunkte)
4. Zeige mir nur Orte mit einer gewissen Mindestbewertung
5. Eine große Anzahl von Orten/Places (wenn mir in einer Stadt das nächste Cafe in 10 km Entfernung angezeigt wird, hat der Service sicher auch keinen allzu hohen Wert)
6. Eine hohe Datenqualität (wenn die Telefonnummer der ausgewählten Apotheke falsch ist, ist der Nutzen ebenfalls gering)
2. Leistungsfunktionen
1. Was ist mein aktueller Standort? Wo bin ich?
2. Sind Freunde an dem gefundenen/gewählten Ort?
3. Wo sind meine Freunde?
4. Wie haben meine Freunde einen Ort bewertet?
5. Ich möchte an dem Ort einchecken
6. Ich möchte an einem Check-In auch auschecken können
7. Ich möchte für alle personenbezogenen Informationen übersichtliche und einfache Datenschutz-Einstellungen haben
8. Automatische Ortsbezogene Angebote (ich bin gerne im Cafe, also bekomme ich einen Hinweis vom Smartphone wenn ich in der Nähe eines gut bewerteten Cafes bin)
3. Begeisterungsfunktionen
1. Automatischer Check-In für Orte, bei denen ich dies wünsche (wo ich oft und gerne bin und dies anderen mitteilen möchte)
2. Check-In für "Zuhause" ohne einen Ort/Place im System anzulegen (wenn das jeder macht entsteht eine Menge "Placemüll")
3. Automatischer Check-Out, wenn ich mich von meinem Check-In entfernt habe (nach einigen Minuten zum Beispiel)
4. Rabatte für einen Check-In

An Hand dieser kleinen Analyse ist schon zu erkennen, dass die Einordnung in die verschiedenen Kategorien nicht so einfach ist. Ist die Bewertung des Ortes Basisfunktion oder Leistungsfunktion? Sind die personenbezogenen Informationen (basierend auf Daten aus meinem Social Network) Leistungsfunktionen oder doch Basisfunktionen? Bei Punkt 1.4. bin ich mir auch unsicher, ob dies nicht schon eine Leistungsfunktion ist. Sicherlich erhält man aus Sicht verschiedener Kunden/Personen auch verschiedene Eingruppierungen (zur Sicherheit kann man die Six Sigma Methode Voice of the Customer verwenden ).

Verblüffend ist, dass es bisher kaum Apps gibt, bei denen man sich auschecken (2.6.) kann, egal ob manuell oder automatisch. Ich halte dies für eine Leistungsfunktion (wer will schon zwei Tage später eine SMS für ein Treffen an einem Ort erhalten, an dem man sich schon lange nicht mehr aufhält). Eine solche fehlende Funktion wird im Kano-Modell auch als Rückweisungs-Merkmal bezeichnet. Bei mir hat diese Nichterfüllung dazu geführt, dass ich bestimmte Apps nicht mehr nutze (diese Deinstallation ist auch das Schlechteste was einem Anbieter passieren kann - weil der Kunde so schnell die App nicht wieder installiert).

Die unerheblichen Merkmale
Diese Produktmerkmale sind für den Kunden nicht von besonderer Bedeutung. Weder im Positiven wie im Negativen. In unserer App-Analyse sind das Funktionen wie die Badges in Foursquare (aus meiner Sicht eher Spielerei). Sollte dies den Kunden aber zu sehr nerven, können sich solche Funktionen zu Rückweisungs-Merkmalen entwickeln.
Im Schaubild des Modells habe ich die unerheblichen und Rückweisungs-Merkmale zwecks Vereinfachung nicht aufgeführt.

Was wird in Zukunft aus den Begeisterungsfunktionen?

Haben sich die Kunden erst einmal an die Begeisterungsfunktionen gewöhnt, werde diese schnell zu Leistungsfunktionen. Der Kunde will nicht mehr darauf verzichten und erwartet, dass diese vorhanden sind. Versuche ich permanent mit Begeisterungsfunktionen neue Kunden zu gewinnen, vielleicht sogar von der Konkurrenz, werden solche Innovationen regelmäßig erwartet. Sonst droht wieder die Abwanderung der Kunden. Aber dem Anspruch der permanenten, hohen Innovation gerecht zu werden, dürfte auf die Dauer auch sehr schwierig werden. Dies gilt aus meiner Sicht vor allem für Funktionen wie die Rabatte. Und natürlich können auch Leistungsfunktionen irgendwann vom Kunde als Basisfunktionen betrachtet werden.