In the beginning of last year, I moved from a Test Consultant to a Product Owner role and I haven’t written much since. Gaining so many insights over that period from: My role change, remote working teams, testing strategy workshops in other companies, Agile transformation of a HealthCare company and much more. It’s been a tumultuous year, but a rollercoaster in learning and insights. The end of the ride is not in sight.

My first insight I wish to explore is how I, as a PO, am dependent on testers: My in-team tester, our automation specialist and the separate team of testers.

In my role, I am mainly concerned about delivering a quality product that people are sufficiently happy with. It shouldn’t be stellar. It doesn’t have to be perfect. It has to be an improvement. 

That’s the context I work in. We’re trying to replace a big monolith of ancient software into smaller pieces of understandable, working software using strangling patterns.

A strangling pattern in short: You identify the boundaries of a piece of functionality, you build a completely, separate duplicate of the functionality and feed the exact same inputs to both pieces of functionality in a test or production environment. Then you monitor the outcomes. When, over time, the outcomes are consistently the same you can replace the old functionality with the new.

This pattern is used in situations where functionality has become so complicated, so bloated that any change can cause a ripple effect across the software destroying just about anything.

The Team Tester

Given this situation, I rely highly on the software testers. My team’s tester has been working for the company a lot longer than I have and has a wealth of knowledge when it comes to the application and its history. That’s why me and the team need him to:

As Early As Possible:

• Warn us about possible points of failure;
• Inform us about potential risks and their outcomes;
• List problematic parameters and outliers that we might forget;
• Talk to & prepare other testers about the changes that are coming.

During Development:

• Support the team by providing information, good and bad, about the current state of the product;
• Inform the PO about the progression on achieving of sprint goals or not;

After Development:

• Support me in handing over the changes to our most direct stakeholders;
• Hand over the changes to the separate test team so that they can see what actually was finished.

In other words, he’s a bit out guardian angel. Not the kind to swoop in and save the day, but the fairy-god-person type that’s always watching our backs and supports us to overcome problems ourselves.

The Automation Specialist

To be honest, when it comes to automation on the service or UI level, it’s not profitable for us yet. Our specialist has her hands full maintaining old selenium scripts for the big monolith. Voices constantly rise up whether these scripts are worth the investment time and again. For now, we persist.

Next to the maintenance, she’s also involved in pair development with the others in the team, learning about implementation new user stories. She’s involved in pipeline improvements and team discussions about for example: the depth and effort the team wants to put in TDD practices and so on.

With our move to Windows containers for our test systems and hopefully also production, she’ll have her hands full supporting the team in providing checks and information on stability.
For I want them to streamline everything so well, that in the future they can give me a button: a button that I can push at any time, that deploys our current devbranch into production.

The Separate Test Team

This is a whole different article that needs to be written. Potentially, this is the point in the Agile Transformation that has had the biggest change and effect on the reliability of our releases of all.

In the past year, I’ve seen our releases go from “Always going horribly wrong, needing four to five hotfixes” to “A release with scheduled hotfixes” to “A stable release with little to no problems.”
These changes can be attributed to changes across the whole development process, but it is a marvel to observe how much more efficient the test team has become.

I saw them, under guidance of great test consultants, abandon most of their documented test scripts and develop mindmaps and checklists. They focused on efficiency, speed and supporting rather than complaining, defending and acting like martyrs.

To Conclude

The testers I work with cover a lot of ground. They focus on results and moving forward, by amplifying the team through information. Information that is actionable and valuable.

It hasn’t always been like this. Together, we’ve come from a very ‘structured’ process where people were working in separate roles on a monolithic software problem, making our situation worse and worse by the day.
What turned it around was:

• Problems being made visible;
• Protection being provided by (and from) management;
• People’s roles being mixed;
• Teams getting a vision, but otherwise left to their own devices;
• Relentless positivism;
• Strong consultants that support with knowledge and learning.

Little change after little change each of us started to see a little light in the darkness. That’s all one needs to keep moving forward. So we joined hands and started in that direction together.