Testing Zeitschriften im Web

In den letzten zwei Jahren hat sich bei den Zeitschriften zum Testen doch einiges getan. Vor allem gibt es recht neues deutsches Test Magazin. Nachfolgend ein Update zum Artikel von vor zwei Jahren. Kostenlos verfügbare Zeitschriften:

• Testing Experience Deutsch
  erscheint einmal im Quartal - http://www.testing-experience.de/
• Testing Experience Englisch
  sehr umfangreiche Zeitschrift, die zweimonatlich erscheint - http://www.testingexperience.com/
• Professional Tester
  sehr bekannte englischsprachige Zeitschrift, zweimonatlich - http://www.professionaltester.com/
• Tea-time with Testers
  monatliche Zeitschrift - http://www.teatimewithtesters.com/
• Testing Circusenglischsprachige Zeitschrift, die monatlich erscheint - http://www.testingcircus.com/
• Testmagazine - The European Software Testerzweimonatlich - http://www.testingmagazine.com/

Der Change von klassischen Vorgehensweisen zum Agilen

Warum ändert man die Vorgehensweise in der Softwareentwicklung? Warum wird man agil, wenn man vorher klassisch Software erstellt hat? Na klar. Man möchte die Qualität erhöhen. Bezüglich der Kundenanforderungen. Bezüglich der Stabilität. Und auch bei den weiteren Qualitätsfaktoren.
Doch die agilen Projekte liefern in der Regel keine besseren Ergebnisse als klassische Vorgehensweisen, wie die Umfrage Softwaretest ermittelt hat.

Doch was sind die Ursachen? Die Diskussionen mit Experten im letzten Seminar haben dabei folgende mögliche Gründe zu Tage gebracht:

• Alle Beteiligten benötigen einen Mindshift von klassisch zu agil. Teilweise geht nicht.
• "no test - no code"
  Wer den Code nicht richtig gut getestet hat, darf diesen nicht einchecken. Sonst läuft es niemals.
• "Agilität ohne Test Driven Development geht gar nicht" (Zitat Prof. Dr. Mario Winter)
• Ohne testgetriebene Ansätze (TDD, XP, Pairing etc.) sind agile Vorgehensweisen absolut fragwürdig. Das ist dann nur "Hacken".
• Ohne eine Definition of Done wird auch keine Qualität herauskommen
• Planning Poker ohne Berücksichtigung der Testing Tasks (oder der jeweiligen Testaufwände in den user stories) ist nur Selbstbetrug

Halbe Sachen gehen also gar nicht. Ein Change-Prozess braucht viele Coaches und eine Basis, die für Veränderung bereit ist. Sonst wird aus einem Wasserfall nur ein "agiler Wasserfall"...

Neue Sicht zum explorativen Testen

Das explorative Testen ist den letzten Jahren immer mehr ins Gespräch gekommen. Vor allem im agilen Umfeld hat man immer wieder vom Einsatz gehört. Was ich bisher darüber gehört hatte, hatte mich jedoch nicht überzeugt:
Wer keine systemtischen Testverfahren verwendet, wer keine Requirements definiert und wer keine richtige Vorgehensweise hat, der macht eben exploratives Testen. Unstrukturiert und chaotisch...
So habe ich bisher gedacht. Doch eine Veranstaltung mit Prof. Dr. Mario Winter (Link FH Köln) hat mir eine neue Perspektive gegeben (natürlich liegt an seinem Aufbau und Inhalten dieser Methode).

Exploratives Testen

• ist eine zielgerichtete Vorgehensweise um Fehler zu finden (Test-Chartas)
• ist eine strukurierte und kreative Methode (Testing-Touren und Session-basiert)
• ist für die Tester sehr motivierend
• dient als Ergänzung zu systematischen Testverfahren
• ist natürlich auch eine Methode, die man nutzen kann, wenn kaum (oder keine) Konzepte vorhanden sind 

Vor allem in agilen Projekten ist der Einsatz sehr spannend. Neben dem Seminar (extrem empfehlenswert) ist auch ein Buch von James Whittaker (Testing Evangelist) sehr zu empfehlen (Link zu Amazon) 

Später mehr zur Methodik...

Fazit vom German Testing Day 2013

