Testautomatisierung / Softwaretesten


Softwaretesten Blogartikel


Testautomatisierung Blogartikel

Testendekriterien
Testen im agilen Kontext: habe ich genug getestet – wann höre ich auf? 1920 1114 Thorsten Specht

Testen im agilen Kontext: habe ich genug getestet – wann höre ich auf?

Eine Frage, die vermutlich jedem Softwaretester irgendwann begegnet: wann habe ich genug getestet? Oder: wann höre ich auf? Insbesondere in iterativen Entwicklungsprozessen ist diese Frage nicht einfach zu beantworten. In diesem Artikel gehe ich auf die Antworten anderer Softwaretester ein und beantworte die Frage abschließend anhand meiner eigenen Erfahrungen.

Definition von Testendekriterien und Abgrenzung von der Definition of Done

Gemäß ISTQB sind Testendekriterien definiert als “die Menge der abgestimmten generischen und spezifischen Bedingungen, die von allen Beteiligten für den Abschluss eines Prozesses akzeptiert wurden.” Weiter heißt es, Endekriterien verhinderten es, dass eine “Aktivität als abgeschlossen betrachtet wird, obwohl Teile noch nicht fertig sind.”

Diese Definition kann nützlich sein, um das Testende von der Abnahme eines Features abzugrenzen. Bezogen auf Scrum sprechen wir bei Abnahmekriterien üblicherweise von der Definition of Done. Diese geht jedoch weiter, als bis zum Ende des Testens.

Im Folgenden beziehe ich mich ausschließlich auf den Prozessschritt Testen in der agilen Softwareentwicklung.

Projekt-getriebene Testendekriterien: Testfälle, Codeabdeckung, Deadlines

User Elham Jamal beantwortet in diesem populären Beitrag auf LinkedIn die Frage nach dem Testende mit harten Testendekriterien:

  1. Testing Deadlines
  2. Completion of test case execution
  3. Completion of Functional and code coverage to a certain point
  4. Bug rate falls below a certain level and no high priority bugs are identified
  5. Management decision

Angemerkt sei, dass er keinen Bezug auf das agile Vorgehensmodell nimmt. Ich möchte die einzelnen Kriterien dennoch im agilen Kontext diskutieren:

  1. Deadlines sind ein rein zeitliches Kriterium. Beendet der Tester seine Arbeit, weil die Deadline es so vorsieht, scheint er nach anderen Kriterien nicht fertig zu sein – sonst hätte er bereits aufgehört. Zudem beginnt das Testen im Scrum-Prozess oft erst kurz vor der Deadline – dem Sprintende.
  2. Testfälle entstehen basierend auf dem Modell der Software, bevor der Tester sie wirklich nutzen kann. Daher deckt ein rein Testfall-basiertes Testen möglicherweise nicht die relevanten Schwachstellen der endgültigen Software ab.
  3. Es ist eine sinnvolle Strategie, die Abdeckung funktionaler Anforderungen und der Codeabdeckung als ein messbares Instrument heranzuziehen, um das Testende zu bestimmen. Im agilen Kontext ist es allerdings zeitkritisch, in Iterationen von 2-3 Wochen und einem verbleibenden Testzeitraum von wenigen Tagen eine vollständige Abdeckung der beiden Aspekte zu erreichen.
  4. Das Testende anhand der Fehlerrate zu bestimmen, ist im agilen Kontext ebenfalls kritisch. Bei kleinen Features bewegen wir uns im Rahmen von möglicherweise nur ein bis zwei Fehlern pro Feature. In solch einem Falle ist eine quantitative Grenze schwierig zu ziehen.
  5. Ähnlich wie bei Punkt 1 wird in die Arbeit des Testers eingegriffen. Ein externer Einfluss als Testendekriterium ist mit hoher Wahrscheinlichkeit nicht im Sinne der Softwarequalität.

Fehler-Vorhersage als Testendekriterium

Yegor Bugayenko schreibt in diesem Blogbeitrag: “the only valid criteria for exiting a testing process is the discovery of a forecasted amount of bugs”. Wie er in seinem Beitrag schildert, muss im Laufe des Testprozesses eine möglichst genaue Prognose über die verbleibenden Fehler entstehen. Anhand dieser Daten kann der Tester einschätzen, ob das Produkt ausreichend getestet ist, um es auszuliefern.

Ich stimme dieser Aussage weitestgehend zu. Hat der Tester ausreichend Daten gesammelt, kann er zusammen mit dem Team entscheiden, ob die Software gut genug ist, um sie auszuliefern. Und dennoch fehlt mir eine konkrete Ableitung, wann der Tester demnach aufhören kann zu testen.

Risiko-basierte Testendekriterien

Wie wir in zukünftigen Beiträgen noch genauer beleuchten werden, verfolgen wir den Ansatz des risikogetriebenen Testens. Hieraus lassen sich auch auf Risiken basierende Testendekriterien ableiten. Kurz umrissen bedeutet risikogetriebenes Testen: Risiken analysieren, Risiken priorisieren, Risiken minimieren.

Anders als die Ansätze in den referenzierten Beiträgen bietet das risikogetriebene Testen eine handfeste Strategie, um das Testende zu begründen.

Das Testende wird bereits im zweiten Schritt – der Risikopriorisierung – vorbestimmt. Es sei angemerkt, dass die Priorisierung der Risiken nur zwei Fragen beleuchtet: Welche Risiken sollen im Rahmen des Tests erkundet werden? Welche Risiken nehmen wir in Kauf, ohne ihnen nachzugehen? Der Tester ist genau dann fertig, wenn er genügend Daten über potentielle Risiken gesammelt hat. Daten sammeln meint hier sowohl den explorativen Test als auch Absprachen mit dem Product Owner oder den Entwicklern.

Offen bleibt also die Frage, wie ausführlich der Tester seinen explorativen Test gestaltet, um das jeweilige Risiko zu erkunden. In der Praxis handhabe ich es so, dass ich anhand der Rahmenbedingungen Zeit, Aufwandsschätzung und Kritikalität entscheide, wann ich ein Risiko ausreichend erkundet habe.

Fazit: Der Test ist beendet, wenn ausreichend Daten bereitstehen

Richtet sich das Ende nach Deadlines oder durch Vorgaben des Projektmanagers, testen wir in der Regel zu viel oder zu wenig. Beides ist kostspielig und ineffizient. Stattdessen sollte der Tester seine Arbeit systematisch abschließen. Hierzu benötigt er Erkenntnisse anhand derer ein Team entscheiden kann, ob es die Software ausliefern möchte.

Harte Testendekriterien eignen sich für das agile Vorgehensmodell nur bedingt. Stattdessen lassen sich solche Kriterien als Hilfsmittel nutzen, um eine Software oder eine Softwarekomponente systematisch zu erkunden. 

Quereinstieg ins Softwaretesten – Rückblick nach zwei Jahren 1920 1440 Thorsten Specht

Quereinstieg ins Softwaretesten – Rückblick nach zwei Jahren

In älteren Beiträgen habe ich bereits über meinen Quereinstieg als Softwaretester berichtet. Inzwischen sind zwei Jahre vergangen. In diesem Rückblick fasse ich zusammen, was ich gelernt und welche Erfahrungen ich gemacht habe.

Auf dem Fundament aufbauen: Zeit für gezielte Weiterbildung

