Job profile of a tester

The job description of testing describes the tasks, skills and positions required today to ensure software quality in agile teams. Quality is no longer an individual responsibility, but a team task. Analytical, technical and planning skills are required, which different people in the team take on depending on the project situation.

Key Takeaways

Testing is no longer a one-person job: In an agile team, every member is responsible for quality, regardless of whether “tester” is on their business card.
Developers already unconsciously apply test methods such as equivalence class analysis and decision tables when they set up if-then-else structures without calling it that.
Planning and management skills remain essential in agile teams: those who run Scrum without a plan will fail, even if the role of “test manager” no longer officially exists.
Knowledge alone is not enough: according to the German Testing Board, experience, i.e. having actually applied concepts and experienced their effect, is the more decisive competence.
The German Testing Board’s job description for testing is available as a free download and provides both individuals and managers with a structured basis for career planning and team composition.

The profession of tester is changing, testing remains

The requirements for testers are not changing. What is changing is the way teams work. This is precisely the shift that testers are facing today.

Testers used to work sequentially. A tester received the finished requirements, then the software that someone else had built. They wrote their test cases, found bugs and reported them. Each activity was assigned to one person, clearly delineated, one after the other.

This model no longer works in agile teams. It was never really good before. What was missing was collaboration: an early exchange with colleagues and a shared understanding of what testing actually is.

The core lies in a slight reformulation. It’s not about the tester as a person, but about testing as an activity that needs to be done to ensure quality. Who carries out this activity is a second question.

Why testing today is a team task

Quality is created in a team, not by an individual role. The whole-team approach hits this point exactly: not one person is responsible for quality, but everyone together.

The reason for this lies in the way we work. When a team develops in small increments, individual features instead of a finished product, the requirements for what needs to be done are constantly changing. Sometimes a database needs to be set up, sometimes an interface needs to be expanded, sometimes an interface between the frontend and backend needs to be installed, sometimes a component needs to be replaced.

These changing tasks require different skills at different times. Sometimes a team is too small for all the necessary skills, sometimes a product is too big for a single team. Then there are issues such as releases, test environments and test automation that extend beyond the individual team.

Testers have never built in bugs. In the past, they were just unable to ensure at an early stage that errors did not occur in the first place. This is exactly what the team approach changes: quality is shifted to the front, to the phase in which nothing has been built yet.

What programmers already do without calling it testing

Many disciplines already use testing methods, just unconsciously. This makes the transition easier than it sounds.

A programmer needs a decision table and combinatorics in his head to build his if-then-else structures and structure his methods. An equivalence class analysis is implicit in any clean architecture. This is basically the same way of thinking that testers know as test design.

What you are doing is already testing. Now you just have to apply it consistently.
Steffen Schild

Creating this awareness is the way to introduce other disciplines to testing. Anyone who shows a programmer that their daily work has long included testing methodology lowers the barrier to actively engaging with quality assurance.

Conversely, the same applies to testers. A tester can no longer say that they don’t program. A programmer can no longer say that he does not test. Agile teams have outgrown this way of thinking of recent years.

Positions instead of roles: Temporary responsibility

The German Testing Board’s new job description refers to positions rather than fixed roles. A position is a task that someone assumes responsibility for a certain period of time.

This does not mean that you remain in one position for the rest of your life. On the contrary, the agile team concept expects someone to have different priorities at different times. Sometimes the focus is on backlog analysis and acceptance criteria, sometimes on test automation, test data management or test environment.

The first job description was created in 2017. The revision came about because agility shifts roles and distributes tasks across traditional boundaries. This was preceded by a development at the ISTQB: around 2012 and 2013, four or five basic syllabi became around 15 syllabi, which raised the question of who actually needs them and how the whole thing is connected.

What skills a tester should have today

The spectrum is broad, and the focus shifts with each task. Three areas come up again and again.

Analytical ability: Understanding the big picture. Work out how a new feature fits in with the existing system and whether there are inconsistencies. Derive test data from this and design test cases.
Technical understanding: Assessing what impact the currently implemented technology has on the existing system and on what will be added later.
Test automation: Implement the designed test case. This can be done by a tester with programming experience or a programmer in the team who implements the test case designed by someone else.

This division of activities according to skill is not a makeshift solution. It opens up development opportunities. If you want to automate things yourself, you learn to program or you pick up old skills. Those interested in interfaces can delve deeper into REST and API.

There are also specialization paths that have led to niches: Performance, security, game testing, test automation. You pick up such a niche because it interests you personally or because it is important for the team and no one else covers it.

Knowledge is one thing, experience is more important

A job description makes a conscious distinction between knowledge and skills. Knowledge can be acquired in courses. Skills are only acquired when you have actually done a job and gained experience.

The ISTQB program covers testing knowledge. For a complete profile, you need more: domain knowledge, technology knowledge and process knowledge. As soon as it comes to specific tools, the tool manufacturers take over with specialized courses.

More courses do not automatically make you better. If you take performance, security and safety at the same time, you will gain in breadth, but not necessarily in depth. For real strength in a subject, you need experience, not just certificates. You will never apply a lot of the things you learn during your training, but others will shape you because you have had good experiences with them.

Management skills don’t disappear, they spread

Planning, estimation, metrics, reports and concepts remain necessary. In Scrum, there is just no longer a role that has “manager” on the business card.

Scrum needs planning without end. If you start Scrum without a plan, you should leave it alone, because after three to six weeks the situation is more likely to get worse than better. The planning and management activities have to be done, they are just one skill among several that must be present in the team.

Whoever takes on this task changes with the context. One day, the person who plans the test management is the chief. The next day, the person with the business expertise for backlog analysis. On the third, the most experienced programmer, who decides on the tool and framework.

Basic management skills are therefore also part of the team. Anyone who can assess whether something fits into the sprint or can back up a report with a reliable metric will take the team forward, no matter what name they have.

How to plan your tester career today

Orientation starts with yourself, not with a course catalog. Actively look at what’s happening in your team and ask yourself where it’s struggling and what you enjoy most.

A reflection cycle helps: make a plan, implement it and regularly check whether it still fits. What are your strengths? What do you want to do? Nobody can give you these answers from the outside, but a reference scheme such as the job description provides the map.

You can proceed like this:

Observe which tasks are required in your team and where there are gaps.
Clarify for yourself which activities suit you and which you want to deepen.
Talk to colleagues from the testing boards or specialist communities about your previous experience.
Compare your strengths with the job description and derive further training and more responsibility from this.

Career here doesn’t just mean further training. It also means gradually taking on responsibility: first for a small area, then for a larger one. If you are committed and continue your training in one direction, you are more likely to be the person responsible for this activity in the next project.

The job description is not just for individuals. As a team leader or HR manager, you can use it to compare what your people can do and which skills are still missing in the project. You don’t have to be an expert to make a well-founded recommendation for the next step.