Testing for non-testers: Ein Quereinstieg mit Plan

QualityMinds | Blog

Für einige Menschen kommt irgendwann der Punkt, an dem man seine berufliche Laufbahn in Frage stellt, eine Job-Midlife-Crisis quasi. So auch bei mir. Veränderung und immer etwas Neues zu lernen war mir schon immer wichtig. Daher habe ich auch in beruflicher Sicht eine kleine Evolution durchgemacht: Account Manager in einer Online Werbeagentur, Projekt Manager, Product Manager im Online Marketing, CRM Manager. Aber irgendwie fehlte immer ein wenig, um zu 100% zufrieden zu sein.

Was mich mit jedem Jahr Berufserfahrung immer mehr interessierte, war der Blick hinter die Kulissen dessen, was im Frontend passiert. Fragen stellen konnte ich auch schon immer gut – zum Leidwesen der Kollegen. Ich habe mein Netzwerk gefragt, wer Quereinsteiger in die IT-Branche anstellen würde und so kam ich bei QualityMinds an.

Nach den Meet the Minds Days, an denen ich mein Tester-Gen gleich in der Praxis unter Beweis stellen musste, war klar: ich will Software Tester werden! Endlich darf ich mit kritisch-prüfendem Blick Dinge in Frage stellen – und alle freuten sich auch noch darüber. Bereits in dieser Kennenlernphase habe ich neue Tools und erstes Testerwissen kennengelernt, z.B. eine Mindmap, mit der ich meine Teststrategie für das Testobjekt festhalten sollte. Ich habe gleich meinen ersten “echten” Test durchgeführt, bei dem ich als Bugreporting-Tool Excel benutzt habe, um die Fehler zu dokumentieren, Screenshots festzuhalten und die Testschritte zur Reproduktion durch die Entwickler aufzuschreiben. Nach der Behebung der Bugs erfolgte dann deren Nachtest.

Ich habe festgestellt, dass Excel als Reportingtool gar nicht so unüblich ist. In einem meiner Projekte war das Projektumfeld noch nicht “ausgereift” genug, um sich mit professionellen Tools auseinanderzusetzen. Daher gab es zum Beispiel die bestehende Test-Suite nur in Excel und der Bug-Report erfolgte über Jira, das gleichzeitig der einzige Weg war, sich mit den Entwicklern in UK zu unterhalten. Neue Testfälle wurden daher nicht oder nur rudimentär in den Tickets festgehalten, was auch die Regressionstest nicht immer einfach machte. Eine gelebte Struktur und das Festhalten von Metriken in Sachen Test mussten in diesem Projekt erst etabliert werden, was mir als explorativer Tester die Freiheit gab, meinen eigenen Weg zu gehen. Meist nutzte ich daher, sofern nicht die Smoketests auf der (Vor-)Produktivumgebung anstanden, eine session-basierte Herangehensweise, die es mir ermöglichte, jeweils ganz fokussiert einen bestimmten Teilbereich der Software zu testen.

In einem anderen Projekt habe ich dazu das Gegenteil kennengelernt: hier gab es für (fast) alles feste Regeln. Zudem hatte ich dort meine ersten Berührungspunkte in agilen Arbeitsweisen. In unserem Daily wurde besprochen, was man tags zuvor gemacht hatte, für den heutigen Tag anstand und ob es Impediments gab oder gibt. In definierten 2-Wochen Sprints wurden dann die Arbeitspakete abgearbeitet. Am Ende des Sprints wurden in der System-Demo die erarbeitete Features vorgestellt und besprochen. In diesen hat sich immer gut gezeigt, ob unsere Schätzung der Features realistisch war oder ob nicht alles entwickelt und getestet werden konnte. Für mich als Tester waren die Anforderungen durch die Abnahmekriterien, die in den Stories in Jira hinterlegt waren, klar definiert, was mir im Testdesign geholfen hat. Ergänzend konnte ich weitere Informationen aus dem Fachkonzept entnehmen und diese für das Testkonzept nutzen.

In diesem Projekt wurden alle durch mich geschriebenen Testfälle in dem Tool “Aqua” dokumentiert, zu den entsprechenden Anforderungen im Tool verknüpft und dann in einem Testszenario zusammengestellt und ausgeführt. Auf diese Weise war für mich und den Product Owner sowie das Management klar, welches Feature mit welcher Intensität in welcher Umgebung getestet wurde. Ergänzt wurde diese Trackability auf Testfall- bzw. Feature-Ebene durch die Tool eigene Reportingfunktion, die unterschiedlichste Metriken auswerten und graphisch darstellen kann.

Eine weitere wertvolle Erfahrung war es, sich mit den Entwicklern direkt austauschen zu können, da wir in einem Scrum Team zusammengearbeitet haben. Indem wir uns regelmäßig feste Zeitfenster eingerichtet haben, in denen ich als Tester ein bestimmtes Feature getestet habe und ein Entwickler direkt meine Fragen und Anmerkungen beantwortete, konnte nicht nur schnell die Qualität der Software verbessert werden, sondern auch das Denken des anderen besser verstanden und damit die Zusammenarbeit produktiver gestaltet werden.

Um mir als Quereinsteiger den Start in die Thematik des Testens zu erleichtern, haben mir meine Kollegen vor dem Start in den Projekten nicht nur vieles ad hoc erklärt, sondern mir mit dem Leitfaden Testing for non-testers eine sehr hilfreiche und praxisorientierte Ausbildung an die Hand gegeben. Testarten, Testverfahren, Testmanagement, Teststufen und Software Entwicklungszyklen: so viele neue Begriffe, die ich nach und nach im Laufe dieser Ausbildung kennen und anwenden gelernt habe. Darüber hinaus hat es auch immer geholfen, dass mir meine Kollegen die Parallelen aus meinen vorherigen Jobs aufgezeigt haben denn Qualitätssicherung war in allen Jobs wichtig. Und um nichts anderes geht es ja auch beim Testen, nämlich die Qualität des Produkts zu verbessern. Auch der zügige Start in mein erstes Kundenprojekt hat dazu beigetragen, das Erlernte in die Praxis umzusetzen – neben dem Pauken für die ISTQB Zertifizierung.

Rückblickend kann ich sagen, dass ich, als ich endlich den Schritt zum Quereinstieg gewagt habe, alles richtig gemacht habe und Glück hatte, dass ich bei QualityMinds die Gelegenheit dazu bekommen habe. Ich lerne jeden Tag dazu nicht nur da ich von Banken-Software bis hin zu einer Plattform für Mietfahrzeuge immer wieder neue Kontexte kennenlerne, sondern auch weil meine erfahreneren Kollegen ihr Wissen und ihre Erfahrung bereitwillig mit mir teilen. Mittlerweile habe ich vom explorativen, fachlichen Testen, Testmanagement und Testdesign eine solide Basis aufgebaut, die ich nun stetig ausbauen und vertiefen kann. Und aktuell darf ich in die Test-Automatisierung reinschnuppern und mich mit Gherkin, Java und Cucumber auseinandersetzen – langweilig wird es also nie.

0 Kommentare

Activities of the Podstawy Testowania

Geschrieben von

Iza Wilkosz