Im ersten Artikel dieser Serie habe ich berichtet, mit welchen Grundlagen ich als Quereinsteiger in der Qualitätssicherung gestartet habe. Mein zweiter Bericht beschäftigte sich damit, wie ich mich in das Umfeld der Softwareentwicklung eingelebt habe. Hierbei bin ich auch darauf eingegangen, wie ich mich an die Zeremonien des agilen Arbeitens gewöhnt habe. Fachlich habe ich nur das ISTQB-Zertifikat erwähnt, das die Grundbegriffe aus dem Bereich Softwaretest abdeckt.

Inzwischen sind all die thematisierten Herausforderungen selbstverständlicher Alltag. Es fühlt sich an, als hätte ich nie in einem anderen Bereich gearbeitet. Zudem habe ich durch die Projekterfahrung der letzten zwei Jahre breites Grundlagenwissen aufgebaut. Dieses Wissen hilft mir, spezifische Themen, Methoden und Tools zu identifizieren, in die es sich einzuarbeiten lohnt.

Wissensaustausch mit anderen Testern

Als agiler Softwaretester ist es normal, dass ich Fehler und Risiken übersehe. Tauchen diese Bugs später auf, analysiere ich, wie ich analoge Risiken identifizieren und entsprechendes Fehlerpotential zukünftig mindern kann.

Der Austausch mit anderen Testern ermöglicht es, auch aus deren Fehlern und Erfahrungen zu lernen. Somit lassen sich entsprechende Defekte im eigenen Projekt leichter vermeiden.

Als besonders wichtig habe ich den Wissensaustausch mit anderen Testern aus dem eigenen Projekt kennengelernt. In großen Projekten ist es nicht möglich ist, alle Bereiche einer Anwendung zu überblicken. Deshalb ist es nötig, sich mit anderen Testern beziehungsweise Teams auszutauschen. Das gilt nicht nur dafür, frühzeitig an die richtigen Informationen zu kommen. Es ist genauso wichtig, andere Teams über Risiken zu informieren, die eine Änderung oder ein neues Feature mit sich bringt.

Das dritte Team – das dritte Projekte – der dritte Tech-Stack

Um in der Softwareentwicklung erfolgreich zu arbeiten, ist stetiges Lernen unabdingbar – auch für uns Softwaretester. An der nachfolgenden Schilderung möchte ich veranschaulichen, wie wichtig die Bereitschaft ist, sich stetig in neue Technologien und Tools einzuarbeiten.

In meinem ersten Projekt habe ich eine bestehende Testautomatisierung vorgefunden. Die eingesetzten Technologien waren das Automatisierungs-Framework Geb, das Testing-Framework Spock und die Programmiersprache Groovy.

Nach einem Jahr hat sich die Projektstruktur geändert. Ich landete in einem anderen Team und hatte die Freiheit, die Testautomatisierung neu aufzusetzen. Da ich in einem Team von JavaScript-Entwicklern war und Kollegen bereits gute Erfahrungen mit Cypress gemacht hatten, habe auch ich mich für Cypress und die Sprache JavaScript entschieden.

Nur ein halbes Jahr später ging die Reise weiter. So landete ich in meinem heutigen Backend-Team. Hier kümmern sich die Entwickler um die Unit- und Component-Tests, die sie – wie auch die Services – in Scala schreiben. Für die End-2-End-Tests haben sich die Teams auf Selenide und die Programmiersprache Java geeinigt.

Fazit nach zwei Jahren als Softwaretester: der Quereinstieg hat sich gelohnt

Fazit: Der Quereinstieg in die Softwareentwicklung und speziell in das Softwaretesten war für mich ebenso abenteuerlich wie fordernd. Schnell hatte ich wahnsinnig viel Spaß dabei, doch besonders in den ersten Wochen stieß ich täglich auf neue Herausforderungen. Ähnliche Erfahrungen schildern übrigens Kristofer Mohr und Matthias Passer, die hier über Ihren Quereinstieg bei MaibornWolff erzählen.

Zunächst musste ich mich in dem Berufsfeld einleben. Danach war mein Kopf frei genug, um mich abseits meines Projekts mit neuen Themen zu beschäftigen. Die Grundlagen zu bilden, war der anstrengendste Abschnitt.

Inzwischen lese ich regelmäßig in Blogs oder Büchern über Software Testing oder agile Softwareentwicklung. Hierbei sammle ich neue Impulse und lasse diese in meine Arbeit einfließen. Im Unterschied zu den ersten Monaten als Softwaretester, wähle ich die Themen gezielt basierend auf meinen aktuellen Herausforderungen.

 

Backend vs. Frontend – ein Vergleich aus Testerperspektive 1920 1280 Thorsten Specht

Backend vs. Frontend – ein Vergleich aus Testerperspektive

In der Softwareentwicklung hat es sich schon lange etabliert, zwischen Frontend-, Backend- und Fullstack-Entwicklern zu unterscheiden – anders bei Testern. Ein Blick in gängige Jobbörsen zeigt, dass Unternehmen im Wesentlichen zwischen Softwaretestern, Testautomatisierern, Testanalysten und Testmanagern unterscheiden. In vielen Fällen sind die Stellenbeschreibungen schwammig, die Tätigkeitsbeschreibungen überschneiden sich. Doch gerade für Testautomatisierer und Softwaretester bedeutet es einen wesentlichen Unterschied, ob diese im Frontend, im Backend oder in beiden Bereichen arbeiten.

In diesem Artikel schildere ich, inwiefern sich die Arbeit des Testers im Frontend und Backend unterscheidet. Ich schildere, auf welche Herausforderungen der Tester im Frontend und Backend trifft und welche Fähigkeiten er benötigt. Die Darstellung erfolgt subjektiv und basiert vorwiegend auf meinen Erfahrungen, die ich in agilen Entwicklungsteams in der Webentwicklung gesammelt habe.

Testen im Frontend

Wer als Softwaretester anfängt, macht das meistens im Frontend. So war es auch bei mir. Eine übliche User Story beschreibt abstrakt, wie sich die Benutzeroberfläche einer Anwendung bzw. Website verändern soll oder wie neue Komponenten erscheinen sollen. Meist ist eine solche Story angereichert mit Designs, Wireframes oder Screenshots. Je nach Vorarbeit steht das Design so fest, dass ein Prototyp pixelgenau zeigt, wie die Anwendung später auszusehen hat. Für den Tester macht es das recht einfach: Er muss Neuentwicklungen gegen diese Anforderungen prüfen und testet idealerweise auch, wie sich die Software in Grenzbereichen, unter verschiedenen Systemen (z. B. Betriebssysteme oder Browser) oder im Fehlerfall verhält. Kennt er das Projekt bereits, kann er durch Regressionstests feststellen, ob ältere Komponenten und Features auch weiterhin funktionieren.

Manuelles Testen im Frontend

Um das Frontend manuell auf Herz und Nieren zu testen, sind ein Auge für’s Detail, Geduld und Fleiß gefragt. Die technischen Hürden sind eher gering und selbst Backend-Anbindungen lassen sich über das Frontend testen. Letztlich bewegt sich der Tester eben entlang der Benutzerschnittstelle. Und die ist im Idealfall selbsterklärend.

Gleichzeitig hat der Tester mit nicht-funktionalen Anforderungen zu kämpfen: Ist die GUI stimmig, intuitiv, verständlich und nutzerfreundlich? Themen wie Barrierefreiheit können relevant sein. Hinzu kommt, dass ein einmal aufgetretener Fehler nicht immer leicht zu reproduzieren ist. Ich erinnere mich an viele Diskussionen mit Entwicklern, die einem Fehler erst dann nachgehen wollten, wenn sie ihn selbst erwirken konnten. Hier sieht der Entwickler die Beweislast beim Tester: Screenshots, Screenrecordings und detaillierte Beschreibung zur Reproduzierbarkeit werden erwartet.

