All posts by admin

blog, Experiences, mobile, Testing

Facebook Overwriting Email Addresses – Breaking Rule #1

2 Comments

As you are probably aware, Facebook has let what looks to be a pretty serious bug out into the wild. First announced over the weekend, and confirmed yesterday, was the news that users who use Facebook as their primary storage for contact information such as email addresses, had found that these addresses on their mobile devices has been overwritten with @facebook.com addresses. Without them knowing or accepting any such change.

 

What Happened?

The official line goes something like this:

Contact synchronization on devices is performed through an API. For most devices, we’ve verified that the API is working correctly and pulling the primary email address associated with the users’ Facebook account.

However, for people on certain devices, a bug meant that the device was pulling the last email address added to the account rather than the primary email address, resulting in @facebook.com addresses being pulled.

We are in the process of fixing this issue and it will be resolved soon. After that, those specific devices should pull the correct addresses.

Now let’s be clear. This is very serious. I’ve worked in the mobile industry for the last 12 years and if there is one thing that is sacrosanct it is user data. You do not change, delete, update or generally mess around with anything that the user has stored on their device without giving them the opportunity to tell you to stop it first. Users have a much greater emotional attachment to their devices than they do to their desktops. They rely on them. Suddenly finding that you cannot contact someone is extremely annoying. Finding that is because another company has changed data that is yours is far more serious.

 

So Why Did This Happen?

I’ve been musing on why this bug may have got released. After all, this seems a pretty obvious use case. Of course Facebook is famous for a) not having testers as such and b) famous for adopting a test in production methodology. Could either of these be to blame?

Would these problems have been found by using manual test techniques? Facebook is a primary user of test automation and I can’t help but feel that a bug this obvious would be found by a few skilled testers adopting an exploratory test strategy.

I also wonder how much of a place the test in production has in the mobile world. In the desktop world, where users are always connected and backups are plentiful then rolling out updates and observing what happens is OK. Just roll back. It’s not so easy on mobile. Being on a mobile device means that you probably don’t have access to backups right away. You may be in a poor signal area or away from WiFi. And so you are stuck. Stuck out of the office or away from your friends and unable to contact people. And if you are stuck then you will become far more frustrated.

It seems to me that there is a typical gap in test strategy at work here. A bug that only manifested itself on mobile, uncovered as a result of changes made at server/ desktop level. When companies start to move onto mobile then this is pretty common. Failing to adopt a combined test strategy, treating mobile and desktop equally, or pushing more testing towards mobile can leave dangerous gaps.

It’ll be interesting to see how Facebook responds to this situation. I don’t know Facebook’s test strategies in detail but it seems to me that something needs changing to adapt to the world of mobile.

 

 

blog, Experiences, management, practices, Testing

A Testers Hierarchy of Needs

16 Comments

As part of my role I manage testers and also those involved in delivery operations. This means thinking not only about testing and test techniques, but also about person management, and the tools and techniques that a good manager uses in order to have a happy and productive team. These two areas should not, of course, be treated in isolation since, in order to have a successful test team, it’s the managers job to ensure that the two areas fit well together. If this can be done in as seamless as possible a way, maybe even without the team members even being aware of it, then my experience tells me that you can hit that sweet spot where the team is technically excellent as well as being the sort of team that testers want to work in, and are proud to work in.

I’ve studied a lot of theories of management in the past but the one that I keep coming back to again and again is Maslow’s Hierarchy of Needs. At it’s simplest it seeks to explain the needs of human’s in their most basic form, expressed hierarchically in order of those needs.

So, for example, the theory puts forward the hypothesis that it is most important (and therefore at the bottom of the pyramid) that human’s experience a need for food, water, etc. Safety needs come next, followed by a need for belonging, and so on.

As a manager, keeping this simple theory in mind can really help. I’ve found numerous occasions in the past where it has helped me understand team members actions, and to help ensure the team is working effectively together.

But it has also got my thinking about how one might go about applying Maslow’s Theory of Needs to Testing. More specifically, how a tester in a team or project might experience and visualise those needs, as reflected by their status within the team. This lead me to produce this:

Testers Hierarchy of Needs

Test Mastery is a place I see the respected, happy tester sitting. Probably people like you, who interact and are involved with the software testing community, who self-learn and who are able to articulate the need for testing effectively.

