There are a few things which make the first week of March this year to be interesting, most notably:

  • New Daylight Saving Time
  • March Madness
  • It's merely a couple weeks away from Spring
  • Techfest!

As a matter of fact, I'm planning on attending either today or tomorrow Techfest session to absorb new ideas and see cool demos.  I did catch a bit of live webcast during the press day (yesterday) and happened to see a couple of demo presented.  One of them was Boku (video)-- lightweight programming language for kid.  I have to say that although it didn't blow me away, but the concept was very intriguing.  It is based on the 3D-game environment and UI-based, which means there is no text involved.  A child can then go ahead and create his/her "program" in this virtual world where different object can interact with one another depending on the instructions given.  Since there's no code, the learning curve is pretty minimal.  And it sort of introduces and teaches the child the basic concept of programming subconciously.  I have been doing slight research on some introductory programming language for kid (for my own child), and there are a few out there.  Some notables are KPL (video).

The thing that gets me thinking after watching the Boku demo is how do we go about testing software like this?  Beside the traditional testing methodologies (i.e. functionality, error checking, boundary, stress, perf, and what-not), there is actually a whole new perspective to look at from testing standpoint.  First of all, we have a brand new group of users (at least they are new to me).  This group of users are basically a bunch of 3-8 year-olds.  Their usage pattern, needs, requirements, and thought process are very different than typical users (like you and me). 

Testing software that's meant for children could be challenging but definitely interesting.  I'm trying to imagine myself as a Boku tester and there could be so many unpredictable activities which can be carried out.  This would result in tremendous amount of scenario-based cases as well as new workflow.  UI testing and usability testing would definitely be key testing criterias here (and they should be fun).  And like any other prototypical software, there's going to be endless conflicting ideas on requirements, functionality, and design.  These are probably not going to be easy tasks.  The end result, however, is going to be so rewarding which justify all the efforts.  And that makes me very interested.

Now, I'm a bit psyched up for more cool demos at Techfest.