Welche Skills braucht ein Tester?

Aus meiner Sicht ist ein Tester nicht jemand, der ein Dokument vorgesetzt bekommt und dann die Test-Schritte ausführt. Nein. Ein Tester (besser gefällt mir die englische Bezeichnung TE - Test Engineer) benötigt deutlich mehr Skills.

Testing Know-How
Der TE benötigt methodisches Know-How zum Erstellen von Testkonzepten, wie zum Beispiel die Äquivalenzklassenanalyse, Entscheidungstabellen oder die Grenzwertanalyse. Er beherrscht außerdem Review-Techniken, um in frühen Entwicklungsphasen Qualität sichernd mitzuwirken.
Er kennt die Begriffe zum Testing (wichtig ISTQB Curriculum) und aus dem Entwicklungsvorgehen (V-Modell XT, Agile Vorgehensweisen, CMMI etc.). Sonst klappt die Verständigung zwischen TE's und mit den Softwareentwicklern (SE) einfach nicht - auf jeden Fall nicht mit TEs aus anderen Unternehmen. 

Testziele und Testfälle definieren
Die Qualitätsfaktoren (Funktionalität, Zuverlässigkeit, Robustheit, Benutzbarkeit, etc.) sind bekannt und für alle diese Faktoren kann er Testziele festlegen und Testfälle definieren. Damit nicht immer alles getestet wird, legt er Prioritäten pro Test fest und kann Risiken (Produktrisiken, Fehlerrisiken, Komplexitätsrisiken etc.) abschätzen. Er hat also eine Teststrategie.

Tests organisieren
Selbstverständlich kann er auch Tests managen. Testumgebungen und Testdaten definieren und erstellen. Testressourcen (Maschine, Mensch, Testzeiten)  festlegen ist selbstverständliches Handwerkszeug.

Werkzeuge kennen und nutzen
Viele dieser Aufgaben kann man nur effizient erfüllen, wenn man die entsprechenden Testwerkzeuge kennt und intensiv nutzt. Und jeder im Team muss die festgelegten Werkzeuge nutzen. Da spielt es keine Rolle, ob zur Testplanung Excel oder ein High-End Werkzeug genutzt wird. Natürlich machen integrierte Werkzeuge wie Quality Center, MS Test Manager, Test Bench oder auch Open Source Werkzeuge Sinn, in denen manuelle und automatische Testfälle (als Bestandteil von Testsuiten) definiert werden können und nach der Testausführung auch die Fehler gleich im System dokumentiert und verfolgt (Bug Life Cycle) werden können.


Fachliches Know-How
Für hochwertige Tests benötigt der TE natürlich fachliches Wissen zum Produkt oder technisches Wissen, wenn das Testgebiet z. B. eher im Bereich von Backends oder Datenbanken liegt (in dem Fall ist das Fachwissen eben Wissen über die Technik). Ohne fachlichen Hintergrund kann kein guter Testfall und kein gutes Testkonzept entstehen. Dazu muss ein TE auch Fachkonzepte und Use Cases verstehen können.

Testen...
Ja klar. Selber testen ist auch ein wichtiger Teil des Jobs. Die Testfälle ausführen und Abweichungen hochwertig dokumentieren, machen ebenfalls einen guten TE aus. Dazu gehören z. B. die Fähigkeiten der  Klassifikationen von Fehlern, der Bewertung von Fehlerschwere und -dringlichkeit aus Sicht des Kunden und auch eine Dokumentation, die ein SE nachvollziehen kann, um einen Fehler zu reproduzieren.
Gute Tester mit viel Erfahrung finden Fehler, an die vorher kein Entwickler gedacht hat.

Und er kann programmieren. Muss er das wirklich können? Wenn ja, ist das klasse. Dann steht der Testautomatisierung, und damit einer weiteren Qualitätssteigerung, nichts mehr im Wege. Aber viele TEs können es (noch) nicht. Doch vielleicht gibt ja auch hier Google vor, wohin der Weg in der Softwareentwicklung führt. Wie habe ich vor kurzem gelesen: "Test Engineers at Google do code".