This is just the start of the theory. I’m sure, as a community we can add more to this. What would you add to the different levels and why? Leave a comment below.

 

 

blog, Experiences, Testing

A Good Test Case Is?

1 Comment

I’ve recently been reading through my ISEB Practitioner notes, which I got when attending a course organised by Grove Consultants a few years back, as I mentioned in my previous post. It’s got me thinking about test cases, and in particular the four criteria of a good test case. Having attended both Rapid Software Testing and Rapid Test Management recently, and having rolled out an Exploratory and Session Based Test Strategy in my teams then it’s caused me to question again the validity of test cases and the need for them.

So, to a good test case. Reading my notes, a good test case is, in no particular order, apparently:

1. Exemplary.
2. Evolvable.
3. Economic.
4. Effective.

Straight from the ISTQB/ ISEB of course. But not without merit. Are these still relevant?

Exemplary

Good test cases can test more than one condition at the same time. This is one good reason for taking the time to design test cases in the first place. Just writing test cases because “it’s the done thing” or “because the policy says so” is time wasting, but designing them so that when the testing is carried out it is done so in the most efficient way requires exemplary test cases and can add value. It is also the case that test cases are shared and it’s difficult, especially in large organisations, to ensure that all testers have the same basic level of ability. Having test cases can help.

Evolvable

From a contextual point of view perhaps a good test case is not written down at all but merely in the testers head, and driving the testing into particular areas that the tester feels are worthy of time and effort. Cases where the software is the specification are becoming increasingly common; in-sufficient or non-existent requirements documentation which requires the tester to apply their previous knowledge of the system under test in order to effectively test it. Clearly in this case, if documented test cases are required then they will be need to evolve. As Rapid Software Testing mentions “How do you invent the right tests at the right time – evolve them with an exploratory strategy”.

Economic

Time is money and often in testing we have little time and sometimes little money. So using that time and that money in the most efficient way means we minimise the economic impact. Of course, sometimes the best way to get maximum value is to have a purely exploratory approach and spend more of the time and money with the software in hand. A choice which is key to a good test strategy and highly dependant on the industry area one is testing within.

Effective

Clearly a good test cases should be effective. We are not in the business of wasting time, particularly when time is precious as it often is in testing projects.

 

I’d argue that the definitions given in ISEB/ ISTQB are still relevant and can be a good guide as to what is required of a test case. In a lot of industries test cases are still very much required and, particularly where there is strict regulation such as in areas of financial software and even in mobile software. The ability to write a good test case is a skill which should not be forgotten.

 

 

"rapid software testing", blog, Experiences, Exploratory Testing, Testing

Seeing the Wood For the Trees

4 Comments

I’ve recently been reading through my ISEB Practitioner notes, which I got when attending a course organised by Grove Consultants a few years back.

Don’t switch off yet. I know I mentioned ISEB. So before I go further, it’s worth stating my thoughts on the whole ISEB/ISTQB debate. I summed up my frustrations in a previous blog post; the fact that in the UK having ISTQB certification is practically the only way to get past the recruiters gate, but I also feel that there is some merit to the courses if taught properly, and followed up with a context driven approach such as Rapid Software Testing.

Reading back through my notes from Grove I can now see that this is what they were trying to work towards. At the time I had no idea how important the context driven school of testing was, nor the work of James Bach, Michael Bolton, Cem Kaner and others. But looking in the notes, the names are there. The techniques, albeit in nowhere near the detail that James or Michael teach in class of course, were hinted at and some approaches, particularly Exploratory Testing, are mentioned in some detail. Some slides are directly referenced from James and Michael’s work.

Unfortunately, due to the need to pass the exam, and with these areas being marked as ‘not exam’ then I didn’t pay them the attention that they warranted, and so it took a few more years to discover how and why the context driven approach can be so powerful. Which maybe shows the true problem with ISEB/ ISTQB certification after all.

Experiences, mobile

Time To Start Speaking In Public

Leave a comment

Yesterday I attended the Next Generation Testing Conference in London. Whilst on the face of it this is nothing new, I’ve been to conferences before, this time I was presenting and also took part in a panel session. This was something new for me; I’ve often presented within Nokia, and have run a number of training courses internally, but never to paying public so the pressure was on to make sure that things went well.

The Next Generation Testing Conference is not one that I had been to before, and this time the organisers UNICOM were also trying out a new format, with more emphasis on expert panel sessions, all focused around three main topics:

  • Testing Today – What are the main challenges?
  • New Tools and Techniques
  • All about Agile

