Fazit zum German Testing Day 2011

Nach ca. zwei Wochen nun das Fazit zum German Testing Day. Eine mögliche Tagungseuphorie bzw. Tagungsdepression ist nun verflogen. Rückblickend sieht man das Ganze etwas nüchterner.

Die beiden Keynotes haben die Teilnahme gelohnt. Wie es sich für Keynotes gehört, wurde über den Tellerrand hinaus geschaut. Gunter Dueck hat in der Abschlussveranstaltung in eindrucksvoller Weise (rhetorisch erstklassig mit vielen plastischen Beispielen) das Thema der Industrialisierung der Dienstleistungen aufgegriffen. So etwas zu hören, regt auf jeden Fall zum Nachdenken an. Die Lachmuskeln wurden auch intensiv in Gang gesetzt :-)

Die Vorträge, die wir besucht haben, waren überwiegend gut bis sehr gut, sowohl fachlich, als auch was die Präsentationen selber angeht. Da waren gute Anregungen dabei, die zum Ansehen, Einarbeiten und selber Ausprobieren der Themen einladen. Fachlich konnte man auf jeden Fall etwas aus den Veranstaltungen mitnehmen.

Auch die Lightnings Talks konnten gefallen. Einzig die Zeitgestaltung am Nachmittag sollte nochmal überdacht werden. Lieber zwei als drei Vorträge und dafür die beiden Vorträge etwas länger. Aber das unsere Meinung - in den Fragebögen kommt vielleicht etwas Anderes heraus.

An der Organisation gab es Nichts auszusetzen. Das Einchecken, die Verpflegung, Trackauswahl und- vielfalt, Informationen für die Teilnehmer und sonstige Organisation waren einwandfrei. Die Vortragsvisualisierung ist sicher eine spannende Idee, wobei jeder je nach Wissensstand andere Schwerpunkte aus einem Vortrag mitnimmt (deshalb findet man sich in der Visualisierung nicht unbedingt so wieder). Und die Räumlichkeiten mit der Integration der Sponsoren haben ebenfalls gepasst.

Und damit die entscheidende Frage: Würden wir wieder einen German Testing Day besuchen?
Ja - es war eine gelungene Veranstaltung.

Alex und Frank

Vortrag "Das Softwareleitstand-Prinzip" auf dem German Testing Day

Der "Softwareleitstand" ermöglicht es, ständig einen aktuellen Status zum Zustand der Software zu bekommen. Dazu werden verschiedene Indikatoren herangezogen, die die Firma Qaware in drei Ebenen gliedert, wie der Referent M. Ciolkowski erläuterte.

Erste Ebene bilden die Qualitätskontrakte (ca. Sieben - wird bei Bedarf auf die aktuelle Situation angepasst). Unter anderem sind dies

• Unit-Test Abdeckung
• Code Coverage
• Code Anomalien

Diese werden bei der Build-Erstellung automatisch generiert.

Die zweite Ebene bildet das Software-Blutbild:

• Analysen der Untersuchungsergebnisse vom System durch einen Experten
• Auch hier hat Qaware feste Vorgaben definiert

Die dritte Ebene bildet die freie Analyse. Hier werden aus Daten aus dynamischen und statischen Tests  herangezogen, um Prognosen Verläufe und Trends sichtbar zu machen (z. B. Fehlerhäufungen in Modulen, Verlauf der Testabdeckung bei Regressionstests).

Noch ein paar Statements des Referenten

• Continous Integration erfordert genauso oft eine Erstellung der Analysedaten für den Leitstand
• Vermeide Qualitätsschulden (Kleinigkeiten die versäumt wurden und sich zu Problembergen anhäufen)
• keine zerbrochenen Fensterscheiben akzeptieren (ist die SW an einer Stelle schlecht, wird sie insgesamt noch schlechter)
• Qaware arbeitet mit Landkarten, um die Qualität zu visualisieren

Die Lösung ist mit OpenSource Software umgesetzt. Zum issue tracking wird Jira verwendet. Die Build Statistiken (u. a. wie wächst der Code) werden mit radiator erstellt. Diese Daten fließen dann zentral in sonar ein, dass als zentrales Werkzeug für den Leitstand dient.
Insgesamt ein sehr interessanter Vortrag, in dem es dem Referenten gut gelungen ist, mit Bildern und Metaphern den Teilnehmern ein Verständnis für den "Softwareleitstand" zu vermitteln.

