Are we really just test managers?

We act as quality coach of the team

We support the teams in understanding quality as a joint responsibility. We do this not by lecturing on general concepts, but especially by working intensively with all other roles in the team on a daily basis. In doing so, we establish knowledge as well as appropriate procedures around the topic of quality.

We accompany the complete story lifecycle

Together with the entire team, we ensure that our high standards of quality are taken into account long before our products are developed.

During the conception of a story, we show alternative paths and point out possible risks. We avoid later edge case problems by considering them already during the creation of the story. During implementation, we pair with developers to test the right things in the right place. At sign-off, this gives us more time to talk again with our stakeholders and users. In production, we monitor and evaluate our software through proper monitoring and alerting.

We drive Continuous Delivery / Continuous Deployment.

We bring our deployments into the production environment with as little risk as possible. To do this, we keep our changes as small as possible and roll out every single commit automatically. We use feature toggles to enable and disable new functionality independently of code changes.

This has two additional major advantages: We can deliver our software to our customers at lightning speed and get quick feedback on newly developed components.

We balance the different types of tests of the test pyramid

We know what to test at which level of the test pyramid. We can use it as a guide to create lots of quick unit tests, an appropriate number of integration tests, and as few end-to-end tests as possible. This allows us not only to speed up our pipelines, but also to run our tests as effectively and with as little maintenance as possible.

We also find in our toolbox different types of tests (such as acceptance or feature tests, exploratory), methodologies (e.g. Test-First, BDD) and frameworks (e.g. Selenium, RSpec). We use the respective type, method and framework appropriately at all levels of the test pyramid.

We help the team to use the right methods for high quality.

As specialists we know the advantages and disadvantages of different methods and can establish them successfully in the team. We have learned that pairing in a team leads to greater knowledge dispersion, more communication, faster software development and higher quality. Besides pairing, test-driven development is one of the key methodologies to create our product with high quality from the beginning.

Flexible software is only created in flexible structures. Therefore, we teach our teams suitable process methodologies in an undogmatic way. We can then decide together which processes we actually need.

We are active in pairing

Not only do we encourage pairing between developers, but we enjoy active pairing ourselves. This allows us to point out problems while the code is still being written. To avoid running into edge cases during development, we like to pair with business designers, analysts, and UX designers. In production, we monitor our software in collaboration with DevOps.

Pairing with these different roles allows us to combine both our technical and business skills.

We represent different perspectives

By taking different points of view, we enrich one-sided discussions. We try to break typical thinking patterns by questioning assumptions about processes, methods, features and architectures. In doing so, we can often point out possible alternatives when working out solutions to problems. This helps us to reduce systematic errors, to avoid cost traps and to weigh risks in development as objectively as possible.

We are communication talents

We are a point of contact for questions and information of all kinds, both within the team and externally. We also make active use of the effect of corridor radio, which is practically always present in large organizations.

We see ourselves as an amplifier for communication. This can take place between a pair, between many or all team members, and across team boundaries. Through this coordination, we can significantly reduce ambiguity about features or integrations and thus develop our products to production readiness more quickly.

The next step was to introduce this new role to more and more of our "agile test managers", who were so enthusiastic right away that they wanted to apply for the position again. What was still missing was a suitable name. There are various specialists in each of our cross-functional teams. One of these specialists is the driving force for more quality: theQuality Specialist.