logo logo

Testing Lessons Learned by Watching my Son Play with Lego

Testing Lessons Learned by Watching my Son Play with Lego

I recently got my son a lego robotics set. As with any lego set, he had a lot of fun putting it together, but then the real fun came. He started to figure out to program the robot to do what he wanted. I was sitting there watching him try to figure it out, and I noticed that he did a few things that testers and developers could learn from.

Test in Small Pieces

His goal was to get the robot to navigate through an obstacle course and he had a set of commands like “move forward”, “turn right”, “turn left” etc. that he could use to program the robot. The first thing he tried to do was to string together a long line of those commands: Forward, forward, right, forward, left, forward, etc. He then ran his program, and the robot promptly knocked into one of the obstacles 🚧 Turns out the “forward” command covered more ground than he had thought it did. At this point, he could have just taken out a forward command and re-run the program, but instead he did something very interesting. He broke off the rest of his program and tried just one forward command. He wanted to see how far that command would move the robot, and he realized that it was much easier to do that if he looks at the command in isolation.

This leads to the first testing lesson I learned: Test in small pieces.  It is much easier to understand what is going on if you isolate the code under test. This could mean using a unit test instead of a UI test, or it could mean testing one small piece of the application at a time. Breaking up your testing into small pieces can help you find problems more efficiently.

Bugs Love Company

Once my son figured out how far each forward command moved the robot he added back some of the other commands. However, he didn’t just run the program right away. He looked at the rest of the program and used his newfound knowledge to see if there were any other spots where the forward command might cause problems. He made a few adjustments to the program. This leads to the second testing lesson I learned: Bugs love company.

If there is a bug in the code, there are probably more like it. In this case, when he first wrote the code, he had a model in his head about how the forward command worked. Once he realized that the model was wrong, he knew that there would be other places that he had misapplied the model. The same thing often happens in the software development life cycle. When we are creating the code, we have certain ideas in our head about how it works. If it turns out that one of those ideas is wrong, we end up with a bug 🐞 However, we probably wrote more of the code with that wrong idea in our head. Where else might that bug show up? When you find a bug think about other ways or places where the same bug might show up!

All You Need is Good Enough

My son then re-ran the entire program. It almost worked. The turn command wasn’t quite turning 90 degrees, and so the robot ended up going off the track at one point. What would you do at this point? I think I would have tried adding in a lot of complexity to the program. Maybe I would have put in some turns that are set to 95 degrees to see if that would get it to turn how I wanted. It would have taken quite a bit of trial and error to get it to do what I wanted. That’s not what my son did. He took the robot and turned it a few degrees and then ran the program again. With that starting offset he corrected for the error in the turn commands and although the turns weren’t all neat and tidy, the robot made it through the course without hitting anything. This led to the third lesson I learned: Sometimes all you need is good enough. 

The obstacle course he had setup was short enough that the errors didn’t accumulate. The path wasn’t “perfect” but the robot made it through. We testers can have our own ideas of how things “should” work, but a program that solves a client’s problem provides value even if it doesn’t work perfectly. We need to understand what problem we are solving. Then we can figure out what a “good enough” solution is for that problem. Sometimes it just takes one simple tweak to get to a solution that works ✅

Developers Can test

In watching my son develop a program for his robot, I saw a lot of testing going on. Is there a place for people who specialize in the skills needed for testing? I sure hope so, as that is what I do, but let’s not deny reality. Developers can and do test. My son spent more time testing his program than he did writing it. If you are a tester, talk to your developers about what testing they are doing. you might just be surprised at how much testing they do.

So there are a few lessons I learned from watching my son play with his lego robot 🤖
What do you think? Did any of these testing lessons resonate with you?

About the author

Dave Westerveld

Dave Westerveld is an experienced tester who has been involved in various aspects of the testing role. As a strong exploratory tester, he has learned how to leverage many different tools to enhance his testing powers. He has also been involved in many automation projects including building out new automation frameworks. In addition he has helped transition several large and expensive automation suites into lighter weight, higher value systems. A speaker at several conferences, Dave also blogs about his thoughts and experiences at offbeattesting.com

Leave a Reply