Why, of all things, does one become an Agile Tester?

My interest in software development has always gone above and beyond programming – and even if it does go hand-in-hand, without programming know-how, testing is not really possible.

 

What kind of qualifications are needed?

Testing is a very broad field. Its not enough to just understand a programming language. You have to understand the logic and risks as well. It is really important for testers to have a good level of communication with the developers. You have to be careful and sensitive enough to point out mistakes to your colleagues without insulting their coding abilities.

 

What’s your daily business?

Well, fundamentally, we are responsible for the testing of software throughout the entire lifecycle – whereby the focus is in on quality assurance. Among my tasks is also to sharpen the understanding of quality in our teams, introduce new tools, and in the end: to execute testing in all its facets.

 

What are the facets of testing?

The establishment of Code Reviews and Unit-Tests in the developer teams, the implementation of static Code-Analysis, automation of Functional Tests in order to test User Stories, explorative and manual testing of End-to-End-Tests, UX and Design Tests all the way to Prototypes, Load Tests (non-functional) and Penetration Tests.

 

It seems to be a very broad field.

You can explain the types of tests using pyramid or a testing quadrant.

When you look at the testing quadrant, you’ll see that 4 types of tests are defined within it. In the first quadrant, the code is tested. In the second quadrant, functional Example Tests and Story Tests are represented, i.e. GUI and API-Tests. Here a Behaviour-Driven-Development approach is ideal – according to which, the features of certain scenarios are defined which are typical of user interactions.

 

What kind of scenarios?

One describes these scenarios sing the das Given-When-Then principle. According to this the prerequisites are determined that need to be fulfilled (GIVEN), and then we look for which actions need to implemented (WHEN) in order to reach the expected outcome (THEN).

 

Who defines the prerequisites?

The scenarios are defined by the product owner and development team in a planning or estimation meeting. In practice, the 3-Amigos model has prevailed. In it, at least one developer, a tester and a product owner have to be involved in the definition in order to ensure that various points of view are included: “What do we want”, How can we achieve it” and “How can I break it?”

 

What about test automation?

Test automation is very important for us. Because we work with multiple iterations and therefore have frequent releases, we have to test the same components often. In order to ensure fast response, we rely on automation of the tests that are required more frequently. We use Cucumber as a test automation tool, which is already described by the GUI-Test and defined according the BDD-Framework. In this tool we write various scenarios in every day language that are to be tested and which are then linked to functions with regular phrases. For example, you can take the scenario “When I log in” – Cucumber then searches for the Java functions that have to be called up for that scenario.

 

Back to the testing quadrants: which tests can be found in quadrants 3 und 4?

The third quadrant is dedicated to the explorative, manual tests which look at user acceptance. And last but not least, in the fourth quadrant, one takes a look that the Load and Performance and Security Tests. In the Security Tests, we recreate the active attempt to hack the software. In Load and Performance Tests, a large user load is simulated in peaks that have been previous determined.

 

What kind of testing project are you working on at the moment?

Most recently I was working on a project for a client’s central platform in China. We had to test several services in load scenarios. In more specific terms this means: what happens when a large number of vehicles all access multiple services at the same time? Due to the fact that cars access services from the central platforms in different ways, load tests are very complex in this scenario. We used a so-called Grinder in this case, which runs the test 100 times per second for example, in order to ascertain if the service still functions under a certain load. Testing plays an increasingly important role for our clients because we work with software that is critical and highly security relevant – and which also has high user numbers. That means that maximum quality is essential.