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.

Six Sigma für Software - welche Bestandteile gibt es

Wie im letzten Blog-Eintrag beschrieben, bietet Six Sigma für Software ein Toolset, mit dem verschiedene Prozesse der Softwareentwicklung unterstützt werden können. Folgende Toolsets sind dies:

• Kundenorientierung
• Prozessorientierung
• Steuerung mit Metriken

Welche Bestandteile beinhaltet das Toolset für die Kundenorientierung:

• Das Kano–Modell zur Bestimmung der Mindestanforderungen an die Software
• Die Ermittlung der kritischen Kundenanforderungen mittels Critical to Quality (CTQ)
• Die Methode Voice of the Customer (VoC) zur Ermittlung der Prioritäten aus Kundensicht
• Quality Function Deployment (QFD)
• Methoden für das Benchmarking (Vergleich mit Konkurrenten)
• FMEA (Fehler Möglichkeits- und Einfluss- Analyse) ist eine Methode zur Vermeidung von Problemen, in dem Lösungen für solche Probleme schon vorab bedacht werden

Diese Tools von Six Sigma konzentrieren sich auf das Qualitätsmanagement in den frühen Phasen der Softwareentwicklung.



Das zweite Toolset unterstützt die Prozessoriertierung:

• Prozessbeschreibungen (Flussdiagramme), wobei fraglich ist, ob diese benötigt werden, wenn umfangreiche Modellierung stattfindet
• SIPOC (Prozessanalyse: Supplier – Input – Prozess – Output – Customer) Auch hier ist die Frage, ob dieses Tool benötigt wird, wenn intensive Modellierung stattfindet. Es ist jedoch eine interessante Methode zur Betrachtung von Prozessen
• DMAIC ist der klassische Verbesserungsprozess im Six Sigma (Define-Measure-Analyse-Improve-Control)

Das dritte Toolset dient der Steuerung durch Metriken:

