Monthly Archives: April 2012

Something interesting has just happened in the mobile market. You may have missed it or it may surprise you if you live in the US or Western Europe and are a middle class iPhone or Android owner.

What’s happened is that smartphone sales have passed feature phone sales for the first time. That may surprise you, you probably thought this happened years ago. After all, we’re all smartphone users now, right? Nope. And it didn’t: worldwide 70% of device sold are still feature phones (meaning cheaper devices running OS’s like Nokia’s S40 or other proprietary OS’s, typically with smaller screens and a lack of multi-tasking). Although the amount of money that manufacturers make on these devices is much smaller than smartphones, they ship in their millions and billions. Nokia recently shipped it’s 1.5 billionth S40 device for example.

You can read more in the MobiLens report which surveyed over 400 Japanese customers, and was compiled by market-watcher comScore for the three months to February 2012. A quote from the report:

“Smartphones surpassed feature phones as the most acquired device type in February 2012, signalling an important shift in Japan’s mobile market,” said Daizo Nishitani, vice president of comScore Japan KK. “The rise in smartphone adoption opens the door to tremendous opportunity for publishers and advertisers to expand their reach and increase engagement with key consumer segments through this channel. Japanese mobile phone users were already highly engaged with their devices, but with the added functionality and higher levels of mobile media consumption we should expect to see significant changes in behaviour among the Japanese mobile population in 2012.”

Why Is This a Big Deal?

Japan typically leads the smartphone market and this is therefore a good indicator that slowly but surely the tide is beginning to turn towards smartphones in mature markets.

For testers this means more opportunity – smartphones typically mean a more open OS and therefore a significantly greater number of complicated applications that require testing. Feature phones are typically tested primarily by the manufacturers themselves; the only 3rd party runtime available is normally the Java ME platform and whilst there are a lot of applications launched written in Java (check out GetJar if you want some proof), there’s no evidence to suggest a large testing population at work ensuring that they work. Feature phones are also more likely to be lower powered, with smaller screens, ITU-T keyboards and generally lower spec without hardware like GPS.

However, with this move away from feature phones also comes further testing challenges; as the market switches to smartphones then it is inevitable that this will mean greater fragmentation of the OS’s themselves as manufacturers attempt to cover more and more price segments with different products. This will mean more display sizes, more hardware configurations and more differentiation in mechanics. For testers this will mean increased complication and mobile device testing strategies will need to evolve further than previously to cover a wider range of devices under test.

Also, as the market evolves then so does the installed base on devices. This presents additional challenges and further fragmentation issues. Ignore the devices in the field at your peril.

The conference is in its seventh year and is trying out a new format this year, with more emphasis on panels and discussions, together with case studies. This should hopefully mean that there’s some great audience participation and discussion on software testing.

I’ll be on Panel 1: Testing Today – What are the main challenges? It’ll be moderated by Dr Richard Sykes and they’ll be a group of us representing various areas of software testing, including Tony Bruce of London Tester Gathering fame. We’ll be debating various topics including:

Testing in the cloud

Testing mobile applications

Testing Big Data migrations

Games Testing

Non-software systems testing

I’m then be presenting a case study: Mobile Testing – That’s Just a Smaller Screen, Right? This will go into the background behind mobile device testing, how it differs from the desktop world, and giving some pointers towards areas to consider when formulating a mobile device strategy.

As I’ve blogged about recently, I’ve been recently studying for the Level 5 Certificate in Management and Leadership from the Chartered Management Institute. I’m now three sessions into the four session course, and it’s getting really interesting to see and think about how one might apply general management principles more specifically to the software testing area.

The most recent session was all about Management and Leadership. As part of this we did an exercise where we had to sort out a number of different phrases into groups that either apply to ‘Management’ or ‘Leadership’. No sitting on the fence, no spending hours deciding which to put where, but a quick exercise to make you think. There were right and wrong answers (although primarily to seed further discussion).

The list, as I saw it, is below. What do you think? Do you agree?

Leadership

Management

Enables others

Implements and maintains

Inspires vision

Focus on systems and structures

Encourages head and heart

Adopt short term view

Acts authentically

Completes transactions

Asks what and why

Asks how and when

Has long range perspective

Brings order and coordination

Focuses on doing the right thing

Focuses on doing things right

Inspires trust

Accomplishes tasks through others

Acts as an innovator

Focuses on performance

Challenges

Provides stability

Transforms

Controls

Committed to the cause

Imitates

Gives purpose and meaning

Complies

Focus on people

After the exercise I got thinking about how I might apply this more generally to software testing. Specifically to Test Managements vs. Test Leadership, i.e. what separates those who run testing projects, probably as part of the design and delivery of a specific product, vs. those who lead groups and provide inspiration both inside those groups, and to the wider testing community. Are the skills needed in those situations different?

We clearly need within our community those who can challenge and innovate. Right now this is coming mostly from the context-driven community as I see it, where also the vision and long range perspective is clearly evident. These people are driving things along nicely in my opinion. As someone who has recently attending Rapid Software Testing with James Bach then I can say first hand that he’s certainly encouraging head and heart. I don’t need to mention challenging, right?

The question then comes, who is taking things further? Leaders need managers to take their vision and turn it into practice. They need someone who can focus on the short term view, give the control and ensure completion. They need people who implement. As a community do we currently have enough of the managers listening and implementing the vision that our leaders are sharing?

I’ve been studying recently for a Chartered Management Institute Level 5 qualification. As my time in my current role comes to an end then it’s important to make sure that the management activities and experience that I have built up in my 9 years at Nokia is accurately reflected on my C.V. in a way that future recruiters will recognise. But the good thing is that through the course I have also been introduced to some techniques which are new to me, are useful for the future and can be applied to the software testing field as much as anywhere else.

Recently I learnt about a problem solving technique called reversal. It’s nothing new I know, but it appealed to my testers mind. It appealed to the part of me who wants to see how things could be made worse, how faults could be found, and how increased risk could be identified. The sort of mind-set that can equally be applied to software testing situations.

The reversals technique is a basic information based decision making technique. It breaks problem solving down into the following activities:

Identify the situation under study.

Consider how the situation could be made worse.

Create as many options as possible which will make the situation worse.

Reverse the options to identify ways of improving the situation.

As an example, consider a situation where a lack of road capacity has been identified. Using the technique, one could come up with options such as:

Close all the motorways.

Discourage homeworking.

Close alternative transport mechanisms.

Then by reversing these, one could come up with solutions which could improve the situation:

Build more motorways.

Encourage homeworking.

Build more alternative transport mechanisms.

A simple example I know, but you get the picture.

I think we can apply this to software testing as well. I recently read the blog post by Ilari Henrik Aegerter about What you Can Do if your Brain just Refuses to Understand and one addition I’d make to his list would be to consider some problem solving techniques. I find they help me unlock the locked parts of my brain. Reversal is one such technique.

Consider the situation where you know a bug exists but you just cannot reach the root cause. If you’ve run out of options when it comes to reproducing a bug, consider reversal. Think about what really will not cause the bug to happen, what combination of key presses or code paths that won’t help. Then reverse them. Consider a situation where you need to load test a system. What could you do that would actually make it faster? Then reverse them.

Hopefully it gives you a new perspective and another tool in the belt.

I work with groups of people who break the illusions that people have about software. I'm intrigued by software testing, test strategies and techniques, and organising everything using Scrum and Kanban. I have also been known to talk about mobile devices and mobile testing a lot.