Noch eine Anforderung mehr an den TE. Dabei ist sein benötigtes Fachwissen und Aufgabengebiet schon sehr umfangreich. Eine permanente Weiterbildung ist unabdingbar, da geht des dem Test Engineer genau so wie dem Software Engineer...

Warum wird man eigentlich Tester?

Wann man tagtäglich mit dem Test von Software beschäftigt ist, egal ob in der Funktion des Testingenieurs, des Testers oder auch des Testmanagers, fragt man sich öfter, warum man dies eigentlich tut.

Man findet Fehler, die keiner gemacht hat. Man prüft etwas, was sich nicht geändert hat, obwohl es sollte. Man bereitet einen Test vor, den plötzlich keinen mehr interessiert. Man designt Testfälle, die auf Grund extremer Agilität überflüssig wurden. Man prüft das Testobjekt, obwohl es noch gar nicht bereit für den Test ist. Ok. Sollte nicht passieren. Dinge, die jedem Softwaretester aber immer wieder unterkommen.

Und trotzdem macht man dies. Warum?

Weil man etwas verbessern möchte

Dem Kunden etwas möglichst Gutes zu bieten, das spornt an. Deswegen testet man. Deswegen bereitet man die Tests gewissenhaft vor. Und deshalb streitet man sich mit den "Bei mit geht's" Entwicklern.

Neugierde

Irgendwie steckt die Neugierde ja in uns drin. Schauen, ob es wirklich das macht, was es soll. Das System ausreizen. "Und einen Spaß dabei haben", doch einen Bug entdeckt zu haben.

Kreativität

Es ist auch interessant, immer wieder Neues vor sich zu haben. Neue Tests zu entwickeln. Die Tests immer wieder zu verfeinern. Und Dinge auszuprobieren, von denen man glaubt, dass keiner daran gedacht hat.

Hat jemand noch eine andere Motivation?

Was ist Qualität?

Gesehen bei einer netten Kollegin, die mir spannende Ansätze zur Verbesserung der Steuerung von QS- Maßnahmen vorgestellt hat.

Six Sigma für Software - kaum Relevanz

Sig Sigma für Software war in den Jahren 2005-2008 ein Trend, der inzwischen jedoch stark abgeflaut ist. Auf Tagungen zur Softwareentwicklung und auch in Fachzeitschriften ist davon fast nichts mehr zu hören oder zu lesen. Im besagten Zeitraum wurden von verschiedenen Anbietern (u.a. vom ASQF) Seminare dazu angeboten. Und auch in der Presse (Computerwoche und Computerzeitung) gab es Artikelserien.

Was ist Six Sigma für Software?

Six Sigma ist eine Methode zur Verbesserung von Prozessen (Six Sigma bei Wikipedia). Vor allem in der Industrie, mit teilweise komplizierten Fertigungsprozessen, wurde Six Sigma erfolgreich eingesetzt, um bessere Ergebnisse zu erzielen . Ein wesentlicher Bestandteil von Six Sigma sind statistische Methoden zur Analyse bestehender Prozesse oder von Kundenwünschen.
Für die Software-Entwicklung hatte vor allem Dr. Thomas Fehlmann Methoden aus Six Sigma aufgegriffen und diese zu einem "Paket" für die Software-Entwicklung zusammengestellt. Er hat ein Buch darüber geschrieben und bietet auch Dienstleistungen auf diesem Gebiet (euro project office) an.

Warum ist Six Sigma in der Software-Entwicklung kein großer Trend mehr? Was hat eine Marktdurchdringung verhindert?

• Six Sigma für Software ist kein echtes Vorgehensmodell, wie das V-Modell XT oder agile Modelle (z. B. Scrum), sondern eher ein Bausteinkasten.
  Damit eignet es sich nicht, um einen kompletten Entwicklungsprozess danach auszurichten.