• Six Steps to Completion (Projektmanagement - Methode) Eine interessante Vorgehensweise, bei der "fertig" erst dann wirklich "fertig" ist, wenn alle Aktivitäten abgeschlossen sind (und nicht der "Code für den Tester über den Zaun geworfen wird")
• Function Point (Aufwandsmessungen zur Schätzung der Projektdauer)
• Fehlerstatistiken (Steuerung über offene Punkte, ToDo's)
• Histogramme
• Paretodiagramme
• Weitere statistische Methoden

Alle Tools (oder Methoden) bieten interessante Ansätze, die in die Entwicklungsprozesse integrierbar sind. Hat man jedoch ein Entwicklungsvorgehen (z. B. nach CMMI) auf einem hohen Level im Unternehmen implementiert, bringt der Einsatz dieser Methoden nicht zwingend weitere Verbesserungen. Es lohnt sich jedoch, die Methoden einmal anzusehen.

Wenn beim Kunden ein Softwarefehler auftritt

Fehlerfreie Software ist ja eine Utopie. Trotz intensivster Qualitätssicherung ist eine Software-Auslieferung ohne leichtere oder sogar schwere Fehler ist nicht möglich. Nicht jeder Fehler in der Software muss beim Kunden auch auftreten. Ist dies jedoch der Fall, zeigt sich im Umgang mit dem Problem, was einem die Kunden wert sind. Ein sehr auffälliges, und aus meiner Sicht auch positives Beispiel, habe ich heute bei twitter.com entdeckt. 
Der Anbieter my6sense hatte einen Fehler in seiner Applikation. Erwarten würde man, dass der Fehler bereinigt wird und anschließend die Kunden, wenn dies möglich ist, direkt darüber informiert werden. Das Unternehmen hat sich jedoch entschlossen, sehr aktiv auf die Kunden zu zugehen, und das Problem über twitter kommuniziert.

A very positive and impressive way of customer support

Diese sehr offene Art führt dazu, dass viel mehr User, als die von dem Problem betroffenen, das Problem mitbekommen. Trotzdem hatte sich der Anbieter dafür entschieden. Einige Zeit später hatte der Anbieter das Problem behoben und auch in diesem Fall wieder alle twitter-follower informiert. 

the problem is solved

Der offene Umgang mit dem eigenen Fehler und die Kommunikation sorgen dafür, dass der Kunde trotz des Fehlers weiterhin Vertrauen in seinen Anbieter hat (solange der Fehler nicht zum Regelfall wird) und damit auch als Kunde langfristig erhalten bleibt.
Ich finde, dass dies ein Beispiel sehr guter Betreuungs-Qualität ist. Thanks to my6sense.

Erwartungen an die Qualität neuer Software am Beispiel von Google Latitude

Google hat mit Latitude (in der mobile App Google Maps 5.1) eine neue Version der Software veröffentlicht, die auf den verstärkten Wettbewerb des "lokalen Internet" reagiert. Damit sollen die Wettbewerber Foursquare und Facebook local und einige kleinere Wettbewerber angegriffen werden.

Welche Erwartungen hat man als Nutzer an so eine Software?

1. Die Software bietet komplett neue Features, die noch kein Wettbewerber hat,
   oder Features mit mehr Detailfunktionen
2. Die Qualität Funktionen und/oder der Daten ist höher

Neben dieser Erwartungen stellt sich generell der Anspruch: "Reagiert ein Wettbewerber auf ein am Markt bestehendes Angebot, muss die Qualität seines neuen Angebotes sehr hoch sein". Warum sollte ich sonst wohl wechseln? Ich will mich doch nicht mit neuen Softwareproblemen herumschlagen. Das mache ich nur, wenn die neue Funktionalität deutlich über das bestehende Angebot hinausgeht.

Analysieren wir die einzelnen Punkte:
Latitude bringt mit der Funktion des automatischen Check-In und automatischen Check-Out neue Funktionen, über die die Wettbewerber so nicht verfügen. Der Check-Out funktioniert einwandfrei. Hat man sich für einige Minuten, von eingecheckten Ort entfernt, erfolgt ein automatischer Check-Out.
Der Check-In funktioniert ebenfalls. Die Zuverlässigkeit hängt jedoch von verschiedenen Faktoren ab. Länge des Aufenthalts am einzucheckenden Ort. Genauigkeit der ermittelten Position (mittels GPS und WLAN), was in Großstädten mit hohen Gebäuden nicht so einfach ist. Vielfalt der Check-Ins im näheren Umkreis (z. B. Center mit vielen Geschäften).

automatischer Check-In

Informationen zum Check-In

Wie bei anderen Anbietern des "lokalen Internet" gibt es Abstufungen, wenn ein Ort mehrmals besucht wird. Das reicht von "Besucher" über "Stammgast" zu weiteren Bezeichnungen, wenn der Check-In an einem Ort öfter durchgeführt wird (automatisch oder manuell). Diese haben bei Latitude damit eher einen realen Bezug, als bei anderen Anbietern ("Bürgermeister", "Champion" etc.).

manueller Check-In

Ebenfalls von guter Qualität sind die angebotenen Dialoge. Übersichtlich, klar zu verstehen und leicht zu bedienen.

Es existiert ein Dialog für Datenschutz-Einstellungen. Dieser ist ebenfalls einfach zu bedienen und in der Grundeinstellung sind alle Daten geschützt und automatische Check-Ins nicht aktiv, da zuerst Check-In Orte hinzugeführt werden müssen.

Hier macht es den Eindruck, das Google beim Thema Datenschutz dazugelernt hat.

Datenschutzeinstellungen

Insgesamt bietet die App eine gute Qualität, gute Bearbeitungsfunktionen, einen guten Datenschutz und Features, die sicher bei anderen Anbietern noch zum Standard werden. Durch die vielen Places, die in Google Maps schon existieren, gibt es auch bei den automatischen Vorschlägen für Check-Ins viele gute Angebote.
Wenn man das "lokale Internet" nutzen möchte, ist Latitude sicher eine gute Alternative, die es lohnt, dass man sie einmal ausprobiert.