Das Frontend automatisiert testen

Im Frontend übernimmt der Tester üblicherweise je nach Projekt-Struktur die UI- und/oder End-2-End-Tests. Die hierzu einsetzbaren Technologien unterscheiden sich nicht. Gängige Tools für die programmatische Testautomatisierung des Frontends sind zum Beispiel Selenium und Cypress. Manche Unternehmen setzen auf GUI-basierte Testautomatisierungstools wie Tosca oder Katalon Studio, die kaum oder keine Programmierkenntnisse erfordern. Das Ziel automatisierter Frontend-Tests ist es, funktionale Anforderungen der Anwendung zu testen. Nicht-funktionale Anforderungen zu Design, UX oder Usability muss der Tester manuell testen.

Testen im Backend

User Stories im Backend sind wesentlich abstrakter und meist dem endgültigen Anwendungsfall ferner. Ein Beispiel: Während das Frontend immer etwas abbildet, was irgendwann mal ein Mensch sehen und/oder verwenden wird, dient das Backend oftmals dafür, Schnittstellen bereitzustellen, die andere Systeme oder Services abfragen bzw. konsumieren. Dabei ist nicht grundsätzlich gegeben, dass ein Mensch diese Funktionalitäten selbst verwenden wird, sondern dies im Hintergrund durch die Anwendung geschieht.

Manuelles Testen im Backend

Für den Tester bedeutet das Folgendes: Um ein Backend zu testen, ohne das Frontend zu verwenden, muss er in der Regel Requests an eine API senden. Anschließend prüft er, ob die jeweilige Response der erwarteten Response entspricht. Dies geschieht zum Beispiel über einen API-Client wie Postman. Da eine Response oft lediglich ein Status-Code ist, der dem Tester sowas sagt wie 200 OK oder 404 not found, muss der Tester zusätzlich die Logs des Service heranziehen.

Neben der Weiterentwicklung von APIs wird im Backend oft an Datenbanken gearbeitet. Für einen Tester reicht ein Grundwissen zu SQL (bzw. der jeweiligen Datenbanksprache), um zu testen, ob die richtigen Daten in den richtigen Fällen in der Datenbank abgelegt werden. Zudem kann er prüfen, ob Regeln für die Datenbank, z. B. ein not null constraint, korrekt implementiert wurden.

Automatisiertes Testen im Backend

Anders als im Frontend werden im Backend üblicherweise keine End-2-End-Tests implementiert. Stattdessen lässt sich das Backend umfangreich durch Unit-Tests testen. Ergänzend hierzu kann (und sollte) das Team Integrationstests implementieren, um die Business-Logik zu testen. Je nach Team- und Projektstruktur übernehmen im Backend die Entwickler nicht nur die Unit- sondern auch die Integrationstests.

Als technisch versierter Tester ist es sinnvoll, die Integrationstests selbst zu schreiben. Anders als der Entwickler identifiziert er die Testfälle unvoreingenommen und beschränkt sich bei den Testdaten nicht auf das Offensichtliche.

Ist der Tester weniger technisch versiert, sollte er die Integrationstests zumindest auf Vollständigkeit sowie Redundanz prüfen und die Entwickler bei der Auswahl geeigneter Testdaten zu unterstützen.

Ergänzend ermöglichen API-Clients wie Postman, API-Tests zu schreiben, um insbesondere einfache Regressionstests zu automatisieren.

Mein Fazit nach 7 Monaten Backend-Testing

Für den Einstieg in ein Projekt, ist die Arbeit im Frontend komfortabler. Es ist einfacher, die Software kennenzulernen, Anwendungsfälle zu verstehen und sich in den Nutzer hineinversetzen zu können. Dafür ist es sehr zeitaufwändig, Logik der Software zu testen, die aus dem Backend stammt. Zudem kann es den Tester auf Dauer langweilen, immer und immer wieder dieselbe GUI zu verwenden. Dies ist vor allem bei manuellen Regressionstests der Fall. Insbesondere deshalb ist eine solide Testabdeckung mit automatisierten End-2-End Tests wertvoll.

Auch wenn der Start ins Backend herausfordernd ist, lohnt sich der erste Schmerz. Der Tester taucht schnell tiefer in die technischen Finessen der Software ein und ist dazu gezwungen, die Prozesse und Architektur der Anwendung zu verstehen. Ist diese Hürde genommen, macht das manuelle Testen des Backends insofern viel Spaß, als dass der Diskussionsbedarf darüber, was richtig, was falsch, was gut oder was schlecht ist, deutlich kleiner ist. Soll ein Endpunkt in einem Szenario den Code 200 zurückgeben und tut dies, ist der Testfall erfolgreich. Nachträglich über das Design der Implementierung zu diskutieren, ist eher unwahrscheinlich. Im Frontend hingegen habe ich genau das sehr oft erlebt: Gerade dann, wenn ein Feature fertig ist, wird gerne noch mal über Design und UX diskutiert. Visuelles ist eben sehr subjektiv.

Abschließende Worte

Als Tester wünsche ich mir, mit allen Fassaden einer Anwendung in Berührung zu kommen. Sich mit dem Frontend auseinanderzusetzen hilft dabei, eine bessere Vorstellung von dem Endprodukt zu bekommen. Das Backend zu verstehen und zu testen, eröffnet einen tiefen Blick hinter die Fassade. Bietet sich mir die Chance, beides zumindest zu Teilen abzudecken, ist die Abwechslung am größten und das Verständnis über sinnvolle und notwendige Testfälle nimmt zu.

softwaretesten-risikobasiert-testen
Testautomatisierung – warum es in vielen agilen Projekten nicht optimal eingesetzt wird 1920 1282 Jakob R. Jaworski

Testautomatisierung – warum es in vielen agilen Projekten nicht optimal eingesetzt wird

Testautomatisierung – Fester Bestandteil der agilen Softwareentwicklung

Testautomatisierung ist ein fester Bestandteil der agilen Softwareentwicklung. Trotzdem habe ich oft die Erfahrung gemacht, dass die Testautomatisierung in vielen agilen Projekten nicht optimal eingesetzt wird. Es fängt damit an, dass die Testautomatisierung oft isoliert vom manuellen Testen gesehen wird. Selbst die Testautomatisierungsstufen sind in vielen Fällen nicht aufeinander abgestimmt. Die nächsten Abschnitte gehen näher auf den letzten Punkt ein.

Testautomatisierungspyramide

Wenn wir uns die Testautomatisierungspyramide anschauen (siehe Abbildung 1), sehen wir drei Arten von automatisierten funktionalen Tests: Unit-Tests, Integrationstests und End-2-End-Tests. In der Praxis gibt es noch andere Arten von automatisierten Funktionalen Tests. In diesen Artikel fokussieren wir uns auf diese drei, da die Problematik auch bei Zunahme andere Testarten besteht.

Die Unit-Tests – Was der Softwaretester nicht weiß

Der Prozess startet bei den Unit-Tests. Die Entwickler implementieren in der Regel die Unit-Tests und oft hat der Softwaretester keinen Überblick, aus welchen Komponenten bspw. ein Microservice besteht. Dies führt dazu, dass der Softwaretester keinen oder nur wenig Informationen darüber hat, was auf der Unit-Test-Ebene abgedeckt ist und welche Abdeckung auf Unit-Test-Ebene möglich ist.

Die Integrationstests – Die Problematik führt sich fort

