An equestrian project ...

Fellow tester Lisa Crispin gave me the idea for this ...

What the customer imagined ...

The early prototype ...

How it felt bringing the business owner on the journey ...

The speed with which the project progressed ...

Phase one testing ...

What was finally delivered ...

"Beam me up Scotty" requirements ...

Everyone's heard of the phrase “Beam me up Scotty” from Star Trek...

There's just one problem - that the phrase was never spoken in any TV series or film in the Star Trek franchise. We can trawl through them all and we'll find something very similar in a few occasions, "Scotty, beam us up" or "Beam them out of there, Scotty”.  But never properly, word-for-word “Beam me up Scotty”.

Never-the-less, the phrase has entered culture so much that we know it's associated with the series. We just have the inconvenience of not being able to be backed up by the facts!

I've recently learned that something similar with requirements. On my Waterfall project, we've been living and breathing the same set of requirements since Christmas. We've had meetings about them, we've had a dozen updated copies of the. We've discussed them informally.

Imagine our surprise then when we had software delivered this week, and it didn't quite meet expectations. We turned to our source of truth, the requirements, and found … erm that they weren't there. Not quite as we'd imagined them.

We'd kind of asked for a certain behaviour, and we'd definitely discussed them. But rereading them from a different angle now, maybe not.

This no doubt is the weakness of Waterfall projects. When you talk about the requirements so much, it's very easy to read them “in the same manner as how you've discussed them”.

The difference sadly is one between “what you think the requirements say” and “what they actually say”. Oops.

This in my mind is definitely the power of Agile, where it's the group discussion and consensus which is the living and breathing source of truth for the project, instead of the derived set of documentation (often delivered weeks after all those conversations).

The electric chair problem ...

This week I’ve been having a bit of fun talking with testers about implicit (unspoken) requirements we might have for products.  [Don't take the next bit too seriously]

One that seems quite obvious is,

“It’s a bad product if it ends up killing someone”

Of course testers know better, “but our product is an electric chair … so isn’t it the purpose of it?”.

How could we check this?  In a real project we’d ask a Business Analyst for their opinion.

I have a great relationship with Patrick, one of my Business Analysts.  We share a bay, and there’s a lot of good natured banter.  Like me he used to be a programmer, and he turned BA, whilst I turned Tester – so we’re kind of equal but opposite. 

So I put it to him,


To: Patrick, chief BA
From: Mike, chief Tester
Subject:  Electric chair requirements

We’re working on an electric chair, and we need your business analysis of it.  For our product, is the guy strapped into the chair the end-user, the customer or just an interested party?

When it comes to the reliability of the product, who would you consult most with, they guy throwing the switch or the guy sitting in the chair?

Where is the customer experience in this scenario?

Mike

---------------

His response was so good, I’ve just had to build a blog around it …

To: Mike, chief Tester

From: Patrick, chief BA

Subject:  RE: Electric chair requirements

The end-product is a chair that is capable of sending a high enough current discharged through the body of the person in the chair to end their life in (insert parameters here eg. 5 seconds). 

The Customer is the person who is paying for the product, together with all the people who work with them/support them to ensure that the product fulfils it’s set objective (“a chair that kills with electricity”).

The business rules for this product can be that,

• the power is not to ignite the body
• that it won’t prolong death
• that the current won’t blow the fuses

Consult with

• the Business owner,
• the chair manufacturer,
• the electrician looking after power supply,
• procurement,
• property,
• medical professionals

to determine best death time within the parameters.

So the deliverable is a chair that kills people, the business owner owns the relationship with the person in the chair, not the BA or the Project!

Patrick

---------------

Testing in pictures

How we testers see ourselves ...

How we view business owners ..

How we feel requirements are written ...

How we view developers ...

How we really need to behave with our teams ...

How what we deliver is viewed ...

How our jobs can feel like some days ...

What it feels like to encounter a high level defect ...

What it feels like when we miss a defect ...

How the project manager behaves when a deadline looms ...

How it feels when it goes into production ...

[Take with a pinch of salt - just a bit of fun]