Trends auf dem German Testing Day 2011

Natürlich muss man sich die Frage stellen, ob sich auf einer Eintagesveranstaltung mit begrenzter Anzahl an Vorträgen allgemeingültige Trends für eine ganze Branche ableiten lassen. Da kann man ganz schön daneben liegen. Ich möchte es dennoch versuchen.

Trend 1 - Weitere Professionalisierung des Softwaretests
Alleine, dass es eine weitere Veranstaltung neben den bereits etablierten Verstaltungen rund um den Softwaretest gibt, zeigt dass das Thema immer weiter professionalisiert wird. Das Interesse an den Methoden
Prozessen zur Erstellung guter Software wächst weiterhin. Aber es ist ja auch noch viel zu tun in dieser Richtung ...

Trend 2 - Visualisierung der Qualität
Immer mehr Unternehmen setzen Visualisierungen (Beispiele unter http://software-cities.org/) zur Darstellung der SW-Qualität ein. Ziel ist einfach Transparenz über den aktuellen Entwicklungsstand zu schaffen. Dabei kommen Daten zur Auswertung, die direkt aus dem Build-Prozess erzeugt werden können.

• Wie viele Änderungen am Code/Modul
• Wie viele Personen arbeiten an einem Modul / bestimmten Codeteilen
• Wie entwickelt sich der Code bezüglich Größe, Komplexität, Schnittstellen, etc.
• Fehlerhäufigkeiten in Modulen
• ...

Trend 3 - Einsatz Open Source
Ich war schon überrascht, wieviele unterschiedliche Werkzeuge zum Einsatz kommen und dass so viele Schnitsttellen exitieren. Das ist ein guter Gegensatz zur ebenfalls verbreiteten Ansicht, dass möglichst Alles in den TFS von Microsoft reingesteckt werden soll, auch wenn die Möglichkeiten zur Auswertung und Analyse im TFS dann nicht so toll sind. Es lohnt sich Open Source Programme genau anzusehen...

Stand des Software-Testens in der Praxis

Im Mai 2011 lief eine grpße Umfrage zum Softwaretest in der Praxis. Prof. Dr. Mario Winter von der FH Köln präsentierte aus der Umfrage einige Ergebnisse.

Einige interessante Ergebnisse, die - so weit ich das im Überblick habe - nicht in den Grafiken auf der offiziellen Web-Seite www.softwaretest-umfrage.de zu sehen sind.

• Die QS wird weitgehend in den späten Phasen der Software-Entwicklung durchgeführt. Es gibt zwar schon Verschiebungen in frühere Phasen (z. B. Reviews zu Fachkonzepten). Allgemein gibt es jedoch Nachholbedarf, was die Testaktivitäten zu früheren Phasen angeht.
• Der Einsatz der Testautomatisierung in agilen Vorgehensweisen ist nicht ausreichend. Auch besteht Nachholbedarf
• Die Befragten gaben an, dass nur ca. 20% des Budgets in die QS läuft. Dies widerspricht bisherigen Erfahrungen (40% oder mehr).

Was ich Dr. Winter im Gespräch noch mitgegeben habe:

• Wenn man die 110 Fragen ausfüllt, wäre es in Zukunft schön, wenn man hinterher eine Dokumentation erhält, was man selber angegeben hat. Gerade in großen Unternehmen kommen verschiedenste Techniken und Modelle zum Einsatz. Man könnte dann besser die Ergebnisse mit eigenen Angaben vergleichen.
• Die Fragen könnten doch wieder Online gestellt werden. Denn allein die Beantwortung der Fragen regt zum Nachdenken über die eigene Vorgehensweise an. So kann ein Selbst-Verbesserungsprozess angestoßen werden.

Auf jeden Fall bin ich auf weitere Auswertungen gespannt. Es sollen ja noch welche Folgen...

Lightning Talks am German Testing Day 2011

Erstmalig habe ich auf einer Veranstaltung die sogenannten Lightning Talks gesehen. Dabei haben die Referenten genau 5 Minuten Zeit, um den Zuschauern ihr Thema zu präsentieren. Das können natürlich nur Appetit-Häppchen

sein. Aber gut gemacht, können Sie in ein Thema einführen und die Teilnehmer dazu animieren, sich später genauer darüber zu informieren.

Ein aus meiner Sicht besonders gelungener Kurzvortrag kam von Dr. Trapp vom Fraunhofer IESE zum Thema Usability. Mit tollen plakativen Bildern führte er den Zuschauern vor, was Usability sein kann und was sie nicht ist (Nutzer macht die Qualität der Anwendung an der Oberfläche fest)

Sofort wurde klar, wie wichtig es ist, den Kunden frühzeitig in Entwicklungsprozesse einzubinden und einen starken  Fokus auf die Gestaltung des Produktes zu legen. Ein sehr guter Appetit-Happen.

Bei den weiteren Beiträgen merkte man, dass es sehr schwierig ist, "Web Application Security Testing" und "Performance-Moddelierung von IT-Systemen" in nur fünf Minuten an den Mann zu bringen. Diese sehr technischen Themen sind nicht so leicht verdaulich. Aber auch hier wurde deutlich, das die Themen für das Testing eine erhebliche Relevanz haben.

Als Vortragsmethode eine spannende Variante für eine Konferenz. Da auf den Folien Texte erlaubt sind, unterscheidet es sich doch schon stark von Pecha Kucha. Gefühlt sind bei dieser Vortragform weniger Worte auf den Folien mehr...

Keynote von Alan Page am German Testing Day

Die erste Keynote auf dem German testing Day (www.germantestingday.info) hielt Alan Page von Microsoft zum Thema "Test-Innovation". In einer für einen Amerikaner typischen, lockeren und unterhaltsamen Vortragsweise brachte er den Zuschauer seine Gedanken zum Thema "Test-Innovation" nahe.

Die Eingangsfrage "What shall I innovate today?" zeigte schon, wie Innovationsprozesses ablaufen. Nicht bis ins Detail planbar, sondern eher beiläufig und aus bestimmten Motiven heraus (oft ist die Motivation die, sich seine Arbeit zu erleichtern).

Innovationen kommen zustande, weil wir einen besseren Weg finden wollen. Aus seiner Sicht tragen dazu bei:

• transformational change
• incremental change
• simplification
• connecting ideas

Welche Innovationen setzt Microsoft im Rahmen der Qualitätssicherung ein:

• Virtualisierung von Testplattformen (seit vielen Jahren) 
• model based testing seit über 10 Jahren 
• Test requirements werden aus der Spezifikation generiert
• Riskobasiertes Testen - redundante Tests aufgeben
• Testmethoden werden auf jedes Projekt individuell angepasst
• Spezielle Frameworks zur Dokumentation von Fehlersituationen (z. B. für Spiele  für die Xbox)
• coverage maps, heat maps (Intgeressante Visualisierungen zur Software-Architektur und den Build-Daten). Einen Vortrag zu dem Thema gab es auf der #iqnite11 (siehe Blogbeitrag)
• crowed sourcing in den Tests

Ein kurzweiliger und interessanter Vortrag von Alan Page. Links zum Autor twitter.com/alanpage  und angryweasel.com

CMMI Überblick als Tabelle

Die einzelnen Prozessgebiete im CMMI sind nicht nur den Levels 1-5 zugeordnet (siehe auch Blog-Beitrag zu den Levels). Es gibt auch eine Zuordnung zu Kategorien. Vier Kategorien sind es in der CMMI Version 1.3:

• Entwicklung
• Prozessmanagement
• Projektmanagement
• Unterstützung

Zu diesen Kategorien sind 22 Prozessgebiete zugeordnet. Welche dies sind, zu welcher Kategorie das jeweilige Prozessgebiet gehört und zu welchem Level kann in folgender Google Docs Tabelle nachgelesen werden:
Spreadsheet

Kritische Testfälle im Softwaretest - Beispiel Login

Immer wieder liest man von Fällen, dass der E-Mail Zugang oder auch andere Login-Mechanismen nicht korrekt funktionieren. Dies sind extrem kritische Fälle. Wenn eine Übersicht oder eine Auswertung nicht korrekt angezeigt wird, so ist das für den Anwender sehr unschön (manchmal auch kritisch), aber der Zugang zu einem Cloud-Dienst ist ein sehr wichtiger Testfall. Nachfolgend ein paar Beispiele, in denen die Softwaretests nicht ausreichend waren:

1. Dropbox (Cloud-Dienst zur Ablage von Dateien/Dokumenten) akzeptierte vier Stunden lang beliebige PasswörterHeise Online Artikel (21.06.2011)
2. Amazon erlaubt das Login bei älteren Accounts mit fehlerhaften Passworten
   Blog-Artikel auf Netzgezwitscher (27.01.2011)
3. Facebook erlaubt die Veränderung der Passworte von Hotmail-Usern
   Blog-Artikel auf Datenschutzberatung.org (21.04.2011)
4. Im Fantasy-MMO Rift gab es eine Sicherheitslücke im Login
   Blog-Artikel auf buffed.de (Spieleportal)

Allen diesen Fällen ist gemeinsam, dass dies nicht in der ersten Version der Software aufgetreten ist. In diesem Fall waren die Tests wohl ausreichend. Immer sind die Fehler aufgetreten, nachdem Änderungen oder Erweiterungen an der Software durchgeführt wurden. Das lässt folgende Rückschlüsse zu:

1. Kein ausreichendes Testfallmanagement
   Es müsste klar sein, welche Testfälle nach Änderung der Software auszuführend sind
2. Keine Traceability
   Durch die Organisation der Anforderungen an die Software, müsste der Bezug zwischen Anforderung und den auszuführenden Testfällen vorhanden sein.
3. Kein risikobasiertes Testen
   Wenn bewertet wird, welche Tests nach Änderung durchzuführen sind, komme ich wegen des hohen Risikos des Login-Zugangs darauf, dort Tests durchzuführen

Dies zeigt, dass Schwächen im Testmanagement vorhanden sind. Solch kritische Probleme führen auch dazu, dass die Kunden überdenken, ob sie diesen Anbietern weiterhin ihr Vertrauen schenken. Ob man unternehmenskritische Daten bei so einem Dienst ablegt - wohl eher nicht. Und ob andere aus diesen Fällen lernen... Ich bin gespannt auf den nächsten Fall...

Überblick über CMMI 1.3

Unternehmen, die Software entwickeln, führen nicht nur umfangreiche Maßnahmen zum Softwaretest an sich durch, sondern versuchen die Prozesse der Softwareentwicklung zu optimieren. Zur Überprüfung der Vorgehensweise in der Entwicklung gibt es Reifegradmodelle wie CMMI oder SPICE, die beschreiben, welche Schritte/Aktivitäten im Entwicklungsprozess durchgeführt werden sollen. Im Jahr 2010 wurde die Version 1.3 von CMMI veröffentlicht. Diese enthält einige Veränderungen gegenüber der Version 1.2. Die nachfolgende Grafik stellt die fünf Level von CMMI dar und zeigt auf, in welchen Prozessgebieten Aktivitäten anfallen, damit ein bestimmter Level erfüllt wird.



CMMI 1.3 for Development

Wie die Tätigkeiten im einzelnen aussehen und welche Tools zur Erfüllung der Aufgaben eingesetzt werden können, lässt das Reifegradmodell offen. Dies muss die Organisation selber festlegen.

Informationen im Web zum Softwaretest

Gute Zeiten für Menschen, die sich mit dem Thema Softwaretest beschäftigen. Immer mehr Webseiten beschäftigen sich auf professionelle Weise mit dem Softwaretest, dem Testmanagement und Verfahren der Qualitätssicherung. Einige Links habe ich im Blog in einer Linklist aufgenommen. Die wachsende Vielfalt spiegelt auch eine immer stärker werdende Professionalisierung der Disziplin Softwaretest wieder.


Es gibt auch ein paar Zeitschriften, die regelmäßig publiziert werden. Teilweise ist die Online-Version (PDF) sogar kostenlos.

• Testing Experience
  (sehr umfangreiche englischsprachige Zeitschrift, die zweimonatlich erscheint - Online kostenlos)
• Professional Tester
  (englischsprachige Zeitschrift, die zweimonatlich erscheint - Online kostenlos)
• SQ-Magazin vom ASQF
  (erscheint zweimonatlich in deutscher Sprache - zwei Exemplare kann man zur Probe bestellen)
• Testing Circus [Update]
  (englischsprachige Zeitschrift, die monatlich online erscheint)
• Online Magazin Software Testing Magazin [Update Juli 2012] 
  http://www.softwaretestingmagazine.com

Viel Spaß bei der Lektüre der vielen interessanten Artikel...

Wer noch interessante Links zum Thema kennt, die nehme ich gerne in die Linklist auf...

iqnite11 - Mein Fazit

Ich war dieses Jahr das erste Mal auf der iqnite (Link). Die Vielfalt des Vortrags-Angebotes war wirklich prima. Wir waren zu dritt auf der Konferenz, aber fast immer auf verschiedene Tracks verteilt. Es gab wenig Enttäuschungen und daher nach jeder Session viel zu diskutieren. Durch die vielen Vorträge zogen sich aus meiner Sicht folgende zwei Grundsätze:

• Der Kunde steht im Fokus - Konzentration auf seine Bedürfnisse ist angesagt
• Software nicht vergolden - die Business Prozesse der Kunden im Auge behalten

Persönlich fand ich den Track Testmanagement trifft Risikomanagement (Blog-Beitrag) sehr gut. Auch in den anderen Vorträgen/Tracks gab es gute Anregungen, die es nun gilt in die tägliche Arbeit zu übernehmen.

Zu der gelungenen Veranstaltung hat auch die Organisation der Konferenz viel beigetragen. Die Räumlichkeiten waren gut geeignet. Aussteller, Vortragsräume und der große Raum für die Keynotes waren dicht zusammen, was sehr angenehm war. Die Verpflegung und das Social Event, mit vielen Gesprächsmöglichkeiten, waren ebenfalls ausgezeichnet. Auch die Versuche die Teilnehmer stärker einzubinden, SMS-Voting und Open Space (Blog-Beitrag), konnten gefallen. 

Absolute Highlights waren die Keynotes. Allen Referenten ist es gelungen, interessante Ideen zu präsentieren und neue Perspektiven zu vermitteln. Allein die Keynote zur Visualisierung der statischen Projektinformationen (Blog-Beitrag) hätte den Besuch gelohnt.


Das Niveau der Veranstaltung war gut, so dass ich sicher nicht das letzte Mal auf der iqnite gewesen bin...

iqnite11 - Testmanagement trifft Risikomanagement

Einen hervorragenden Vortrag hielten die beiden Autoren Bernd Schindelasch und Claudia Gelhaus von der Telefongesellschaft EWE TEL GmbH. Beide stellten den Ansatz ihres Unternehmens zur Einführung eines Risikomanagements zur Steuerung von Produkt- und Projektrisiken vor.

Zu jedem Release wird ein QS-Plan erstellt, in dem alle Produkt- und Projektrisiken aufgeführt werden. Dazu wird neben FMEAs auch eine Risikomatrix genutzt, mit der alle Testfälle (strikte Ableitung aus den Anforderungen) bewertet werden. Nachfolgend sind einige Punkte (nicht vollständig) der Matrix

aufgezeigt:

1. Kritikalität des Geschäftsfalls
   (Auswirkung auf den Geschäftsprozess, betroffene Kunden, Anpassungshäufigkeit)
2. Fehler - Eintrittswahrscheinlichkeit
   (Veränderung des Geschäftsprozesses, Qualität der Konzepte, Häufigkeit Fehler in der Vergangenheit)
3. Komplexität der Anforderung
   (Bewertung anhand der Eingabedaten, Schnittstellen, des Prozesses)

Über die Matrix werden alle Testfälle bewertet, und eine Priorität für die Durchführung der Testfälle festgelegt. Dazu wird ein Werkzeug verwendet, mit dem alle Aufgaben des risikobasierten Testen durchgeführt werden. So hat der Testmanager jederzeit den Überblick über die Prioritäten, die Testdurchführung, den Testfortschritt und die Testergebnisse. Mit diesem Wissen können gute Entscheidungen ("data beats opinion") über den Auslieferungszeitpunkt, auch aufgrund der Testaufwandsplanung die mit dem Werkzeug durchgeführt wird, getroffen werden.

Zur Weiterentwicklung der Vorgehensweise werden TPI Assessments durchgeführt. Insgesamt ein sehr interessanter und schon reif wirkender Ansatz, den Test (und damit auch das Projekt) über ein Risikomanagement zu steuern.

iqnite11 - Keynote "Kann man Qualität sehen?"

Die sehr interessante Keynote mit dem Titel "Kann man Qualität sehen? - Softwarevisualisierungen für komplexe Kennzahlenzusammenhänge" hielt Dr. Claus Lewerntz von der BTU Cottbus.
In seiner Einleitung verwies er darauf, dass wir uns bei vielen Produkten schon vom Ansehen ein Urteil über das betrachtete Objekt bilden. Dabei genügen schon wenige Blicke, um die Qualität abzuschätzen.
Bei der Software ist dies jedoch nicht so einfach möglich. Wie können wir uns ein Gesamtbild von der Qualität eines Systems herstellen? Wie schaffen wir uns ein gemeinsames Bild?
Sein Ansatz besteht darin, die statische Struktur der Software mit einer Stadt-Metapher darzustellen. Aus den Entwicklungsdaten werden geometrische Modelle entwickelt, die dann in einem weiteren Schritt als thematische Landkarte dargestellt werden.
Das Alter, die Kopplung und die Größe der Komponenten werden als Stadt dargestellt (Gebäude, Straßen, Höhenzüge). So gelingt es sich ein Bild von den Zusammenhängen zu schaffen. Auch die Historie kann so nach verfolgt werden. Als Beispiel stellt er eine Landkarte "Testabdeckung" und eine Panoramakarte "Änderungsgeschichte" vor. Relativ schnell konnte man anhand seiner Schilderungen interessante Fragestellungen zum Gesamtsystem erkennen (so zum Beispiel: Wer hat wann an welcher Komponente eine Änderung vorgenommen). Auch Risikobetrachtungen (zum Besipiel: Wer hat dem Codefreeze noch Änderungen an einer Komponente vorgenommen) sind so relativ leicht möglich.
Unter www.software-cities.org finden sich einige Visualisierungen und weitere Informationen.

Ob sich dieser Ansatz durchsetzt, hängt sicher davon ab, ob es gelingt, die Qualität tatsächlich anhand dieser Darstellungen festzustellen. Dazu sind nach Aussage von Dr. Lewerentz noch weitere Erfahrungen notwendig.

Aus meiner Sicht ist dabei sicher auch die Frage entscheidend, ob die festgelegte Qualität aus der Interpretation der Visualisierung mit der tatsächlichen Qualität in der Praxis korreliert.

iqnite11 - Keynote "Softwareindustrie am Wendepunkt?"

Eine ausgezeichnete Keynote hielt Dr. Goerg Kraus von der Unternehmensberatung www.kraus-und-partner.de. Aus seiner Sicht ist die Softwareindustrie inzwischen eine Branche, in der der Reifegrad immer stärker wird. Nach seiner Ansicht, "Fachwissen wird in reifen Branchen einfach vorausgesetzt. Damit kann man nicht mehr punkten.", müssen die Unternehmen damit ihre Geschäftsmodelle überdenken.
Was sind die Kernkompetenzen? Wie groß ist die eigene Fertigungstiefe? Welche Tätigkeiten kann/muss ich auslagern?
Als Konsequenz der zunehmenden Reife hat er 8 Thesen formuliert:

1. Business-Modell schlägt Software-Produkt
   Facebook oder LinkedIn sind nicht wegen der Software (die ist wohl relativ einfach) erfolgreich, sondern wegen des Business-Modells dahinter
2. "Sustainability" schlägt den Preis
   IT ist das Rückgrat vieler Unternehmen. Die Anwendungen müssen laufen. Deshalb ist Zuverlässigkeit wichtig.
3. Kundennutzen/Problemlösung schlägt Anwendung
   Die Frage ist: "Wie hilft die Anwendung die unternehmerischen Frage zu lösen?". Die Software steht nicht im Mittelpunkt
4. Business-Kompetenz schlägt IT-Kompetenz
   Wichtig ist das Verständnis für das Geschäft und die Aufgaben des Kunden. "Gute Software entwickeln kann jeder".
5. Qualität schlägt "Speed"
   Die Lösung muss von Anfang an fehlerfrei funktionieren. Mit "Bananensoftware" kann man nicht gewinnen.
6. Preis schlägt Feature
   Was braucht der Kunde wirklich. Für "vergolden" will er nicht bezahlen.
7. Projektmanagement schlägt Organisation
   Im Zeitalter von Virtualisierung und firmenübergreifender Zusammenarbeit (auch über Landesgrenzen hinweg) ist das Projektmanagement absolut wichtig. Ohne eine gute Steuerung funktioniert es nicht.
8. Kultur schlägt Preis für Arbeit
   Unternehmen benötigen eine gezielte Kulturentwicklung (Spirit, Professionalität) in der eigenen Organisation. So können sie gegen Anbieter in den Ländern bestehen, in denen der Preis je Arbeitsstunde günstiger ist.

Spannende Thesen. Einige Thesen (1-4) würde ich sofort unterschreiben. Bei anderen bin ich mir nicht so sicher, wie zum Beispiel These 5. Ist im mobile computing derzeit Speed nicht wichtiger als Qualität - denn da hapert es bei vielen Apps und die Apps werden trotzdem oft heruntergeladen (Markt besetzt!?). 

Auf jeden Fall ein dickes Lob an den Referenten Dr. Kraus. Kein "weichgespülter" Vortrag, sondern Thesen die pro's und con's herausfordern.

iqnite11 - Open Space

Auf der iqnite 2011 in Düsseldorf gab es eine interessante Session mit der Bezeichnung Open Space. Dabei teilten sich die Teilnehmer in verschiedene Workshops auf, mit der Möglichkeit beliebig zwischen den Workshops zu wechseln. Die Themen wurden vor der Konferenz bereits eingereicht. Interessant war für mich der Workshop "Welchen Mehrwert bietet die Software-Industrialisierung".
Die entscheidende Frage dazu ist, was ist überhaupt "Software-Industrialisierung". Obwohl die iqnite11 dieses Konferenz-Motto hatte, war unklar, welche Rahmenbedingungen gegeben sein müssen, damit Industrialisierung (und im Speziellen in der Qualitätssicherung) vorherrscht.

Ein Teilnehmer formulierte "Wenn die  Entwicklungs-Prozesse (und damit auch der Testprozess) standardisiert sind, dann herrscht Industrialisierung vor".

Dazu kamen dann folgende Fragen auf:

• Benötigt dies Industrialisierung Testautomatisierung?
• Müssen Tools zum Einsatz kommen?
• Brauche ich Modellbased Development?
• Reicht der ISTQB-Standard aus?
  (Eher nein, weil nur die Grundlagen definiert sind)

In der Diskussion wurden auch einige Benefits einer Industrialisierung diskutiert. Schnell waren wir an dem Punkt angelangt, ob die eher einfachen und leicht zu reproduzierenden Tätigkeiten nicht in Unternehmen/Länder verlagert werden müssen, die diese dann kostengünstiger durchführen können (siehe starke Produktionsteilung z. B. in der Autoindustrie).
Hier herrschten geteilte Meinungen. Dies wird wahrscheinlich nur in  Unternehmen funktionieren, die eine sehr starke Standardisierung haben (Know-how beim Personal, Prozesse, Werkzeuge, etc.).






Auf jeden Fall eine spannende Vorgehensweise, die Teilnehmer aktiv an den Themen zu beteiligen, an denen sie Interesse haben.

Technical oriented Testing

Wieder einmal trifft man auf einer Veranstaltung auf einen neuen Begriff im Software Qualitätsmanagement (die Unternehmen sind da sehr kreativ). Wir haben uns gefragt was das nun sein könnte:
Technical oriented Testing (TOT)

Es handelt sich um nicht-funktionales Testen. Im speziellen sind Last- und Performancetests gemeint, die zum Test der technischen Zuverlässigkeit von IT-Systemen dienen.

Iqnite Düsseldorf 2011

Es ist viel los auf der iqnite in Düsseldorf. Auch bei den Vorträgen und Führungen zu den Ständen. Einen kleinen Eindruck vermittelt das Bild (zur Mittagspause entstanden).

Nicht funktionales Testen

Nicht funktionales Testen nimmt in den meisten Projekten immer noch einen geringeren Stellenwert ein, als die funktionalen Tests. Das Problem ist sicher auch darin begründet, dass die Anforderung an eine Funktionalität deutlich einfacher zu beschreiben ist (starker Sachbezug), als Anforderungen an die Usability.

• Was ist ein gutes Design?
• Was ist eine gute Bedieneffizienz?
• Wie gelange ich zu einem Corporate Design?
• Wie teste ich dies?

Für diese Fragen benötigt man gute UX Designer, die diese Themen intensiv mit dem Kunden erarbeiten. Daraus Anforderungen zu erarbeiten, aus denen dann Test Cases abgeleitet werden können, ist eine anspruchsvolle Aufgabe.

Ein interessanter Beitrag zum Mobile Usability Testing (Zusammenfassung eines Vortrages der IAK11) ist auf dem User Experience Blog von Ulf Schubert nachzulesen.

Google Docs App - welchen Mehrwert bietet die App

Seit einigen Tagen gibt es in vielen Tech-Blogs und Tech-Newsseiten Informationen zur neuen Google Docs App. Alle schreiben darüber, doch welchen Mehrwert bietet die App? Bietet diese eine bessere Ergonomie oder mehr Funktionen als die Google Browser-Anwendung Text und Tabellen?
Als Google-Anwender nutze ich natürlich auch Google Docs. Aber fast ausschließlich auf dem Desktop oder Netbook. Auf meinem Smartphone (Samsung Galaxy S9000 - Display für Smartphones relativ groß) nutzte ich die Browser-Anwendung bisher recht selten. Die Arbeit macht keine rechte Freude, weil das Display zu klein ist. Zeichnungen, Präsentationen oder Dokumente sehe ich selten an, gelegentlich bearbeite ich ein Spreadsheet (Vervollständigung eines vorhandenen Trainingsplanes oder einer Zeiterfassung). Welche Vorteile bringt mir nun die Native App?

Eine Gegenüberstellung:
Die Dokumentenliste (Übersicht) der App ist eindeutig übersichtlicher und bietet mehr Funktionen. Durch rechts und links wischen können die verschiedenen Kategorien angezeigt werden (bessere Bedienung). In der App können die Dokumente auch in der Liste geshared werden (klick auf den Pfeil):

Dokumentenliste - Docs App

Dokumentenliste - Browser

Die Suche liefert das gleiche Ergebnis bei App und Browser. Das Layout der Ergebnisliste entspricht der Dokumentliste:

Suchergebnis - Docs App

Suchergebnis - Browser

Beim Bearbeiten von Dokumenten bietet die App den Vorteil gegenüber der Browser-Anwendung, dass das Drucken genutzt werden kann (cloud print). Die Bearbeitungsfunktionen sind in beiden Versionen sehr ähnlich. Für Notizen wird man wahrscheinlich noch eine andere App nutzen, bis die Docs App von Google deutlich verbessert wird.:

Dokument - Docs App

Dokument - Browser

Ein geöffnetes Spreadsheet sieht in App und Browser fast identisch aus. Man hat das Gefühl, dass beide mit HTML5 arbeiten:

Spreadsheet - Docs App

Spreadsheet - Browser

Das gleiche gilt für die Bearbeitung von einzelnen Zellen (selbe Technologie?). Auch hier sind App und Browser fast identisch. Und wirklich nicht so toll bedienbar:

Spreadsheet bearbeiten - Docs App

Spreadsheet bearbeiten - Browser

Ein größerer Unterschied besteht bei der Neuanlage. Die App erlaubt die Neuanlage von Dokumenten aus Bildern (mit OCR-Erkennung). So richtig gelungen ist mir die Umwandlung von fotografiertem Text in ein Text-Dokument in Docs noch nicht. Sicherlich eine ganz interessante Funktion. Da wird die Qualität der Ergebnisse (vor allem OCR) beeinflussen, ob sich diese Funktion durchsetzen wird:

Neuanlage - Docs App

Neuanlage - Browser

Die App (Version 1.0.4r) bietet also vor allem ergonomische Vorteile (Dokumentenlisten, Ansichten, Übersichtlichkeit der Dokumentarten). Es sind nur wenige Funktionen mehr, als die Browser-Anwendung bietet.
Einen deutlichen Nachteil hat die App jedoch. Die Performance ist sowohl über WLAN (bei mir ca. 1 MBit) als auch über das Mobilfunknetz deutlich schlechter (bei fast allen Funktionen). Der Cache (200 MB habe ich eingestellt) wird wohl beim Laden (Sync) der Dokumentenliste gefüllt. Denn die App-Dokumentenliste kann auch Offline geöffnet werden. Dokumente werden jedoch nicht gecached (nicht in meiner Version mit Android 2.2). Den ein oder anderen Absturz hatte ich in der App auch schon. Auch hier ist noch etwas zu tun...
Insgesamt lässt sich festhalten, dass die App in dieser Version noch nicht soviel Mehrwert (und mehr Qualität) bietet, dass man sie unbedingt einsetzen muss. Das liegt aber auch wohl daran, dass Dokumentbearbeitung auf Smartphones keine Killer-Anwendung ist.

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.