All hail the Ocelot

Linux and open source software isn’t for everyone. But it’s a good way to learn how software is developed and tested.

As well as preying on rodents and resting in trees, ocelots are surprisingly skilled in optimising recently-overhauled desktop environments.
(Photo: Danleo, Wikimedia Commons)

Yesterday (October 13^th) was an exciting day for many reasons. It marked the first anniversary of the completion of the rescues of the 33 Chilean miners. Classic 80s movies fans saw the return of Ghostbusters to the big screen. It was also the day to celebrate 65 years since the adoption of the constitution of the French Fourth Republic. All of these fascinating events, however, paled into insignificance against the most eagerly anticipated event of all, which is the release of Ubuntu 11.10, codenamed Oneiric Ocelot.

For those of you who don’t know what's so Oneiric about an Ocelot, I should explain what all the excitement is about. Ubuntu is a Linux-based operating system, which works as an alternative to Windows, and this is their latest six-monthly upgrade. (If you want to know why you’d choose to name an operating system after a South American wildcat, this page should explain.) Like most Linux distributions, it’s free – and not just free to use (like Adobe Flash Player or Microsoft Word Viewer is). It’s free for anyone to copy, modify and redistribute, as long as any derivative you produce is also free to modify. Only a small number of Linux users actually modify software this way, but the fact this is possible has a huge influence on how Linux is developed. Windows fans argue Linux is just a mish-mash of cobbled-together software written in backrooms, whilst Linux fans argue that the open collaborative way Linux is developed is actually better than Microsoft’s work behind closed doors. Anyway, the arguments could go on for years, but this is a blog about software testing – anyone who wants to continue on this subject can read why Windows is better than Linux or why Linux is better than Windows.



From a software tester’s point of view, however, there is a big advantage to Linux: you can learn a lot about software development and testing. All of Ubuntu’s Alpha and Beta releases are publically available to download and try out, and it’s a valuable lesson in just how much work is needed to test and stabilise software. The Alpha 1 release typically comes out after just 1½ months of development with all the major changes already in place – but expect the flashy new features to crash the system the moment you sneeze at it.^[1] It is only over the next 3 months that later alpha releases transform the bug-ridden mess into something reasonably stable. The Alpha releases are also the stage where features get pulled – they can be features that looked good on paper but don’t work in practice, or simply features that got a hostile reception from early adopters.

When you reach the Beta releases, you’ll probably come across a system that looks all polished and ready to go. It isn’t. It may load up fine, and all the programs you fancy using may fire up fine and appear to work, but it’s only when you try using the programs that you run into annoying bugs that haven’t been picked up yet – bugs that can still add up and render the system unfit for purpose. This sort of thing, I suspect, is a trap many projects fall into: impatient testers or managers try out beta-quality software, watch it run smoothly on face value, go ahead and deploy it, and learn its shortcomings the hard way.

Then there’s the open bug tracking system. Anyone who finds a bug – whether in an Alpha, Beta or stable release – can report it. But if you want your bug report to be taken seriously, you have to do it properly. Simply writing “Firefox didn’t work” is useless. If, however, you state exactly what Firefox is doing wrong, what you were doing when this happened, whether this error is reproducible or just intermittent, what version you were using, and anything else that might help developers pin down the bug, you will be more likely to get the bug fixed. If the bug you’ve found has already been reported, you can look at the progress of the bug report to see how it was handled and how it was dealt with.

Following open-source projects doesn’t teach you everything. The kind of testing you can observe – the unstructured error reporting from users as and when they come across bugs – is useful, but the kind of work done by paid software testers, in both open- and closed-source, is systematic testing designed to track down bugs and make the system fit for purpose. There’s many other concepts in software testing, such as testing models, reviews, static/dynamic analysis, that generally goes unnoticed by users of alpha and beta releases. But it’s still a good way to try out the world of software testing, and if you find it interesting, perhaps you can make it your full-time job.

Anyway, Precise Pangolin Alpha 1 comes out on 12^th December 2011. I can hardly wait.

[1] Oh, and if you are thinking of trying out an alpha release, you probably want to do it on a spare computer. In theory, an alpha release of an operating system can sit quite happily alongside a partition of Windows or Linux that you use for work, but as test releases by their very nature are liable to do disastrous things you didn’t expect, you probably want to keep it out of harm’s way.