Time to Strategise

Woohoo! The power supplies have shipped! Soon there will be no need to attempt to bend a virtual instance to my will.

I have been thinking about the various opportunities that present themselves around the Raspberry Pi and its potential uses. In discussing it with friends and colleagues, I have encountered various ideas of how it could be used. Many of these ideas already have a marketable solution in the form of some other pre-existing platform. Whilst I can sit back and waffle on about how 'in my humble opinion the following use, it is the best...', I would prefer to present something a little more empirical in value. It would be of little value or relevance to go charging ahead to set a Raspberry Pi up for a particular use, and once it is working, declare that it will be the way of the future, without some current or competing yard-stick to compare it with.

So, what is needed is a test strategy. This is somewhat different from the test strategies I write in my day job. I'm not managing a team of testers. I'm not furnished with mountains of business requirements and functional specifications.

So for now, it is time to set a light-weight test strategy, and move forward from there. In essence, my test strategy is simple.

The Strategy

For each proposed use for the Raspberry Pi, I need to determine if there are existing platforms and options in the marketplace already that fulfill that niche. If there are, I need to find what is currently rated the best option and what is the most cost-efficient option, and then compare the performance of the Raspberry Pi against the other two contenders across a series of tests and criteria. This will mean, that where the opportunity arises, I should in my testing, acquire, or at least acquire access to the competing systems to perform the evaluation.

In the case of a market niche, where the Raspberry Pi would be the only viable option, I will need to gather a set of objective criteria to test the Raspberry Pi against.

In either instance, the tests that need to be performed will be far wider than just simple software tests. Usability, accessibility, reliability, maintainability, affordability, compatibility and general performance of both the hardware and the software as a combined system will need to be evaluated. For some applications of the system, security and safety will also require scrutiny.

The methodology that makes the most sense in terms of further planning, is to treat the evaluation of each potential use of the Raspberry Pi as a test project in its own right, with its own test plan, and its own test suites. The potential deployment of the Raspberry Pis in each case will determine the bias and the make-up of each test plan.

So there, you have it. A very light-weight test strategy, in only four paragraphs.