Bei den Integrationstests führt sich dieses Verhalten fort. In der Regel werden auch die Integrationstests von den Softwareentwicklern implementiert. Im Microserivce-Umfeld sollte hier die Business-Logik getestet werden. Dadurch, dass der Softwaretester keinen Überblick über die Testabdeckung auf Integrationstest-Ebene hat, wird oft die Business-Logik auf End-2-End-Testebene abgedeckt. Das führt unteranderem zu Redundanz und einer großen Anzahl an automatisierten Testfällen auf End-2-End-Testebene. Dies hat auch die Konsequenz, dass der Softwaretester die manuellen und automatisierten End-2-End-Tests nicht optimal im Testprozess abstimmen kann.

Erhöhung der Problematik durch Font-End und Back-End Teams

Die Abstimmungsproblematik wird noch erhöht, wenn bspw. die agilen Teams nicht Cross-Funktional sind und ein oder mehrere Back-End-Teams und Front-End-Teams an der Implementierung der Anwendung beteiligt sind. In diesem Fall wissen die einzelnen Tester oft über die Testabdeckung der unterschiedlichen Teams nicht Bescheid.

Was für uns funktioniert hat

Eine Möglichkeit, die wir eingesetzt haben, um den Softwaretestern einen Überblick über die Unit-Tests und Integrationstest zu verschaffen, ist bspw. im Pair Progamming zusammen mit den Entwicklern die Unit-Tests und Integrationstests zu implementieren. Dies führt unteranderem zu den folgenden Vorteilen:

  • Der Softwaretester bekommt einen Überblick, welche Testabdeckung auf Unit-Test und Integrationstest-Ebene möglich ist.
  • Der Softwaretester hat die Informationen, was bereits auf Unit-Test- und Integrationstest-Ebene abgedeckt ist.
  • Der Softwaretester kann mit seinem Testing-Know-How zusammen mit den Entwicklern die Unit-Tests und Integrationstests optimieren.
  • Der Softwaretester bekommt bspw. einen Überblick über den Aufbau eines Micro Services

Wird eine Anwendung von mehreren agilen Teams entwickelt, hat der jeweilige Tester eines Teams in der Regel nicht die Kapazitäten, um sich einen Überblick über die Testabdeckung der anderen Teams zu verschaffen. Hier haben wir gute Erfahrung damit gemacht, eine neue Rolle einzusetzen, welche unter anderem Überblick über die Testabdeckung der einzelnen Teams hat und diese optimal aufeinander abstimmt und koordiniert.

 Deine Erfahrung

Welche Erfahrungen hast du mit dem Einsatz von Testautomatisierung in Deinem Projekt gemacht? Über Dein Feedback würden wir uns in den Kommentaren freuen!

erfahrung-als-software-tester
Die ersten Monate als Software Tester 1800 1350 Thorsten Specht

Die ersten Monate als Software Tester

In einem früheren Artikel habe ich bereits geschildert, wie mir der Quereinstieg als Software Tester gelungen ist. Nun möchte ich berichten, wie mein Einstieg als Software Tester verlaufen ist.

Ankommen, einarbeiten, loslegen: Schnellstart als Software Tester

Die ersten Tage als Software Tester verliefen nicht anders, als ich es von einem neuen Job erwartet hätte: im Unternehmen ankommen, den Rechner einrichten und erstmal zurechtfinden. Parallel hat mich mein Team – ein typisches Scrum-Team aus Devs, PO, Scrum Master und einem Tester – in das Tagesgeschehen eingebunden. In unserer Organisation bedeutet das vor allem, an Meetings teilzunehmen. Obwohl ich bereits im agilen Umfeld gearbeitet hatte, musste ich mich zunächst in die zahlreichen Scrum Zeremonien und deren durch das Team gefärbte Besonderheiten einfinden.

Mit meiner eigentlichen Arbeit, also Software zu testen, konnte ich bereits wenige Tage nach meinem Einstieg beginnen. Das macht den Quereinstieg in diesen Beruf so attraktiv: manuell explorativ testen kann prinzipiell jeder. Natürlich helfen Heuristiken, Techniken und persönliche Erfahrung dabei, Software gründlicher und vor allem effizient zu testen. Doch anders als etwa für einen Entwickler, sind keine Hardskills – zum Beispiel Programmierkenntnisse – zwingend nötig. So habe ich bereits in meinen ersten Tagen als Software Tester produktive Arbeit leisten können. Gleichzeitig konnte ich mich mit dem Projekt vertraut machen.

Hürden als Quereinsteiger: Testautomatisierung und Entwickler-Sprache

Von Beginn an war klar: früher oder später werde ich auch als Software Tester an der Testautomatisierung arbeiten. Was mir heute am meisten Spaß macht, machte mich anfangs nervös. Zwar half mir mein Mentor dabei, das Projekt aufzusetzen und erklärte mir die Struktur und Strategie unserer Automatisierung. Doch als Quereinsteiger als Software Tester mit rudimentären Programmierkenntnissen hatte ich großen Respekt davor, den Code anderer Leuten zu bearbeiten.

Neben der Testautomatisierung machte mir Anfangs die Sprache der Entwickler zu schaffen. Häufig fielen Begriffe, mit denen ich nichts anfangen konnte. Nicht nur in Meetings, auch in der Mittagspause hatte ich damit zu kämpfen. Die Sprache der Entwickler muss man erstmal lernen.

Eine weitere Hürde als Quereinsteiger ist es, das gesamte Entwicklungsgeschehen zu überblicken. So saß ich im Planning 2 oft mehrere Stunden, ohne eine einzige Diskussion fachlich verfolgen zu können. Im Refinement hob ich willkürlich Punkte, ohne den Entwicklungsaufwand abschätzen zu können. Und oftmals habe ich mich gefragt, ob ich als Tester in diesen Meetings überhaupt richtig bin.

Basiswissen für Quereinsteiger als Software Tester: Das ISTQB Foundation Level

Man mag von Zertifikaten halten, was man will: Besonders als Quereinsteiger ist das Basiswissen des ISTQB Foundation Level eine solide Grundlage, um als Software Tester zu arbeiten. Nach etwa 5 Monaten habe ich eine 3-tägige Schulung mit anschließender Prüfung für das Foundation Level absolviert, um das nach ISTQB geltende Basiswissen des Softwaretestens zu erlernen. Auch wenn das Format nicht mein bevorzugter Lernstil war, habe ich aus der Schulung hilfreiches Wissen mitgenommen, das ich bei meiner täglichen Arbeit als Software Tester im Hinterkopf behalte.

Neben standardisiertem Basiswissen und den Erfahrungen aus dem Berufsalltag sind vor allem Blog-Artikel und Literatur hilfreich. Ein paar Tipps für den Einstieg findest du in unserem Beitrag „Software Tester werden„. Weiterführende Literaturempfehlungen findest du in unseren Blogartikeln zum Thema Softwaretesten.

 

 
 
 
testautomatisierung-tools-liste
Testautomatisierung Tools 1800 1125 Jakob R. Jaworski

Testautomatisierung Tools

Testautomatisierung Tools für Webanwendungen

 

Umfassende Zusammenfassung von Testautomatisierung Tools für Webanwendungen, mobilen Anwendungen und Web-Services. Mit kostenfreien Schulungen zu den einzelnen Tools. Der Fokus liegt auf der Testautomatisierung von Webanwendungen und Web-Services.