The day started with coffee, introduction and some brief networking; there were people from many different areas of testing in attendance, ranging from finance to TV, all with testing and Agile as the common denominator. Then it was straight into a case study presentation about automated testing from Bertrand Meyer. He made some interesting points, some I agreed with and some I did not, and my reaction seemed to mirror the general reaction from others in the audience, as we spoke more about what we’d seen in the first coffee break.

Then it was over to my part. Dr Richard Sykes was doing a great job as facilitator and the first panel session, “Testing Today – What are the main challenges?”, with myself, Tony Bruce and Chris Ambler started. We got some good questions from the audience and some good discussions going, both with the audience and also between ourselves. The panel format worked well and made the event seem less formal than others that I have attended.

Panel session over then it was straight into my keynote “Mobile Testing, That’s Just a Smaller Screen, Right?” I spoke for about 40 minutes about mobile testing, giving the audience an overview of the mobile world as it stands today, pointing out the main challenges and areas to focus upon. This was followed by a quick overview of tools and techniques to use, and answers to questions such as “Which devices should I test on?” and “Where do I get all my devices from?” The time went quickly, it was good fun to get back to doing some presenting, and my part seemed to be well received from the feedback I got during the lunch interval. Plus some inevitable requests to help fix people’s phones 🙂

After lunch it was then time to relax and enjoy the rest of the conference. Two more panel sessions, “New Tools and Techniques” and “All about Agile” were well received and the participants were well versed in their subject areas, and able to give some great examples and tips. Sandwiched between the two panels was a bold, and very good, presentation from Colin Weaver at DB Consulting, on “10 Key Behaviours for a Successful Agile Tester”. This prompted a lot of debate in the room, regarding which behaviours were and were not applicable or specific to Agile, and which were in fact not needed at all. Healthy debate continued for the rest of the afternoon until wrap-up.

Overall it was great to be involved in a conference like this one, and I think the panel format worked very well. Thanks to UNICOM for inviting me to speak, and to all those who spoke as well. I hope this can be the start of more experience like this and I’m certainly now on the look out for more opportunities to present or run tutorials and workshops.

"rapid software testing", blog, Experiences, management, Testing

More Experiences of Rapid Test Management

Leave a comment

If you remember from the last post, I recently attended Rapid Test Management, taught by Michael Bolton in London. For a general overview and what happened in the first day then take a look at the previous post. As before, the following caveat applies:

Caveat – this is not a list of exactly what happens in a Rapid Test Management class, nor is it a list of exercises and course material. You won’t become good at Rapid Test Management by reading this post. Sometimes I forget things. If you really want to know about Rapid Test Management then you need to sign up for the class. It will be money well spent and this post will tell you a little about what might happen if you do take the class.

We started day two talking about test strategy and how one might incorporate Rapid Software Testing into a test strategy. The Heuristic Test Strategy model was introduced and we studied this in some detail, and followed it up with an exercise to define a strategy for a smartphone. I was happy with the choice of product under test, given my background then it made it easier to take into account my domain knowledge, and so our group could come up with a large number of options to consider. Equally interesting was what other groups had come up with and it was very interesting to see how each group had approached the problem differently and come up with different solutions. This goes to show that diversity in teams and experience is very important in testing.

Back on day 1 we had produced a list of areas that we, as a group, wanted the class to be focused upon and the major areas that so far had not been covered were risk and test coverage. As usual, Michael had some great experiences to share and course material to cover the risk areas and the details of risk based testing. In fact, the amount of class material was another one of the great things about this class – you get a lot, far more than you can look at or can be taught in the class itself. Together with some useful testing tools and also some more exercises and demo’s, this gives a great set of material to use afterwards. Continual learning is important and so to gain access to all the notes, examples and slides is just the start.

Day 2 was concluded with a look at test coverage and ways to visualise test coverage. Rapid Software Testing provides you with some great ways to do this, from the simple to the more complex. It got me thinking about how I might incorporate this into the Kanban project management processes that my own team use to manage our work.

So, should you sign-up for the class? You bet’cha. Rapid Test Management is a class that you should attend. If you want it to, and you take the time to study all the information and material that you receive, then it will make you a better tester and it will make you a better test manager. I’m on the way; I’m just beginning to take on-board all I’ve learnt and to read through the material we didn’t cover in class, but with everything I read I’m confident that it’s improving my skills.

