testing Archive - TechTalk - Individualsoftware-Entwicklung nach agilen Methoden

In unserer Interviewserie “Get to know TechTalk” stellen wir TechTalk Mitarbeitende vor. Heute unterhalten wir uns mit Agile Test Engineer Philip Rockenbauer, der seit Februar 2018 Teil des Teams ist. Wie er seine Projekte meistert oder welche Technologien und Werkzeuge dabei zum Einsatz kommen, erfährst du in diesem Interview.

Was ist dein aktuelles Aufgabengebiet in der TechTalk?

Ich arbeite in einem Team aufgeteilt auf Product Owner, Developer und Test Engineers. Wir sind für verschiedene Projekte mit unterschiedlichen Kunden zuständig. Je nach Größe dauern manche Projekte nur wenige Monate, manche laufen aufgrund der Wartung auch mehrere Jahre. Gemeinsam mit einer Kollegin bin ich für das Testing im Team verantwortlich. Das beinhaltet hauptsächlich das Abschließen von manuellen Tests sowie die Unterstützung der Developer bei der Testautomatisierung. Zudem organisiere ich unter anderem TechTalk-interne Testing Veranstaltungen.

Was fasziniert Dich am Testing?

Am meisten Spaß am Testen macht mir das Erforschen einer Anwendung. Manchmal hat man das Gefühl, ein Puzzle lösen zu müssen. Man sucht Probleme sowie deren Zusammenhänge und versucht, diese mit seiner Erfahrung sowie Kreativität zu lösen. Spannend finde ich vor allem auch, dass nicht alles vorgegeben ist und man sehr selbständig arbeitet.

Was macht für dich einen guten Tester aus?

Man sollte aufgeschlossen für Neues sein und Spaß am Entdecken einer Anwendung haben. Das Mindset sollte nicht „make-it-work“ sondern „break-it“ lauten. Ein guter Tester analysiert Probleme, geht diesen auf den Grund und nimmt nichts als gegeben hin. Außerdem ist es wichtig, Selbstdisziplin mitzubringen. Das heißt, man forscht intensiv nach, hinterfragt vieles und deckt nicht nur den Happy Path ab. Der Happy Path ist das einfachste Szenario, bei dem die Anwendung funktioniert und wäre nur das Minimum. Es gibt jedoch auch Spezialfälle und das Kreative an der Position des Test Engineers ist es, sich diese einfallen zu lassen. Außerdem ist es wichtig, im Team gut zusammenzuarbeiten, dabei ist viel Fingerspitzengefühl gefragt wenn es um Feedback zu Fehlern in der Anwendung geht.

Wie arbeitest du im Team?

Generell arbeiten wir in unserem Team agil, dabei kommen je nach Projekt entweder Scrum oder Kanban zum Einsatz. Als Tester ist man in konstantem Austausch mit Product Ownern sowie Developern. Akzeptanzkriterien werden abgeklärt und sobald etwas gefunden wird, wie zum Beispiel ein Fehler in der Anwendung, wird in Absprache mit dem Product Owner entschieden, ob dieser behoben werden muss oder nicht. Manchmal verhält sich das System nur anders als erwartet und es ist unklar, ob wirklich ein Fehler vorliegt. Mit den Devs werden die Findings besprochen und dann Bugreports erstellt.

Mit welchen Testarten und -verfahren arbeitest du?

Bevor der Entwicklungsprozess beginnt, schaue ich gemeinsam mit dem Product Owner die Kundenanforderungen durch und prüfe, ob diese Sinn machen, wie wir sie testen würden und ob weitere Informationen benötigt werden. Als Tester brauche ich konkrete Spezifikationen, damit nachher keine Fragen auftauchen. Im Idealfall definiere ich Testszenarien in Form von Gherkins. Diese werden dann als Basis für die Entwicklung der automatisierten Tests verwendet. Manuelles Testen mache ich häufig explorativ. Generell führe ich unter anderem oft auch Regressions- sowie Smoke Tests durch.

Welche Technologien und Werkzeuge kommen in deinem Projektalltag zum Einsatz?

Wir arbeiten täglich mit Azure DevOps und verwenden es als Tool für Taskboards, um Fortschritte festzuhalten und als Build Pipeline, von der wir auf unsere Testumgebung deployen. Auch Pull Requests werden darüber ausgeführt. Außerdem nutzen wir Git Repository für unsere Projekte. Ich verwende das unter anderem auch, wenn ich etwas lokal deployen muss oder um Commitments zu überprüfen. Zudem kommt SSMS zum Einsatz, um etwa SQL Statements in Datenbanken zu kontrollieren bzw. zu verändern. Wenn ich Schnittstellen teste, verwende ich SoapUI und Postman. Für die automatisierten Tests nutzen wir SpecFlow.

Wie hältst du dich selbst am Laufenden und wie tauschen sich Software Tester untereinander aus? Wie fördert die TechTalk den Wissensaustausch?