Testautomatisierung Tools Selenium

  • Selenium ist eine Open Source API die kostenfrei genutzt werden kann.
  • Kann mit allen gängigen Browser eingesetzt werden (Chrome, Firefox, Opera, Safari, Internet Explorer)
  • Selenium ist in erster Line kein Testautomatisierung Tool, sondern ein Browser Automatisierungstool, welches in Verbindung mit eine Testingframework (wie bspw. JUnit, TestNG) zu einem Testautomatisierung Tool wird.
  • Selenium kann unteranderem mit den folgenden Programmiersprachen eingesetzt werden:
    • Java
    • C#
    • PHP
    • JavaScript,
    • Ruby
    • Python
  • Selenium ist für den agilen Softwareentwicklungsprozess geeignet
  • Kann mit allen gängigen Continouos Integration Server (Jenkins, GitLab)eingesetzt werden
  • Selenium hat eine große Community
  • Meist eingesetzte Testautomatisierung Tool für Webanwendungen
  • Es gibt eine große Anzahl an Reporting Frameworks wie Bspw. Allure-Report und ExtentReports, die in das Testautomatisierungsframework mit Seleniun integriert werden können
  • Mehr zur Testautomatisierung mit Selenium: Testautomatisierung mit Selenium
  • Video Selenium Demo: Selenium parallels datengetriebens Framework
  • Kostenfreie Selenium Online Schulung: Selenium vom Anfänger zum Profi 

 

Testautomatisierung Tools Selenide

  • Selenide ist ein Wrapper um Selenium. Im Gegensatz zu Selenium ist das Testautomatisierungsframework Selenide speziell für die Testautomatisierung von Webanwendungen erstellt worden. Selenide bietet Funktionalitäten Out-of-the-Box die mit Selenium individuell implementiert werden müssen wie Bspw.
    • Screenshots
    • Explizit Waits
    • Assertions
  • Selenide ist genau wie Selenium ein Open Source Framework, welches Kostenfrei genutzt werden kann.
  • Selenide kann mit der Programmiersprache Java eingesetzt werden
  • Selenide ist für den agilen Softwareentwicklungsprozess geeignet
  • Kann mit allen gängigen Continouos Integration Server (Jenkins, GitLab) eingesetzt werden
  • Selenide hat noch eine kleine Community
  • Es gibt eine große Anzahl an Reporting Frameworks wie bspw. Allure-Report und ExtentReports die mit dem Testautomatisierungsframework mit Selenide integriert werden können.
  • Demo-Video: Selenide

 

Protractor

  • Ist ein Wrapper um Selenium und wird für die Testautomatisierung von Angular Webanwendungen eingesetzt.
  • Protractor kann unteranderem mit den Programmiersprachen JavaScript und TypScript eingesetzt werden.
  • Protractor ist für den agilen Softwareentwicklungsprozess geeignet
  • Protractor hat eine mittel große Community
  • Meist eingesetztes Testautomatisierung Tool für Angular Anwendungen
  • Link zu Protractor

 

Katalon Studio

  • Katalon Studio kann kostenfrei eingesetzt werden
  • Katalon Studio erfordert keine Programmierkenntnisse.
  • Katalon Studio ist ein Testautomatisierung Tool für Webanwendungen, mobilen Anwendungen und Webservices.
  • Link zu Katalon Studio

 

Ranorex Studio

  • Ranorex ist ein kommerzielles Testautomatisierung Tool
  • Ranorex erfordert keine Programmierkenntnisse
  • Ranorex ist ein Testautomatisierung Tool für Desktop, Webanwendungen und mobilen Anwendungen.

 

Coming Soon: 

Robot Framework

Cypress

Geb

TestCafe

 

Testautomatisierung Tools von mobile Anwendungen

Testautomatisierung Tools  Appium

  • Appium ist eine Open Source API die kostenfrei genutzt werden kann.
  • Kann für die Testautomatisierung von Android, iOS und mobilen Webanwendungen eingesetzt werden.
  • Appium ist in erster Line kein Testautomatisierung Tool sondern zur Automatisierung von mobilen Anwendungen, welches in Verbindung mit eine Testingframework (wie bspw. JUnit, TestNG) zu einem Testautomatisierung Tool wird.
  • Appium kann unteranderem mit den folgenden Programmiersprachen eingesetzt werden:
    • Java
    • C#
    • PHP
    • JavaScript,
    • Ruby
    • Python
  • Appium ist für den agilen Softwareentwicklungsprozess geeignet
  • Appium hat eine große Community
  • Meist eingesetzte Testautomatisierung Tool für mobile Anwendungen
  • Es gibt eine große Anzahl an Reporting Frameworks wie Bspw. Allure-Report und ExtentReports, die in das Testautomatisierungsframework mit Appium integriert werden können
  • Mehr zur Testautomatisierung mit Appium: Testautomatisierung mit Appium
  • Appium Demo Video: Appium kostenfreie Schulung

Katalon Studio

  • Katalon Studio kann kostenfrei eingesetzt werden
  • Kann für die Testautomatisierung von Android, iOS und mobilen Webanwendungen eingesetzt werden.
  • Katalon Studio erfordert keine Programmierkenntnisse.
  • Katalon Studio ist ein Tool für das automatisierte Testen von Webanwendungen, mobilen Anwendungen und Webservices.
  • Link zu Katalon Studio

Testautomatisierung Tools – Web Services

REST-Assured

  • REST-Assured ist eine Open Source API und wird für das automatisierte Testen von RESTful Webservices eingesetzt.
  • REST-Assured kann mit allen JVM-Programmiersprachen eingesetzt werden (wie bspw. Java, Groovy, Scala)
  • Es ist für die agile Softwareentwicklung geeignet und kann mit allen gängigen Continuous Integration Server integriert werden.
  • REST-Assured hat eine mittel große Community
  • Es gibt eine große Anzahl an Reporting Frameworks wie bspw. Allure-Report und ExtentReports, die in das Testautomatisierungsframework mit REST-Assured integriert werden können.
  • Kostenfreie REST-Assured Schulung: Testautomatisierung von Web Services & Micro Services

Coming Soon:

SOAP-UI

Karate

Katalon Studio

 

Performance Test Tools

Coming Soon:

JMeter

Gatling

Loadrunner

Visual Test Automation Tools

Applitools

Galen

 

Softwaretest Anleitung
Softwaretest: Anleitung für den Quereinstig 1800 1200 Jakob R. Jaworski

Softwaretest: Anleitung für den Quereinstig

Dies ist eine Anleitung, um in den Bereich Softwaretest als Quereinsteiger zu starten. Die Anleitung beschreibe die Schritte, die Dir helfen, den Weg als Software Tester in einem Unternehmen zu meistern.

Softwaretest ISTQB Zertifizierung

Gerade als Quereinsteiger im Bereich Softwaretest ist es wichtig nachzuweisen, dass Du die theoretischen Grundlagen beherrschst. Dies kannst Du mit der ISTQB Foundation Level Zertifizierung nachweisen. Wir empfehlen Dir, die Vorbereitung im Selbststudium zum zertifizierten Software Tester abzuschließen. Eine zweite Alternative ist es sich in einer Schulung darauf vorzubereiten. Die Theorie kannst Du Dir mit dem Buch „Basis Wissen Softwaretest“ (*) sehr gut aneignen.  Auf der Lernplattform SmartWebapp kannst Du kostenfrei Musterprüfungen ablegen. Du solltest früh mit den Musterprüfungen beginnen, um so ein Gefühl zu bekommen, wie die Fragen in der Prüfung aussehen können. Auf der Seite Testing-Board findest Du nützliche Tipps, die Dir bei der Prüfungen helfen können Tipps für die Prüfung. Es gibt viele Hochschulen, die eine Vorlesung zur ISTQB Zertifizierung abhalten. Dieses kannst Du oft auch besuchen, wenn Du nicht eingeschrieben bist. Liste Hochschulen