Viele Eindrücke und viele Gespräche gab es auf dem German Testing Day 2013. Doch welche Dinge sind bei uns hängen geblieben? Welche Statements haben uns beeindruckt? Und was lohnt es, umgesetzt zu werden?

• Tester werden weiterhin eine wichtige Rolle in Softwareentwicklungs-Projekten haben, doch die Skills müssen erweitert werden (wenn nicht schon geschehen)


Test Engineers sind hochqualifizierte Personen, mit Fähigkeiten die über das reine Testen hinaus gehen - da muss man sich selber fragen, ob man die Anforderungen noch erfüllt...
Testautomatisierung hat durch die agilen Projekte stark an Bedeutung gewonnen
Manuelle Tests sind weiterhin notwendig. Aber nicht Alles muss/kann/soll automatisiert werden
Entscheidend für den Erfolg von agilen Projekten und agilem Test ist das Mindset. Ohne eine entsprechende Einstellung werden sich keine Erfolge einstellen
• Qualitätssicherung und vor allem "Testing" sind endgültig in der agilen Welt angekommen und bilden dabei keinen Widerspruch, sondern waren schon immer implizit vorhanden

Beide Keynotes waren beeindruckend. Testing @ ebay von Michael Palotas  kann einem schon die Augen öffnen und wer die Chance hat, mal den ehemaligen Schiedsrichter Dr. Markus Merk live zu hören, sollte diese wahrnehmen. Diese Keynote zum Thema "Sicher entscheiden" wäre die Reise alleine schon wert gewesen.

Alles in allem hat sich der German Testing Day 2013, wie auch schon der in 2011, wirklich gelohnt. Am 02.07.2014 findet die dritte Auflage statt. Schauen wir mal...

Ach: Auch Location und Catering waren ziemlich gut. Dies sollte nicht unerwähnt bleiben.

Fazit von Alex und Frank

Vorträge am German Testing Day 2013

Nach der Keynote gab es einige weitere spannende Vorträge. Nachfolgend einige interessante Aussagen der Referenten zu den verschiedenen Themen:

Scrum-Projekte

• Testing ist eine "gefühlt destruktive Aufgabe". Deshalb muss im Team der Wert dieser Aufgabe klar sein (bzw. gemacht werden)
• Testing Aktivitäten sind nicht verhandelbar!
• Die Notwendigkeit der Testautomatisierung wird systematisch unterschätzt.
• Agile Methoden müssen geschult werden. Ein agiles Mindset muss entstehen. Agile Projekte mit Halbwissen gehen schief.
• Scrum-Master ohne IT-Background tun sich sehr schwer.

Mobile Entwicklung

• Testing im mobile Bereich ist bei den nicht-funktionalen Anforderungen nochmal komplexer (z. B. Netzverfügbarkeit, Bandbreite)
• Die Hardwarevielfalt macht die Test-Planung und Testumgebung komplexer (welche Geräte und Betriebssysteme teste ich)
• Der mobile Markt und damit die Anforderungen an die Software/den Test verändern sich sehr schnell

Tracability

• In komplexen Entwicklungsumgebung kann zur Steuerung die werkzeuggestützte Verwaltung der Traceability zu deutlichen Fortschritten führen. Werkzeuge (u. a. OpenSource) gibt es auch dafür.
• Damit können z. B. folgende Fragen schnell beantwortet werden:
• Welchen Test muss ich durchführen, weil sich ein Feature geändert hat
• Welcher Code ist durch geänderte Anforderungen betroffen
• Der Kunde wünscht eine Änderung. Welche Anforderungen ändern sich? Welche Tests müssen nochmal durchgeführt werden?
• ....
• Aber: Die Dokumentation und Verwaltung muss vollständig gelebt werden. Sonst ist es nur Aufwand ohne den letztendlichen Nutzen.

Keynote vom German Testing Day 2013

Eine beeindruckende Keynote mit dem Thema Testing @ ebay hat Michael Palotas auf dem German Testing Day 2013 gehalten. In der Stunde hat er wahres Feuerwerk an Aussagen losgelassen. 

Sicherlich können die Vorgehensweisen bei ebay nicht auf jedes Unternehmen übertragen werden, aber einzelne Ideen sind immer anwendbar. Hier der Versuch diese festzuhalten und zu strukturieren:

