Thursday, 9 November 2017

It works... And also it doesn't.

Just a quick one while it's in my mind space...
Testers need to make sure that something works, but also make sure that it doesn't not work.
This is another one of those phrases that I've been trotting out for so long I've forgotten if I invented it or just stole it from someone cleverer than me. I said it in a planning meeting yesterday and had a room full of confused people looking at me.

If something works how can it also not work?

Tuesday, 18 July 2017

Alexa-ing the Worcester Wave

This page still gets a few hits per day, so I've broken out the steps and example code into a bitbucket repo. If that's all you're after then head over there now -->


Our new boiler came with one of those WiFi thermostats that everyone has these days. Unfortunately, not a Nest, as that would have knocked a couple of years off the guarantee. So I went with the sensible OEM option and ended up with a Worcester Bosch Wave.
While it does come with a half decent smartphone app, it doesn't appear to be compatible with Google Assistant, Alexa, IFTTT or any other third party do-things-with-stuff type services. Which is a shame - mainly because I just bought an Echo Dot on #primeDay!

Or so I thought...

Tuesday, 13 June 2017

Your test team is a challenge - not a safety blanket!

It seems that the 'us and them' relationship between devs and testers is gradually dying out. But I'm not so sure that this was entirely a bad thing. I've even experienced developers almost relying on their testers as a safety net. You need a bit of healthy competition.

A while ago I heard a developer say:
"That'll do. If it's not right then Test will spot it..."
While I appreciate this vote of confidence, it felt as if he was just passing the buck.

Tuesday, 25 April 2017

You man the guns. I'll drive.

This blog post is basically an expansion on this tweet...

And of course, a twist on the old 'two fish in a tank' joke.

It's not really Paired Testing. It's not quite Paired Development. And it's definitely not DevOps.... I suppose it's DevTest?

Last week I raised a bug against one of our products that was pretty tricky to replicate and even trickier to explain. Not only is there a lot of confusing logic involved, but his app consumes a LOT* of data, and it's time sensitive too. A database backup from yesterday won't give the same results if you import it again tomorrow. The easiest thing to do is to modify the existing data into a given state and fire up the app.

So that's just what we did. I rolled up my sleeves and hacked around in the Test database while he pointed his development machine at it and we stepped through the code. Between us we eliminated a few bugs, removed some potential bugs and eventually got the numbers to line up.

No bug reports were created. Nothing was typed up, crossed off or assigned to anyone. And we didn't have to play my least favourite game ever - Bug Tennis. It's completely the opposite end of the spectrum to the 'throw it over the wall' mentality that existed between dev and test teams a few years ago (and unfortunately I'm sure still exists in some places). If this is the way that testing is going, then I'm all for it! 👍

*It's not quite BIG data... But it's quite TALL data. 

Tuesday, 28 February 2017

Refactoring: IRL

Every morning I walk past Sheffield University's shiny new Diamond building. The actual building has been finished for several months now, but builders are still putting finishing touches to the new pedestrianised area out front. The ugly tarmac paths have been replaced with some very expensive looking flagstones and the road is now a wide paved cycle-path.