Learning to test with Big Trak

In the 1980s, Big Trak was the toy you wanted if you were a boy.

It was amazing - a motorised truck which you controlled by entering a program into the keyboard (see below).  You could choose to move it forward, backwards, turn left, turn right and then enter a number which would allow it to turn/move a specified distance.  See a dated demo here!

Hence,

• UP 2
• LEFT 15
• UP 2
• LEFT 15
• UP 2
• LEFT 15
• UP 2
• LEFT 15

would cause it to move around anti-clockwise in a box pattern.

You could do up to about 100 instructions, meaning you could do some really fancy patterns.

The toy line has recently been revamped for the 21st Century as Big Trak Jr, and you can buy them reasonably cheaply from places such as here.  [Yes I got one myself]

It's something I'd recommend anyone who's passionate about testing to get their hands on, because it's a very tactile learning tool for teams.  Samantha Laing (@samlaing) was asking for Agile workshop ideas for testing, and I think this really gets the point across.

If you've got hold of a couple, set up an assault course to navigate around, and ask a couple of teams to develop a program to get the Big Trak around the various obstacles.  More than likely you'll see at first someone blundering on, trying to do a big program all in one.  See how that works for them ...

Big Trak really parallels what we do in software.  You can give it to a developer, and it makes a lot of very nice and pleasant beeping noises, so you can assume it's making progress.  But you test it by hitting the GO button, to execute the problem, and more often than not you've missed something and it throws itself off the table or runs into the skirting board.

To make the Big Trak do something cool, you have to balance the programming you're doing with the execution (testing) using the GO button.  There is even a TEST button to allow you to test out a single line command.

We way to build up a complex program to get around an assault course is to do as with software, program a bit at a time, and test.  Then add a little bit more.  For instance the team might have to trial-and-error the distance to the first obstacle before turning etc.

Programming with the Big Trak it soon becomes obvious that if you are going to play with this toy, you're going to have to keep using the GO or TEST buttons.  The program really has no meaning until you hit the GO button.

Likewise in development, what we're working on has no meaning until we've attempted to execute it.  Testing our software, playing with it, is a vital step to seeing if we're doing things right, or sending our Big Trak over a cliff ...