A dry tester

When I started my career as a tester 20 years ago in a telecom company I used to dig into several specification documents before I start testing. I saw my duty as a tester, was to find out the points where our services (roaming, data transfer, video calls) do not conform to the standards. What I didn’t consider at all was how the people will use those services and how they would feel if the service fails. I had no empathy for the user. Testing was for me a thing for the lab. I was a dry tester.

An empathetic tester

This started to change over the years and the peak came when my company introduced Scrum as the new way of working. The biggest change for me was that the colleagues didn’t produce functional specifications documents anymore. For me, it was like a hangover. An empty space in my testing brain. I had lost my test oracle. And the Functional Specifications document was not only an oracle for me. It was the 10 commandments. How am I going to find orientation now?
Our agile coach told me that the test oracle is now the end-users. I have to compare the test results with what a user expects from the service. I had to get on the shoes of the user in order to find what they expect. But the word user was very impersonal for me, so I thought of my friends. How do they use video calls for example? I ask my manager how he uses it with other managers. By interviewing persons from different areas I’ve got a good understanding of what scenarios I needed to test. Being an end-user by myself has given me the empathy I lacked before.

A curious tester

Since then I have changed several companies. The first thing I do in the new company is to learn the product through the regression tests. Then I use it by myself and in parallel, I find other people who use it and get to know how do they utilize it and how they feel. I collect in this way scenarios and bottlenecks from the user perspective which I transform in test cases.

An agile tester

Well, I would have been happy if I would have done so but I didn’t. I lied. In the agile era, I use to work on several test levels and different test techniques, mostly automation. My sprint calendar, as an agile tester, is like this:

Automate tests for new features
Automate tests for customer bugs
Fix older broken tests
Setup simulations
Write performance tests
Write Unit tests
Support Backend if needed
Setup metrics
Setup tools like Jenkins/Grafana/Redis

In the agile era, as a tester, I have lost my focus on the product as an end-user. I have no time for that. I became a dry tester again. Instead of the empathetic tester, I used to be, I am now a tester under pressure to reach a release.

A tester as an orchestrator of quality

In the #agiletestingdays I had an aha effect. Yes, it is possible to gain back my stolen fun. The conference made the following things clear to me.
I am more than just a tester.
I can get out of my box and orchestrate a team.
I can talk the way the strong POs and C-level can understand.
I can keep different statistics than only the critical bugs.
I have to clear or to fix the broken tests otherwise nobody cares anymore.
I can make the broken pipeline an issue for the team, not only for testers.
I can look beyond the functionality and think of security and ethics.
QA is a battle, after the strategy we need a plan.
Every agile tester is also a test manager.
AI, why not?
Test strategy can be useful if it is tailored to the person who reads it.
Gamify the tests by interviewing the product
Synthetic Monitoring: a replacement of acceptance tests or an indication?
Shadow run: testing directly in production.
All those aspects have revived in me the spark of joy during testing. I can be an empathetic tester again. However, in order to achieve that, I need to be an orchestrator, so that the whole big thing of testing will gain the significance it deserves besides the development of new features. It’s all about how I perceive myself. Am I just a tester or an orchestrator of quality?