Softwaretest theoretische Grundlagen

Durch die Softwaretest ISTQB Zertifizierung lernst Du die theoretischen Grundlagen. Das Softwaretestzertifikat ist Dein erster Schritt in Richtung Software Tester. Du solltest Dich parallel dazu auch mit dem praktischen Teil des Softwaretests befassen. Im nächsten Abschnitt schauen wir uns an, wie Du praktische Erfahrung im Softwaretest sammeln kannst.

Crowd Testing

Damit Du praktische Erfahrungen sammelst im Softwaretest, empfehlen wir Dich als Crowd Tester bei unterschiedlichen Crowd-Test-Anbieter anzumelden. Hier lernst Du exploratives Testen und wie Du Fehlerreports schreibst. Gute Erfahrung haben wir mit Test.io gemacht. Der Vorteil beim Crowd Testen ist, dass Du für beim Ausführen der Softwaretests bezahlt wirst. Die Bezahlung fällt unterschiedlich aus. Das kostenfreie Buch „How to Test“  wird Dir dabei helfen, praktisch besser zu Testen. Studiere es, während Du praktische Erfahrungen sammelst.

Fundament Softwaretest

Du hast Dir durch das Softwaretestzertifikat und das Crowd-Testen ein gutes Fundament an praktischen und theoretischen Erfahrungen im Bereich Softwaretest aufgebaut. Jetzt wird es Zeit sich mit den nachstehenden Themen zu befassen:

  • Programmierung
  • Webanwendung Grundlagen
  • Testautomatisierung
  • Agile Softwareentwicklung
  • Testen im agilen Umfeld
  • Exploratives Testen
  • Testentwurfsverfahren
  • Webanwendung Frontend
  • Webanwendung Backend
  • Versionskontrollsystem

Programmiersprache

Von einem Software Tester wird heute oft erwartet, eine Programmiersprache für die Testautomatisierung zu beherrschen. Wir empfehlen Dir mit Java zu starten. Java ist die meist eingesetzte Programmiersprache im Bereich Testautomatisierung. Java kann eingesetzt werden, um WebServices, mobile Anwendungen und Webanwendungen automatisiert zu testen. Den Link zu einem kostenfreien Kurs zu Programmierung mit Java findest Du hier: Java Programmierung

Weitere Ressourcen

Java for Tester (*)

Softwaretest Testingframework

Damit Du ein Soll/Ist-Abgleich ausführen kannst, wird ein Testingframework benötigt. In unserer YouTube Serie lernst Du das Testingframework TestNG kennen. TestNG wird sowohl für die Testautomatisierung von Komponententests, Integrationstests als auch End-2-End Tests eingesetzt. In dem späteren Selenium Kurs lernst Du noch das Testingframework JUnit kennen.

TestNG Tutorial 

Webanwendungen Grundlangen

Den meisten Bedarf als Software Tester gibt es im Testen von Webanwendungen. Daher ist es von Vorteil, die Grundlagen von Cascading Style Sheets (CSS) und Hypertext Markup Language (HTML) zu lernen. Dies wird Dir beim manuellen Testen und der Testautomatisierung von Webanwendungen enorm helfen.

CSS/HTML: Einsteiger Kurs YouTube

HTML: YouTube Kurs

CSS: YouTube Kurs

Umfangreicher Online Kurs CSS/HTML

Softwaretest Testautomatisierung

Nachdem Du die Softwaretest- und Programmiergrundlagen gelernt hast, ist es an der Zeit mit der Testautomatisierung zu starten. Von einem Software Tester wird oft verlangt, dass er für die Testautomatisierung verantwortlich ist. Selenium ist ein guter Einstieg in das automatisierte Testen von Webanwendungen. Selenium ist das meist eingesetzte Testautomatisierungstool für Webanwendungen. Wir empfehlen Dir unsere kostenfreien Selenium Kurse auf YouTube. Arbeite erst den Selenium Anfänger zum Profi Kurs durch und dann die Testautomatisierung Design Patten Reihe.

Selenium von Anfänger zum Profi

Testautomatisierung Design Patterns

In den Kursen lernst Du die folgenden Schritte und Technologien:

Testautomatisierung:

  • Selenium konfigurieren
  • Elemente identifizieren
  • Aktionen ausführen
  • Ist/Soll Abgleich mit JUnit und TestNG
  • Screenshots erstellen mit Selenium
  • Testautomatisierung Design Pattern

Technologien:

  • Programmiersprache: Java
  • Testautomatisierung: Selenium
  • Build Management Tool: Maven
  • Testingframework: JUnit
  • Testingframework: TestNG
  • Entwicklungsumgebung: Eclipse
  • Entwicklungsumgebung: IntelliJ

Testautomatisierungsstrategie

Du hast gelernt wie Du automatisierte Testfälle implementierst. Wichtiger ist es, jedoch zu entscheiden was automatisiert getestet werden soll und auf welcher Teststufe. Durch die nachstehenden Ressourcen lernst Du wie Du Testautomatisierung planst, implementierst und worauf Du beim Einsatz von Testautomatisierung achten sollst:

Testautomatisierungsmythen

Kostenfreies E-Book zur Testautomatisierung: The A Word

E-Book über die Planung von Testautomatisierung: Before The Code: First Steps to Automation in Testing

Buch – worauf Du bei der Testautomatisierung achten solltest: Lessons Learned in Software Testing: A Context-Driven Approach (*)

Buch – über den Einsatz von Testautomatisierungspatterns: A Journey through Test Automation Patterns (*)

 Versionskontrollsystem Git

Als Nächstes solltest Du Dich mit Git befassen. Git ist ein Versionskontrollsystem zur Versionsverwaltung von Dateien. In der Testautomatisierung wirst Du täglich mit Git arbeiten, damit Du die Testautomatisierung in einem Team implementieren kannst. Als Software Tester solltest Du die Grundlagen von Git meistern und verstehen.

YouTube Git Crash Kurs

Git Online Kurs

Softwareentwicklung im agilen Umfeld

Durch die ISTQB Prüfung hast Du gelernt, wie Softwaretests in der traditionellen Softwareentwicklung ausgeführt werden. In der heutigen Zeit entwickeln viele Unternehmen Ihre Software jedoch nach dem agilen Framework Scrum. Du solltest die Grundlagen von Scrum beherrschen.

Kurze Einführung zu Scrum

Scrum Guide

Softwaretest im agilen Umfeld

Nachdem Du das agile Framework Scrum kennengelernt hast, wird es Zeit sich mit dem Testen im agilen Umfeld zu beschäftigen.

Growing Agile: A Coach’s Guide to Agile Testing

A Practical Guide for Testers and Agile Teams

Softwaretest exploratives Testen

In der agilen Softwareentwicklung werden selten Testfälle für manuelles Tests geschrieben, oft werden diese automatisiert. Exploratives Testen ist das Erforschen und Experimentieren, um die Anwendung zu hinterfragen, zu modellieren und zu studieren. Du solltest das explorative Testen sehr gut beherrschen. Durch die nachstehenden Ressourcen, kannst Du deine Fähigkeiten beim explorativen Testen verbessern:

Elisabeth Hendrickson: Explore it (*)

Cem Kaner: BBST Exploring Präsentation 

Alan Richardson: How to investigate a Bug 

Testentwurfsverfahren

