Eine Frage, die vermutlich jedem Softwaretester irgendwann begegnet: wann habe ich genug getestet? Oder: wann…
In älteren Beiträgen habe ich bereits über meinen Quereinstieg als Softwaretester berichtet. Inzwischen sind zwei…
In der Softwareentwicklung hat es sich schon lange etabliert, zwischen Frontend-, Backend- und Fullstack-Entwicklern zu…
Testautomatisierung – Fester Bestandteil der agilen Softwareentwicklung Testautomatisierung ist ein fester Bestandteil der agilen Softwareentwicklung.…
In einem früheren Artikel habe ich bereits geschildert, wie mir der Quereinstieg als Software Tester…
Dies ist eine Anleitung, um in den Bereich Softwaretest als Quereinsteiger zu starten. Die Anleitung…
In dieser Serie gebe ich meine Erfahrungen weiter, die ich beim Softwaretesten im agilen Kontext…
Artikel: Testing and Checking Refined Was ist Testen und wie unterscheidet es sich vom Checken? …
Es gibt mittlerweile eine große Anzahl an Büchern, Artikeln und Tutorials über das Softwaretesten. Damit…
Wie der Quereinstieg als Testautomatisierer unserer Meinung nach am besten funktioniert, haben wir bereits in…
In der Softwareentwicklung hat es sich schon lange etabliert, zwischen Frontend-, Backend- und Fullstack-Entwicklern zu…
Testautomatisierung – Fester Bestandteil der agilen Softwareentwicklung Testautomatisierung ist ein fester Bestandteil der agilen Softwareentwicklung.…
Testautomatisierung Tools für Webanwendungen Umfassende Zusammenfassung von Testautomatisierung Tools für Webanwendungen, mobilen Anwendungen und…
Im ersten Teil der Serie „Mythen der Testautomatisierung“ haben wir beleuchtet, warum Testautomatisierung das manuelle…
Es gibt viele Mythen im Bereich der Testautomatisierung. In dieser Serie beleuchten wir die häufigsten…
Testautomatisierer werden per Quereinstieg. Geht das? Die agile Softwareentwicklung verlangt nach schnellem Feedback über die…
Testautomatisierung mit Selenium Selenium ist das meist eingesetzte Testautomatisierungstool für Webanwendungen. Doch ist Selenium ein…
Testautomatisierung von mobilen Anwendungen mit Appium In dieser Folge der Serie Testautomatisierungstools für mobile Anwendungen…
In älteren Beiträgen habe ich bereits über meinen Quereinstieg als Softwaretester berichtet. Inzwischen sind zwei…
In einem früheren Artikel habe ich bereits geschildert, wie mir der Quereinstieg als Software Tester…
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.
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.
User Elham Jamal beantwortet in diesem populären Beitrag auf LinkedIn die Frage nach dem Testende mit harten Testendekriterien:
Angemerkt sei, dass er keinen Bezug auf das agile Vorgehensmodell nimmt. Ich möchte die einzelnen Kriterien dennoch im agilen Kontext diskutieren:
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.
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.
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.
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.
Im ersten Artikel dieser Serie habe ich berichtet, mit welchen Grundlagen ich als Quereinsteiger in der Qualitätssicherung startete. Mein zweiter Bericht beschäftigte sich damit, wie ich mich in das Umfeld der Softwareentwicklung einlebte. Hierbei bin ich auch darauf eingegangen, wie ich mich an die Zeremonien des agilen Arbeitens gewöhnte. 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.
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.
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: 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.
Falls Du Dich für den Quereinstieg ins Softwaretesten interessierst, haben wir genau die richtige Ausbildung für Dich: Vom Quereinsteiger zum Softwaretester.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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:
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!
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.
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.
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.
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.
Falls Du Dich für den Quereinstieg ins Softwaretesten interessierst, haben wir genau die richtige Ausbildung für Dich: Vom Quereinsteiger zum Softwaretester.
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.
Coming Soon:
Robot Framework
Cypress
Geb
TestCafe
Coming Soon:
SOAP-UI
Karate
Katalon Studio
Coming Soon:
JMeter
Gatling
Loadrunner
Applitools
Galen
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.
Falls Du eine Ausbildung zum Softwaretester suchst, in der Du nicht alles im Selbststudium lernen musst, sondern mit der richtigen Unterstützung schneller an Dein Ziel kommst, dann empfehlen wir Dir die Qcademy
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:
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.
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:
Technologien:
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:
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.
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.
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.
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
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
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.
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
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.
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:
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
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
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:
Die Tipps können unabhängig voneinander eingesetzt werden.
Du bekommst das eBook über Leanpub: Fifty Quick Ideas to Improve your Tests
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:
Alle Testentwurfsverfahren werden mit der folgenden Struktur behandelt:
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
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.:
Doch automatisiertes Testen schafft auch neue Herausforderungen wie bspw.:
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.
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:
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.
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.
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
