When “testing” goes wrong….Breaking News, Breaking Rules

When “testing” goes wrong….Breaking News, Breaking Rules

Today, something very strange popped up on my phone, at 10:22am. I’m used to the lovely BBC Breaking news music going off every now and again, so I when I hear it, I have to check and see what’s going on. However, the message on my phone this time wasn’t quiet the breaking news I’m used to (if you can be used to such a thing)

A hacker, maybe? Well, it’s possible, but surely they’d have something more important to say, wouldn’t they? I mean, a Game of Thrones spoiler is pretty bad, but it’s not the work of Anonymous.

20 minutes later, we get another “Breaking News” alert that explains the situation.

Also, Robin Pembroke (Head of Product BBC News) confirmed that this was an error and nothing malicious.

Apologies to all who got the rogue News alert sent this morning. To confirm we have not been hacked & was a testing error. Sorry!

— Robin Pembrooke (@robinpembrooke) June 25, 2014

That explains that, then. But, I can’t be alone in thinking this:

How can the BBC get this so wrong?

I work on a large scale database, with thousands of active customer records at my disposal. The last thing I want is to accidentally release my test cases to them. It’s just not the done thing to do….some simple processes can easily prevent this from happening:

My top tips:

  1. Crucially – always assume that something might (or will) go wrong, and that your testing could become public. Use a message that indicates this, for example, “This is a test” or a timestamp. Writing about the lack of Nudity in Game of Thrones just isn’t needed, and isn’t professional. If in doubt, a passage of Lorem Ipsum will *always* do the job!
  2. Create a sandbox environment. Somewhere without an external route. If you’re testing something that might push notifications out, block the live route out and put a simple exception in place to catch it. You’d rather write an error to a log file than have to apologise to millions of users, right?
  3. Encourage your test team to be vigilant. We got this alert twice. That means, someone (probably) did it once, didn’t realise, and hit the button again.
  4. This is the BBC, and an application that is probably on millions of devices. If that isn’t reason enough for people to take care with their testing, then I don’t know what is.
  5. Ensure you have the correct workflow processes in place for things such as Push Notifications. If something can be sent out to so many people, so easily, twice, then you probably need to investigate the layers of content authentication that you have in place, as something isn’t quite right.

Long story short, as a developer, this isn’t a good thing, and it’s much more than just an accident. It highlights the bad practices that seem to be in place in one of the worlds most reputable (and potentially hacker-appealing) companies.

And that isn’t good at all.

I had a reply regarding this post, from Robin:

@mstevenson83 all sensible stuff and will use to reinforce some of the revised messaging that’s been going to teams here…

— Robin Pembrooke (@robinpembrooke) June 26, 2014

Originally published at www.lifeinpixels.co.uk on June 25, 2014.

Leave a Reply

Your email address will not be published.