"rapid software testing", Experiences, Exploratory Testing, Testing

Experiences of Rapid Test Management

3 Comments

Caveat – this is not a list of exactly what happens in a Rapid Test Management class, nor is it a list of exercises and course material. You won’t become good at Rapid Test Management by reading this post. Sometimes I forget things. If you really want to know about Rapid Test Management then you need to sign up for the class. It will be money well spent and this post will tell you a little about what might happen if you do take the class.

Last week I had the opportunity to attend one of the first Rapid Test Management classes, and certainly the first one to have been run in the UK. It was a great experience and the beginning of a lot more learning. There were attendees from a number of different areas of software testing and together I think we formed a very effective group, learning from each other and sharing experiences.

Rapid Test Management follows on from the Rapid Software Testing class that James Bach and Michael Bolton teach. I’d attended James’ class in Cambridge at the beginning of March and so, with the class material and my ideas rolling around in my head, I pitched up at the Hilton hotel in leafy Kensington (well almost Shepherds Bush actually) for two days of intensive learning from Michael.

Rapid Software Testing is a context driven technique, intended to enable testers to excel at our chosen craft. Since it focuses on testing as a craft itself, instead of merely on the production of test cases and then their use for testing (or it could be argued merely for checking) then this does put some questions in mind when considering how best to manage it. By way of some preparation, I noted down some of the questions that I had:

  • How can I best manage each testers time when adopting a Rapid Testing based strategy.
  • How does estimation fit in with the Rapid Software Testing ethos?
  • How can I sell the idea of Rapid Software Testing not only to those within my team who may be sceptical, but more importantly to those who manage me, who are most likely not only sceptical but also less knowledgeable about software testing in general?

Day 1

The class was split into two days, the first morning focused mostly on refreshing understanding of Rapid Software Testing and ensuring that, as a group, we had effectively collected our own desired outcomes from the class. It was good to spend some time going back over the methodology itself even though I had learnt it very recently. It was great that Michael seemed happy to tailor the class to the audience in any way that was necessary, taking a lot of time to ensure that everyone’s opinion could be heard.

What I found great about this class, and the RST course, are the little nuggets of information, stories and quotes that James and Michael pass on. Looking back through my notes from this class I find that’s what I mostly write down, quotes like:

 “Quality is value to someone who matters”

“Testers tell stories about products”

We also spoke in depth about the testers Elevator Pitch, that two minutes where you have to explain what testing is all about. Being able to explain and justify the role of testers and test teams is a critical skill and Rapid Software Testing gives you that skill.

When implementing any changes, such as introducing Rapid Test Management for example, then it’s critical to take into account the existing knowledge and processes that are already in use. Michael stressed the importance of ensuring that it’s not only the documented processes that are considered; in fact it’s the informal processes that are far more important to understand. He spoke about tacit vs explicit knowledge and how it is important for managers to be aware of the tacit knowledge in a test team and not merely the explicit knowledge.

We then took a look at how to put together a good team and how to train a new tester who was coming onto the team, through guidance and suitable heuristics. It was great to discuss with the others in the class about the issues they had faced when coming into a new team or bringing new team members in and also what had gone well. Ensuring that people are trained in a fault tolerant environment and gradually introduced to new tasks may seem fairly obvious stuff but it’s  often over-looked, as is the need to ensure that feedback is both given and asked for from new team members.

Day 1 concluded with a look at metrics and how important they really are, v.s. how important most organisations seem to think they are. Michael pointed us towards Cem Kaner and Walter Bond’s paper Software Engineering Metrics: What Do They Measure and How Do We Know which I would definitely recommend reading.

 

Find out what happened on day 2 soon…

blog, mobile, Testing

Smartphone Sales Pass Feature Phone Sales in Japan for the First Time

Leave a comment

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.

management, mobile, Testing

I’m Speaking At the Next Generation Testing Conference on 23rd May

Leave a comment

I’m excited to be able to announce that I’ll be speaking, and sitting on a panel, at the Next Generation Testing Conference which is on Wednesday 23rd May in London.

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.

Hope to see you there. You can find out more about the event at http://next-generation-testing.com/

 

"rapid software testing", blog, management

Test Leadership vs. Test Management – Is the Balance Right?

3 Comments

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?