Beiträge

Agile Test Engineers bei TechTalk: ein Blick hinter die Kulissen

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 Du mehr zur Position des (Senior) Test Engineers, zu unseren Trainings oder generell zur TechTalk erfahren?

Questions About Test Frameworks: Q&A Part #3 with J.B. Rainsberger

This is the third chapter of our three-part Q&A blog series with J. B. Rainsberger. In this chapter he adresses questions about „Questions About Test Frameworks. The first chapter and the second chapter is in our blog in case you missed it.

On June 3, 2020 J.B. Rainsberger spoke in our remote Intro Talk about managing the various kinds of uncertainty that we routinely encounter on projects that involve legacy code. He presented a handful of ideas for how we might improve our practices related to testing, design, planning, and collaboration. These ideas and practices help us with general software project work, but they help us even more when working with legacy code, since legacy code tends to add significant uncertainty and pressure to every bit of our work. Fortunately, we can build our skill while doing everyday work away from legacy code, then exploit that extra skill when we work with legacy code.


J. B. Rainsberger helps software companies better satisfy their customers and the business that they support.

Our next remote course Surviving Legacy Code from 14-17 September 2020.


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.


➡️ Also read our last two Q & A Blogposts with J.B. Rainsberger Part #1 „Managing the Uncertainty of Legacy Code“ and Part #2 „The Risks Related to Refactoring Without Tests„! Follow us on Twitter or LinkedIn to get new posts.


Vortrag bei Vienna Mobile Quality Crew

image

© Foto by Rudolf Groetz

Andreas Willich und Christian Hassa waren letzte Woche (wie angekündigt) bei der Vienna Mobility Quality Crew zu Gast und haben einen Vortrag zu Cross Mobile Testautomation mit Xamarin & Specflow gehalten.

Der Bogen spannte sich über die Abstraktion der mobile Plattformen Android und IOS, dem Problem der iOS-UX-Jünger mit XAMARIN Forms und der Vorteile einer gemeinsamen Programmiersprache, hinüber in die Welt der Testautomation über das Mobile-UI als auch Testautomation auf dem Controller-Level. 
– Aus dem Blog zum Vortrag von Vienna Mobily Quality Crew

Die Slides von Christian findet ihr auf Slideshare, ein Video des Vortrags ist noch in Produktion und werden wir hier ergänzen sobald online!

Weitere Fotos vom Event gibts auf der zugehörigen MeetUp Page. Wir bedanken uns für die Einladung und empfehlen die Teilnahme an den MeetUps. Interessierte können sich über das Programm und die Zielsetzungen der Vienna Mobile Quality Crew auf der MeetUp Page informieren. Bisherige Events werden im zugehörigen WordPress Blog besprochen.

Die besprochenen Tools im Vortrag:

MeetUp: Cross Mobile Test Automation with Xamarin and SpecFlow

Die Vienna Mobile Quality Crew veranstaltet gemeinsam mit SIXSENTIX  und Techtalk am 23.4.2015 um 18:00 einen Vortrag zum Thema Cross Mobile Test Automation with Xamarin and SpecFlow.

Teilnahme kostenlos! Get the details!