Skills und Vorgehensweise:

In 3-5 Jahren haben "normale Tester" keinen Job mehr. Produkte werden heute anders gebaut als noch vor einigen Jahren. Die kleinen Inkremente, die erstellt werden, benötigen ein anderes Vorgehen
• UI-Testautomatisierung: Suites waren und sind ein big failure:
  Suites sind doch oft schon nach drei Sprints ohne Wirkung. Die mangelnde Disziplin in vielen Projekten sorgt dafür, dass die Suites nicht mehr aktuell sind. Schlimm ist es, wenn dann Testfälle herausgenommen werden, um einen "grünen" Zustand zu erreichen.
• Stecke die Energie in die Vermeidung von Fehlern (z. B. in das Testen von UseCases), statt in das Finden und die Verwaltung (sekundäre Artefakte) von Fehlern.
• Qualität entsteht nur gemeinsam im Team. Entwickler und Tester müssen und dürfen sich nicht abschotten.


Aus Effizienzgründen sollten man die Projekte mit so wenig Mitarbeitern wie möglich starten. Zu viele bringen zuviel Overhead
• Manuelle Tests sind nach wie vor unersetzlich
• "fast feedback" aus den Tests ist erwünscht und notwendig in der agilen Entwicklung. Effizienz steht hier im Vordergrund.

Haltung der Mitarbeiter:

Test Driven Development benötigt ein entsprechendes Mindset
• Agile Entwickler benötigen Testing Know-how und ein Testing Mindset
• Agile Tester müssen entwickeln können, um die Entwickler zu verstehen und Sie unterstützen zu können - Domainen-Wissen ist nicht mehr alles


Qualität entsteht nur, wenn die Organisation Qualität lebt
In vielen Projekten liegt der Focus auf der Diskussion, ob man einen Fehler gefunden hat, anstatt diesen sofort zu beheben

Weitere spannende Aussagen:

"THE RACE TO ZERO" ist ein Fehler. Die Kosten für qualitätssichernde Maßnahmen können nicht auf Null gesenkt werden. Qualität kostet.
Outsourcing bringt nicht wirklich etwas bei den Kosten und der Qualität. Auch in Europa kann hohe Qualität mit hoch bezahlten Menschen erreicht werden. Summa summarum zumindest kostenneutral, aber mit höherer Qualität


Tester (Test Engineers) werden bei Ebay genauso gut bezahlt wie Entwickler. Bei guten Leuten darf man nicht sparen (beim Hygienefaktor Geld)
• Freiräume sind für Mitarbeiter enorm wichtig (kennt man ja auch von anderen amerikanischen Unternehmen) - Vertrauen und eine lange Leine sind hier unverzichtbar

Alex und Frank

Pyramide der agilen Testautomatisierung

In agilen Projekten steht und fällt die Qualitätssicherung mit der Testautomatisierung. Doch mit welcher Art der Testautomatisierung? Dazu bietet die Pyramide der agilen Testautomatisierung Anhaltspunkte. Mir persönlich gefällt die nachfolgende Variante von M. Cohn recht gut. Die weiteren Varianten von Mezaros und Crispin unterscheiden sich aus meiner Sicht aber auch nur geringfügig.

Wie die Pyramide verdeutlicht, wird der Erfolg der agilen Testautomatisierung weitgehend durch die Unit-Tests bestimmt. Diese sollten am gesamten Anteil an der Testautomatisierung ca. 70% ausmachen. Sie sind auch verhältnismäßig einfach zu erstellen. UI-Tests werden in der Regel spät erstellt, müssen intensiv gewartet werden (bei jeder Oberflächenänderung) und sind auch wegen der Werkzeuge recht teuer (was allerdings kein Argument sein sollte, komplett darauf zu verzichten).
Natürlich muss der tatsächliche Umfang manueller und automatischer Tests individuell im Projekt festgelegt werden. Und die Art der Applikation bestimmt auch, ob Unit-Tests 70% oder doch nur 60% ausmachen. Die Pyramide gibt jedoch einen wichtigen Hinweis, wie die einzelnen Ebenen zu gewichten sind.