How my Testers help Me

Uncategorized

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.

20180919_124906-effects

Team Day in the mountains

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.

20180923_165950

OktoberFest, with the Alps in the background

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.

20180919_131139

Part of the team, chilling

Product Owner of Test Automation

Uncategorized

2018 is another year of change for me. I packed everything I needed in 4 bags that fit my bike and on the morning of the 3rd of January started pedaling south.
Tom Waits – Whistle down the wind in my ears.

IMG_20180103_094703.jpg

Wind in my back, sun in my face. It felt as if something beckoned me, helping me forget what was left behind.

Car, house, job, security, city, comfort, relationship… everything was sacrificed. At least for now. In return I got freedom and a different kind of comfort. I can do whatever I want, enjoy what comes my way and seize all the wonderful opportunities that would otherwise make me think twice.

Since then, I’ve arrived in Munich, a bustling city. Met with QualityMinds, a wonderful company and rejoined with friends who showed to be more than true to the name.
Vera & Marcel have been absolute angels. Supporting me by opening up their home, workplace, baking birthday cake, being motivators and listening to my stories. Vera even found an ideal job for me.

Product Owner of Test Automation

A change in roles comes with an interesting set of insights. I had never been a Product Owner before, nor is my technical prowess in Test Automation of much note.

I do have a knack for connecting people, empowering people and strategising in function of change. Because of this, I’m sure I can add value over the coming months. In my years of being a tester in a SCRUM team, I figured out that the nature of the Product Owner role is hands-off, enabling and providing feedback. However, what I didn’t see before was the effort it takes in finding out how to balance the following:

  • What needs to be done to satisfy our stakeholders in the short term?
  • What can be done within the current constraints?
  • What does the team like to do?
  • What does the team need?
  • What can we do in function of the long term vision?

I feel a tension between now and later, us and them, needs and wants and I like the implications this has. It means my reporting and communication needs to be better. It means I need to listen as much as I talk. It means that I need to direct now to have others evolve later.

Personal introspection and (hopefully) progress, I love it.

For now, I visualise myself sitting at a table on which a massive boardgame is displayed. I’ve only just gotten to know the other players. This game has been going on for some time and I’m the new player. I see the cards I hold and plan for success whilst guessing for surprises that will sweep my feet from under me. I plan now to act later, slowly positioning allies, empower certain areas and planting ideas in the other player’s minds.
The path to victory lays before me, but so are the hazards and changes.

A good strategy goes a long way, but needs hard work, luck and support from others to succeed.

The Strategy

Phase 1:

  • Become a functional SCRUM team that adds value by means of either added confidence or fast feedback.
  • Build a stable and maintainable checking framework as a team.
  • Build a strong relationship with Stakeholders

Phase 2:

  • Coach and strengthen automation practices throughout the development life-cycle by example.
  • Support Testers through handy tools and automating the boring stuff.
  • Provide compelling data and reports to stakeholders who need to make decisions.

While a Strategy is rather deterministic for now, the tactics will certainly change over time. My first challenge is in splitting up the base tactics into workable tasks. Secondly, listening to the team on how they deal with this and how they would move forward.

I’m anxious to find out how things evolve from here.

 

IMG_20180107_174059.jpg