Ich selbst halte mich unter anderem durch die von TechTalk organisierten Trainings am Laufenden. Da jeder Mitarbeitende ein individuelles Weiterbildungsbudget hat, besuche ich diese je nach Interesse. Außerdem hat die TechTalk eine Lizenz für das Testing Hub „Ministry of Testing“, da höre ich mir immer wieder Vorträge an. Zusätzlich haben wir in der TechTalk einen monatlichen Austausch, bei dem sich Testerinnen und Tester, aber auch alle, die Interesse am Testing haben, zusammensetzen. Da besprechen und diskutieren wir diverse Erfahrungen und lernen projektübergreifend voneinander. Außerdem tragen unterschiedliche Formate wie Pizza Talks, TechDiscuss oder Tech & Talk Sessions zum Wissensaustausch bei.

Warum passt die TechTalk so gut zu dir und was sind deine persönlichen Highlights?

Eines der Highlights und auch einer der Punkte, die ich an der TechTalk sehr schätze, ist die wirklich gute Zusammenarbeit aller Mitarbeitenden. Dies betrifft nicht nur das Projektteam, sondern generell den zwischenmenschlichen Umgang aller TechTalker miteinander. Zudem war ich sehr positiv überrascht von der großen Wertschätzung, die man ab Tag 1 spürt. Man kann wirklich von einem kollaborativen agilen Team sprechen, in dem jeder gefordert ist.

Man bekommt außerdem ein gutes Maß an Verantwortung. Das zeigte sich bereits, als ich mein Praktikum machte. Ich war als einziger Tester im Projektteam, hatte jedoch jederzeit einen Coach sowie Buddy an meiner Seite. Beim Start bekommt man zusätzlich einen Mentor zur Verfügung gestellt. So kann man die Arbeitsweise der TechTalk kennenlernen und hat von Anfang an eine Person, die einem jederzeit weiterhilft. Zudem wird die Weiterentwicklung stark gefördert. Von Anfang an schaut man nicht einfach zu, sondern bringt sich aktiv ein. Ein weiterer wichtiger Punkt für mich ist das bereits angesprochene Weiterbildungsbudget. Dadurch hat man die Möglichkeit, je nach Interesse Konferenzen, Trainings oder Workshops zu besuchen.

Möchtest auch du Teil der TT Familie werden?

Dann sieh dir hier die aktuellen Jobausschreibungen an:

Jetzt Jobpostings anschauen

If the code base is too old even for any available test frameworks, how you handle it?

**Testing does not need frameworks. Testing never needed frameworks.** You can always start by just writing tests and refactoring them. If you do this long enough, you will extract a testing framework. If you’ve never tried it, then I recommend it! Kent Beck’s _Test-Driven Development: By Example_ included this exercise.

Every test framework began life with `if (!condition) { throw Error(“Test failure.”) }`. If you can write this, then you can build a testing framework; if this suffices, then you don’t need a testing framework. Start there!

If you can execute one part of the system in isolation from the rest, then you can write unit tests. In the early days of web browsers, we could only execute Javascript in the browser, because even so, we could (and did!) write unit tests without frameworks. We merely had to run those tests in a browser window. Eventually, someone decided to run Javascript outside the browser, which made it easier to write microtests for Javascript code. This made it _easier_ to write tests, but we were writing tests long before NodeJS existed.

If you can invoke a function (or procedure or division or block of code) and you can signal failure (such as by raising an error), then you can write tests without waiting for someone else to build a framework.

In addition, you don’t need to write your tests in the same language or environment as the running system. Golden Master technique helps us write tests for any system that offers a text-based interface. Any protocol could help us here: for example, think of HTTP as “merely” a special way of formatting requests and responses with text. If you have (or can easily add) this kind of interface or protocol to your system, then you can write tests in any language that might offer a convenient test framework. Use Python to test your COBOL code. Why not?

Finally, not all testing must be automated. As I wrote earlier, programmers have a strong habit of forgetting alternatives to techniques that they’ve found helpful. If you don’t know how to automate your tests easily, then don’t automate them yet. Instead, make them repeatable and document them. One day, someone will have a good idea about how to automate them.

You may have to write your own test framework but it can prove a daunting task.

In addition to what I wrote in the previous answer, I encourage you to follow the general advice about building any software with a Lightweight (Agile, Lean, …) approach: build the first feature that you need, then start using it, then add more features one at a time. You don’t need to build a fully-featured testing framework before you start to benefit from it. Start with `if (!assertion) throw Error()` and then use it! The testing framework SUnit was built incrementally. All the testing frameworks you know began from there. You can do it, too. Merely start, then take one step at a time.

You also need this refactoring-without-tests skill, to effectively refactor your tests!

Maybe! I don’t say you _need_ it, but it would probably help you. Your production code helps you to refactor your tests: if you change your tests and they now expect the wrong behavior, then your production code will fail that test for “the right reasons”. It doesn’t provide perfect coverage, but it helps more than you might expect. In that way, the production code helps to test the tests.

There are testing frameworks for COBOL and NATURAL. What could be older?

Indeed, the “framework” portion of testing relates to identifying tests, collecting test results, and reporting them in a unified way, as well as adding standard mechanisms for “set up” and “tear down”. We don’t need those things to start writing tests, although eventually we will probably want to have them. **Simply start writing tests, then remove duplication in any way that your programing language allows.** I don’t know what might be older than COBOL or NATURAL.

Schlagwortarchiv für: testing

Agile Test Engineers bei TechTalk: ein Blick hinter die Kulissen