Während Deines Studiums auf die ISTQB Zertifizierung hast Du einige Testentwurfsverfahren kennengelernt. Damit Du neue Ideen für deine Explorativen Tests genieren kannst, empfiehlt es sich, die Black Box Testentwurfsverfahren zu meistern.

Black Box Testing (*)

50 Quick Ideas to Improve your Tests (*)

BBST Testing Kurs on Test Design 

Softwaretest Frontend

Im Bereich Softwaretest von Webanwendung wirst Du viel mit dem Frontend interagieren. Das Frontend wird Dir im Browser angezeigt und ist der Bereich, mit dem der Nutzer interagiert. Du hast schon die zwei Technologien CSS und HTML kennengelernt. Im Frontend wir oft noch JavaScript eingesetzt. Je mehr Du über die Technologien im Frontend weißt, desto besser kannst Du die Anwendung testen.

Kurs von Alan Richardson: Automating in the browser with JavaScript

Umfangreich JavaScript YouTube Kurs

Tutorial JavaScript YouTube

 

Softwaretest Backend

Du hast das Frontend gemeistert, jetzt ist es an der Zeit sich mit dem Backend zu beschäftigen. Im Backend ist oft die Businesslogik einer Anwendung. Hier solltest Du wissen, was Webservices sind und die Besonderheiten beim Softwaretest von Webservices. In unserer Videoserie Testautomatisierung von Webservices bekommst Du eine Einführung in Webservices, Du lernst die folgenden Technologien kennen:

YouTube Testautomatisierung von Webservices

  • Programmiersprache Java
  • Webservice Testing API: REST-Assured
  • Testingframework: Junit
  • Build Management Tool: Maven
  • Entwicklungsumgebung: IntelliJ IDEA
  • Postman

Weitere Ressourcen:

Automating and Testing a REST API

Tipps für den Bewerbungsprozess

Als Quereinsteiger solltest Du Deinem zukünftigen Arbeitgeber davon überzeugen, dass Softwaretesten Deine Leidenschaft ist. Du hast viel im Selbststudium gelernt. Dies zeigt, dass Du motiviert und lernfähig bist. Im Bewerbungsgespräch solltest Du darauf eingehen, warum Dich dieser Beruf fasziniert. Wichtig sollte sein, dass Du über die Erfahrung berichtest, die Du auf dem Weg zum Software Tester gemacht hast. Welche Technologien und Vorgehensmodelle Du gelernt hast und wie diese Dir beim Softwaretest helfen.

Fazit Softwaretest Quereinstieg

Nachdem Du alle Schritte gemeistert hast, bist Du bereit im Bereich Softwaretest als Quereinsteiger zu starten. Wichtig ist, dass Du nicht versuchst alle Schritte auf einmal zu lernen, sondern die Abschnitte der Reihe nach studierst. Du hast viele Technologien und Vorgehensmodelle kennengelernt, diese solltest Du auch in Deinem Lebenslauf angeben. Die Nachfrage nach Software Testern ist sehr hoch. Dies sind gute Voraussetzungen, um in den Bereich als einzusteigen. Über ein Feedback in den Kommentaren darüber wie Dir der Einstieg in den Bereich Softwaretest gelungen ist, würde wir uns freuen.

 

Die mit Sternchen (*) gekennzeichneten Links sind sogenannte Affiliate-Links. Wenn du auf so einen Affiliate-Link klickst und über diesen Link einkaufst, bekommen wir von dem betreffenden Online-Shop oder Anbieter eine Provision. Für dich verändert sich der Preis nicht. Damit unterstützt Du die Wartungskosten der Testautomatisierung – Gewusst Wie Website

Softwaretesten im agilen Kontext
Softwaretesten im agilen Kontext – Meine Mission 1201 1800 Jakob R. Jaworski

Softwaretesten im agilen Kontext – Meine Mission

In dieser Serie gebe ich meine Erfahrungen weiter, die ich beim Softwaretesten im agilen Kontext gesammelt habe. Ich war in einer großen Anzahl von agilen Softwareentwicklungsprojekten als Softwaretester tätig. In allen Projekten wurde das agile Framework Scrum eingesetzt. In dem ersten Artikel der Serie beschreibe ich meine Mission im Softwaretesten.

Meine Mission beim Softwaretesten

Als Softwaretester im agilen Kontext hat sich ein übergeordnetes Ziel für mich manifestiert. Ich weiß, dass keine Software fehlerlos ist, also ist mein Mission, in kurzer Zeit kritische Fehler zu finden. Alles andere sind Nebeneffekte.

Das Testen nach kritischen Fehlern fängt bei den Anforderungen an 

Als Softwaretester will ich nicht nur zeigen, dass die Anforderung erfüllt sind. Die Anforderungen sind ein Modell der realen Welt, können jedoch davon abweichen. Anforderungen haben drei Zustände:

  • Sie bilden die reale Welt richtig ab
  • Sie weichen von der reale Welt ab 
  • Sie sind unklar definiert

Bilden die Anforderungen die Welt ab, kann nur noch bei der Implementierung eine Abweichung entstehen. Gibt es bei den Anforderungen eine Differenz zwischen Soll und Ist der realen Welt, manifestiert sie sich bei der Implementierung. Sind die Anforderungen unklar definiert, erschwert dies die Implementierung und das Testen und führt oft zu Abweichungen.

Im Scrum-Framework werden die Anforderung in Form von User-Stories definiert. Den ersten Kontakt mit den neuen User-Stories habe ich als Softwaretester meist im agilen Kontext, sobald die User Story im Backlog ist. Bevor das Backlog Refinement Event ansteht, analysiere ich die User-Stories, die im Meeting besprochen werden. Ich hinterfrage die User-Stories kritisch. Damit ich dies tun kann, analysiere ich alle Informationen, die mir zur Verfügung stehen. Dabei stelle ich mir oft unter anderem „Was-wenn“-Fragen. Hier versuche ich, die drei zuvor genannten Zustände zu identifizieren und kläre diese zusammen mit meinem Team ab.

Ich habe die Erfahrung gemacht, dass die meisten kritischen Fehler im Softwareentwicklungsprozess durch unklar definierte oder von der realen Welt abweichenden Anforderung entstehen. Je später ein Fehler im Softwareentwicklungsprozess gefunden wird, desto kostenintensiver wird es, ihn zu beheben. Aufgrund dessen versuche ich, die Abweichung zwischen Soll/Ist-Zustand schon vor der Implementierung zu identifizieren.

Im nächsten Artikel der Serie „Softwaretesten im agilen Kontext“ beschreibe ich weitere Nebeneffekte, die ich mit meinem übergeordneten Ziel abdecke.

Tutorials im Bereich Testautomatisierung von Webanwendungen, mobile Anwendungen und Webservices findest Du im Bereich: Testautomatisierung & Softwaretest Tutorials und auf unserem YouTube-Kanal: Testautomatisierung – Gewusst Wie

Softwaretester bücher und artikel
Softwaretester Must-Reads für den September 1800 1200 Jakob R. Jaworski

Softwaretester Must-Reads für den September

Artikel: Testing and Checking Refined

Was ist Testen und wie unterscheidet es sich vom Checken?  Was ist der Unterschied, zwischem dem ausgeführten check einer Maschine und dem eines Menschen? Diese und weitere Fragen beantwortet der Artikel Testing and Checking Refined von den Autoren James Bach und Michael Bolten

Link zum Artikel: Testing and Checking Refined

eBook: Fifty Quick Ideas to Improve your Test