• Six Sigma für Software eignet sich auch nicht als Modell für ein Audit, weil Teile fehlen, welche die ganzheitlichen Modelle wie CMMI oder SPICE enthalten.
  Dazu war Six Sigma auch ursprünglich nicht gedacht.
• Es gab kaum Unternehmen in der Software-Branche, die dieses Thema aufgegriffen haben, um es dann intensiv voranzutreiben. So ist auch keine Erweiterung oder Vervollständigung zu einem Gesamt-Modell entstanden.

Nichts desto trotz lohnt es sich, die Tools einmal anzusehen. Es gibt verschiedene Six Sigma Tools für die Kundenorientierung, die Prozessorientierung und die Nutzung von Metriken. Alle können auch im Software-Entwicklungsprozess eingesetzt werden.

Fehler-Lebenszyklus

In der Literatur wird immer wieder vom Fehler-Lebenszyklus (Bug Life Cycle) gesprochen. Dieser wird in vielen unterschiedlichen Varianten erwähnt. Oftmals wir er als Ausschnitt des Softwaretest-Lebenszyklus betrachtet. Oft aber auch als eigenständiger Lebenszyklus. Die nachfolgende Grafik zeigt die relevanten Bestandteile des Fehler-Lebenszyklusses.

Bug Life Cycle

Testing in Unternehmen

Im letzten Jahr hatte IDC eine Studie veröffentlich, in der Unternehmen zum Testing befragt wurden. Bei den Maßnahmen ist es sicher keine Überraschung, dass

1. Testing Mitarbeiter in ihren Rollen professionalisieren
2. Steuerung der Testaktivitäten professionalisieren

den Unternehmen am wichtigsten erscheinen.
Sind dies doch Aufgaben, denen sich jedes Unternehmen, das Software entwickelt, permanent stellen muss. Mitarbeiter müssen sich weiter qualifizieren, neue Mitarbeiter eingearbeitet werden, neue Methoden und Werkzeuge in bestehehende Prozesse integriert werden. Test-Prozesse optimiert oder neu strukturiert werden. Das trifft jeden.
Was mich jedoch überrascht hat, das nur 60% Systemtests und 44% der Befragten Integrationstests durchführen. Und wenn man in den Maßnahmen schaut, will aber kaum einer diese Situation verbessern.
Statt dessen stehen die "Hype-Themen" Agilität, Usability Testing und Testing Services auf der Tagesordnung. Doch den Trends hinterher laufen, verbessert nicht die grundlegende Situation. Wie immer ist es besser, erst einmal die Grundlagen zu schaffen und dann weiter zu sehen.

Zur Pressemeldung der IDC-Studie (Link)

Fehler(-kultur)

Der Fehler beeinflusst die Entwicklung von Software sehr stark. Designer machen Fehler. Konzeptentwickler machen Fehler. Programmierer machen Fehler. Tester machen Fehler. Und auch Projektleiter machen Fehler. Denn Fehler sind menschlich und passieren in allen Prozessschritten der Softwareentwicklung.
Damit der Kunde aber nicht unter diesen Fehlern leiden muss, sollten wir uns eine Kultur des "Fehlerbewusstseins" aneignen, sonst hören wir weiterhin folgende Aussagen:

• Bei mir geht's (BMG-Syndrom)!
• Das haben wir doch sicher getestet!
• War das nicht Eure Aufgabe?
• Wir machen keine Fehler - Das war so gewollt
• Das ist doch nicht so schlimm für den Kunden

In vielen Diskussionen erfahre ich, dass dies eine weitverbeitete Einstellung ist. Der Entwicklungsprozess und der Kunde benötigen jedoch eine hohe Transparenz, damit Fehler umfassend und zeitnah bereinigt werden. Wir brauchen eine neue Fehlerkultur. Und wir brauchen Anreize in den Organisationen, die eine neue Kultur der Transparenz schaffen. Doch welche Anreize können dies sein?

Auf thewire.ch findet sich auch ein interessanter Artikel zur Fehlerkultur.