Rapid Software Testing – Before

This is the first in a series of posts on my experiences of RST and the TestBash conference this week.

I’m on my way to Brighton today, to facilitate Rapid Software Testing, led by Michael Bolton. I’m nervous about that, but I’m more nervous about this. 

My day is off to a great start. Overslept by 30 minutes, I need to wear my layers rather than pack them, and my train into Brighton is cancelled. 

Bus replacement service to Eastbourne

So, to anyone who travels regularly on the British transport network, you’ll be familiar with the phenomenon that is the bus replacement service. 

The bus is full, and I’m sat in the jump seat next to the driver, having picked up everyone from Hastings to Eastbourne on the way. There are probably many buses and bus drivers doing similar work across the country. (Subsequent seat moves to allow an elderly lady to sit down, and I’m now on the train from Eastbourne to Brighton, via Lewes.)

It makes me think of the services we test, when they are non performant or under stress. What do systems do when they are under heavy load, or a link in the chain is broken? How do you monitor and check that the system is performing as it should?

Clearly a system of checks and monitoring have come together to arrange this bus I’m travelling on. Service performance was seen to be dysfunctional due to a systems failure, so an additional service was put in place to pick up the slack.

What can testers learn from this?

Well, my first observation is to consider what your weak areas are. Is it the infrastructure, the application or the connectivity between systems? Do you know why they are weak, or can you improve or replace them.

As I’ve seen today, a replacement or temporary service isn’t necessarily better or more comfortable, but it is getting where I need to go.

I could have easily waited to get a lift from my Mum, but she was off conducting her own business elsewhere. I would still get there, but maybe not on time.

What monitoring do you have in place?

Monitoring isn’t just for your operations teams. At NewVoiceMedia, the DevOps team use all sorts of tools to allow us to keep an eye on performance, load, volume, through put, page impressions, browser usage as well as where any breaks in our systems might be. 

It’s hugely important so we can adapt to problems, or see them off before they become issues to our customers. Peak times (like the rush hour on the transport network) are one of the main concerns. 

Why is this a problem for testers?

Well, it isn’t a problem really. It’s more of a change of mindset. As organisations have to change and evolve to meet customer needs, testers need to adapt too.

Testers can and should be more aware of the wider needs of customers who need to use performant systems, rather than just having a narrow focus on the applications only.

We should be clear and concise in our communications, and be involved in the decisions that underpin our systems.


Well, in a DevOps organisation everyone has to muck in and get their hands dirty. Sure, there are people with specialist roles and positions of responsibility. But I see testers as the glue that holds systems together. We can get involved at any point, and not just on the application layer. 

More and more will be expected of testers as organisations change to meet customer need, and we will have to meet that challenge. 


I’ve been wanting to do this course for years. And by chance, luck or fate I have the opportunity to do so now. I’ll be facilitating, so my priorities will be on the needs of Michael and the group, rather than my own.

It’s going to be a huge challenge, and like the needs of any complex system I will need to adapt.

I like to ask a lot of questions, but I anticipate a need to allow the group to generate those questions rather than myself. I’ve been told in the past that I can sometimes “not shut up” or “meander” during groups discussions.

It’s taken a lot of time and mindful thinking to try and control my natural instincts to ask questions or share knowledge, where others might not be willing, unable or be nervous. And I need to be be aware of that for the next three days.

It’s going to be epic.  Just like the scenery today.

My home, The South Downs

One thought on “Rapid Software Testing – Before

  1. You did an awesome job Dan! I barely noticed you were there other than Michael asking you to write things up, which I think is a great sign of a well facilitated session!
    Not to mention, the notes you wrote up barely had any crossings out, so I think that shows you did a good job of scribing!
    As ever, you can’t control technology though, so don’t worry about the technical hiccups! It happens to all of us and it didn’t spoil the day at all.

    Looking forward to the remaining two days! Keep it up!

Comments are closed.