Du willst wissen, wie Du neue Test-Ideen generieren kannst? Dann ist das eBook Fifty Quick Ideas to Improve your Tests von Gojko Adzic, David Evans und Tom Roden genau richtig für Dich. In dem eBook geht es um 50 praktische Tipps, die eingesetzt werden können, um den Softwaretestprozess zu optimieren.  Das Buch ist die folgenden vier Kategorien unterteilt:

  • Generating Test Ideas
  • Designing good checks
  • Improving testability
  • Managing large test suites

Die Tipps können unabhängig voneinander eingesetzt werden.

Du bekommst das eBook über Leanpub: Fifty Quick Ideas to Improve your Tests 

Buch: A Practitioner’s Guide to Software Test Design

In dem Buch von Lee Copeland geht es um die unterschiedlichen Testentwurfsverfahren. Der Autor beleuchtet die Black Box und White Box-Testentwurfsverfahren und zeigt anhand von Beispielen, wie diese eingesetzt werden können. Die folgenden Testentwurfsverfahren werden behandelt:

Black Box Test Techniken
  • Äquivalenzklassenbildung
  • Grenzwertanalyse
  • Entscheidungstabellen
  • Kombinatorisches Testen
  • Zustandsbasierte Tests
  • Wertebereichsanalyse
  • Anwendungsfallbasierte Tests
White Box Test Techniken
  • Control Flow Testing
  • Data Flow Testing

Alle Testentwurfsverfahren werden mit der folgenden Struktur behandelt:

  • Einführung
  • Erklärung der Technik
  • Beispiele
  • Anwendbarkeit und Einschränkungen

Du findest das Buch auf Amazon als eBook oder Print-Ausgabe.  

Viel Spaß beim Lesen
Jakob R. Jaworski

Tutorials im Bereich Testautomatisierung von Webanwendungen, mobile Anwendungen und Webservices findest Du im Bereich: Testautomatisierung & Softwaretest Tutorials und auf unserem YouTube-Kanal: Testautomatisierung – Gewusst Wie

Testautomatisierungsmythen Teil 2
Mythen der Testautomatisierung Teil 2 1800 2700 Jakob R. Jaworski

Mythen der Testautomatisierung Teil 2

Im ersten Teil der Serie „Mythen der Testautomatisierung“ haben wir beleuchtet, warum Testautomatisierung das manuelle Testen nicht ersetzen kann. Löst die Testautomatisierung alle Probleme die beim manuellen Testen auftreten? Diese und weitere Fragen beantwortet der zweite Teil der Serie.

Testautomatisierung löst alle Probleme

Der Kunde ist unzufrieden mit der Qualität des Produkts? Die Supporthotline läuft heiß, weil die Anwendung zu viele Defekte besitzt? Oft Ist der Irrglaube, dass Testautomatisierung eine Lösung für alle Problem, die im Softwaretestprozess auftreten, ist. Testautomatisierung bewältigt eine Anzahl von Herausforderungen, die bei manuellem Softwaretesten auftreten wie bspw.:

  • Schnelles Feedback über die Qualität
  • Kontinuierliche Ausführung (24/7)
  • Parallele Ausführung

Doch automatisiertes Testen schafft auch neue Herausforderungen wie bspw.:

  • Unzuverlässige Testfälle
  • Erhöhter Wartungsaufwand
  • Know How

Testautomatisierung soll als Unterstützung des Testprozess gesehen werden und nicht als Ersatz. Wenn die Testprozesse vor der Einführung von Testautomatisierung ineffektiv waren, wird sich das bei der Einführung von automatisierten Testfällen nicht entscheidend ändern.

Gute Testautomatisierung erfordert nur die Beherrschung von Testautomatisierungstools

Wie das gute englische Sprichwort heißt „a Fool with a Tool, is still a Fool“. Ein Testautomatisierungstool zu beherrschen, lernt man schnell. Wichtig ist es, eine solide Testautomatisierungsstrategie zu haben, die Fragen beantwortet wie:

  • Welche Testfälle werden automatisiert und auf welcher Teststufe?
  • Wer implementiert die Testautomatisierung?
  • Wer ist der Verantwortliche für die Testautomatisierung?
  • Wann werden die automatisierten Testfälle ausgeführt?

Testautomatisierung ermöglicht es, Personal einzusparen

Eine große Anzahl an Verantwortlichen erhoffen sich Kostenersparnisse, indem sie die Testfälle automatisieren. Wie der erste Artikel „Mythen der Testautomatisierung“ schon klargestellt hat, gibt es einen Unterschied zwischen Testen und Checken. Die Testautomatisierung kann keinen guten Softwaretester ersetzen, sondern nur seine Arbeit unterstützen. Das Hauptziel optimaler Testautomatisierung ist es nicht, Personal zu sparen, sondern eine höhere Testabdeckung  zu erreichen. Durch die Automatisierung von Testfällen haben die Softwaretester Zeit, sich auf die wichtigen Risiken des zu entwickelnden Produkts zu konzentrieren.

„End-2-End Testfälle sind unnötig“ versus „Wir automatisieren alles als End-2-End Testfall“

Automatisierte End-2-End Testfälle (Systemtests) sollten vermieden werden, 
End-2-End Tests testen die ganze Anwendung meist über die Benutzeroberfläche. Dies führt dazu, dass die automatisierten Testfälle langsamer und wartungsaufwendiger sind. Seit einigen Jahren wird propagiert, dass automatisierte End-2-End Tests deswegen vermieden werden sollen.  End-2-End Testfälle haben jedoch ihre Daseinsberechtigung. Sie beantworten die Frage: „Kann der Nutzer die gewünschten Aktionen oder das Szenario ausführen?“. End-2-End Tests können in den meisten Fällen parallel ausgeführt werden, was das Argument der langsamen Ausführung von End-2-End Testfällen zum Teil revidiert. Durch den Einsatz von Design-Patterns kann man den Wartungsaufwand reduzieren. Wichtig ist es, eine optimale Verteilung der automatisierten Unit-Tests, Integrationstests und End-2-End Tests zu erreichen.

Wir können alles als automatisierten End-2-End Testfall implementieren, deswegen machen wir das. End-2-End Testfälle sind nicht darauf fokussiert, um Fehlerzustände in einzelnen Komponenten oder in der Businesslogik zu identifizieren. Wenn eine Fehlerwirkung auftritt, dauert es oft lange, bis der Fehlerzustand identifiziert ist. Ein Testfall ist eine Frage, die wir der Anwendung stellen. Um so präziser unsere Frage, desto genauer sind die Informationen, die wir erhalten. Ein automatisierter Testfall sollte in der Regel eine konkrete Frage beantworten. Wenn ich Fragen zur Businesslogik habe, ist es meist fokussierter dies über die API zu machen. Will ich wissen, ob die einzelnen Komponenten den Anforderungen entsprechen, ist es meist fokussierter, dies auf der Unit-Test-Stufe zu tun.

Fazit

Der Testprozess sollte vor der Einführung von Testautomatisierung optimiert sein. Automatisierte Testfälle sollen das manuelle Testen nicht ersetzen, sondern unterstützen. Testautomatisierung soll in erster Linie nicht Personal einsparen, sondern eine höhere Testabdeckung ermöglichen. Automatisierte Testfälle sollen fokussiert sein.

Tutorials im Bereich Testautomatisierung von Webanwendungen, mobilen Anwendungen und Webservices findest Du im Bereich: Testautomatisierung & Softwaretest Tutorials und auf unserem YouTube-Kanal: Testautomatisierung – Gewusst Wie

 

Back to top
Wir benutzen Cookies um die Nutzerfreundlichkeit der Webseite zu verbessen. Durch Deinen Besuch stimmst Du dem zu.