… and what that means for the tester.

I’m still in the Healthcare project where we’re strangling small pieces of functionality out of a big monolith of software that was built over the course of 20+ years.
Next month, we’ll put our first real strangled functionality into production. In a docker container. With horrible UI. Yes, releasing is a matter of months for us. That’s not what I’m worried about right now.

The past week, I noticed myself saying: “I don’t care about quality.” and “We don’t need to fix that logical gap.”. Things I wouldn’t be able to reconcile myself with when I was a tester. My view on releasing, and the quality of said release has changed as well.

That ‘I don’t care about quality’ was mainly to make a point. It wasn’t correct. I just care less about certain aspects. The UI is not well structured, black and white and far from appealing. But everything we need is there. Looking at our new screen, any user will curl their upper lip.

Additionally, when you open a (closed) file from last year, you’ll get a blank screen. No user friendly message, apology or workaround. It’s not optimal, but it’s just not important to me and I’ll gladly defend that to anyone.

What does interest me are two very different aspects: Security and Performance.
(This is by the way why RiskStorming is such a great workshop to do in the beginning of such a project. As this information shouldn’t come as a surprise to anybody.)

Positive User Feedback is currently a low priority for me. We’re doing a very minor change when it comes to our users. However, the change touches upon some very important data. Data you don’t want to have stolen. That’s my first priority.
The second one is successfully working closer with our Operations department. The better we can make that collaboration, the easier we’ll have it in the future.
A third priority is making it run smoothly in production at all. If it’s a flop, it’s merely a flip of a parameter to revert.

These kind of decisions don’t make me particularly popular with the testers in the team.
I apologise for this, yet they are the product of careful listening and thinking.

Skiing with Team members

What does this mean for Testers?

In the aforementioned context, it can be daunting to be a tester. They might feel out of the water concerning expected expertise and they might feel discouraged because many issues are dismissed.

Consider this: I’m currently laying tracks for a train to cross America East to West around the 1860’s. I expect it to be bumpy. I expect troubles. The passengers should have a good chance of arriving at the other side, but in the face of danger, we should be able to turn back. The testers can’t safeguard this project from bandits, explosions, landslides,… They also can’t simulate half of these things or more as they lack expertise, resources,…
However, they can gather information on as many potential points of failure as possible and provide possible alternatives.

They might not know Security Testing or Performance Testing, but they know Risks and have the skills to identify weaknesses.
I expect them to use their words and arguments to do everything in their power to make sure I abandon the project as a whole.
… and have the patience, respect and open mind to accept unpopular decisions made by the PO.
Not that this has been an issue as of late, but I clearly remember my own frustration when faced with what my testers are facing now. I guess it’s never too late for some lessons in humility.