Jumping Into Mobile Application Testing – Initial Challenges

With all of the latest developments in mobile platforms and the nature of this ever changing landscape, I wanted to share my observations and opinions on how I believe testers can approach this dynamic. As part one of a three part series, I wanted to start with some initial observations and background on where we have come from.

An app is an app is an app, so mobile software testing is, at its root, just software testing. Back when I used to work with mainframes, we also tested on those; and even though there were some special considerations to be kept in mind, the fundamentals were essentially the same. Because of that, I’ll try to keep this centered on what I see as particular about mobile SQA today.

I make emphasis on “today” because one of the most apparent characteristics currently facing mobile SQA is just how fast the platforms change. Think about it. Mainframes are still somewhat popular with governments and global businesses because of their robustness, and that robustness comes directly from an almost stubborn reluctance to change. Even though technology outside of the mainframe world has changed significantly in the last decade, a lot of mainframe work during the first years of the millennium wasn’t all that different from what you would have seen back in the 70’s.

Then there’s the modern PC OS which, while getting security-patched every other day, doesn’t really see much in the way of new features until it cycles to a new version every five years or so (unless you botch it so badly that you are forced to take a mulligan).

But mobile devices are changing so rapidly that smartphones pushed their less intelligent brethren off the market almost entirely in what – half a decade? A new iPhone comes out every year, and each time they seem to put a new screen and an additional camera on them. I exaggerate of course, but I’ll present a practical example. Within the past couple of months, a problem arose because apparently Apple discontinued the location services functionality from the Windows version of Safari (which can be used to test certain web mobile application features because it shares some common architecture components with the mobile version). This is a consideration that didn’t even exist until the third generation iPhone came out in 2008 (http://en.wikipedia.org/wiki/IPhone_3G).

At its very root, mobile app testing faces the same bifurcation we saw happen with desktop apps during the last decade: native vs. web. Yes, our humble brick-sized phones have evolved into platforms that can host web browsers which in turn can host web apps. Again, as with desktop apps, mobile web and native apps present substantially different testing challenges, and I would venture to assert that multi-platform is much more easily achieved with web apps (although response across browsers seems somewhat far from consistent still). In any case, apps developed natively for iOS present an interesting characteristic: since Apple tightly controls their app store through a fairly strict certification process, native iOS apps are the first for which testing isn’t just a good idea; you must test your software in order to bring it to the market. And Apple will too.

To finish off for this first of the series and with a little bit of fun, here are a couple of assertions to think about (all answers will be provided in the final installment of this series):

True or False: As of 2012, the iOS operating system has greater market share than Android.

True or False: Angry Birds is the #1 downloaded app of all-time.

(http://www.mobileapptesting.com/take-the-mobile-app-quiz/2012/08/#comments)

Stay tuned for next month’s installment where I’ll talk about the challenges of – “Too Many Configurations?”

Posted in  All, Other | Tagged , | Comments Off on Jumping Into Mobile Application Testing – Initial Challenges

Quality for Rapid Delivery

In the interests of the September theme, I will keep this short.  In his blog, Paul B posed the following challenge:

“a conversation about how the practice of quality could evolve to support the needs of a rapidly changing world. So share with us some of the ways the practice of quality is changing to meet the needs of faster, faster, faster.”

Quality has to change, specifically it has to evolve.

Our reading material has to be shifted from the industrial statisticians of decades past (Deming, Juran, Crosby) to those who reflect the demands of rapid delivery.

  • Steve Jobs: Founder and visionary for Apple products
  • Steve McConnell: Software development expert and author of many books, most notably Rapid Development.
  • Malcolm Gladwell: Social commentator and author of Outliers and Blink.
  • Michael Lewis: Financial columnist and author of revolutionary analytics non-fiction bestsellers, The Big Short (about the financial crisis) and Moneyball (a demonstration of the power of analytics in professional sports).

Rapid Delivery does not permit the traditional methods of Quality Control to be realized before completion.  This has to evolve from a passive practice of waiting for errors to justify action, to an aggressive mode of Quality Anticipation, where problems are blocked and tackled before their appearance.

Rapid Delivery needs to migrate from cumbersome and time-consuming practices like traditional Statistical Process Control and Auditing to more responsive and adaptable methods of Business Intelligence, Financial Forecasting and Tracking, and Analytics.

There are three attributes which distinguish Rapid Delivery: Commitment (to get it done), Mentorship (to deliver correctly), and Preparation (to deliver completely).   Imagine 3 scenarios:

  • Rapid Production: sandwich shop during the lunch rush hour
  • Rapid Service: hotel checkout with a lineup of travelers waiting for airport shuttles
  • Rapid Response: emergency health services in an extreme tragic situation

If any of the three attributes of Commitment, Mentorship, and Preparation are missing from the Rapid Delivery scenarios, the failures would be imminent and immediate, and would negate the positive advantages of Rapid Delivery.  There is no time to wait for audit reports or evaluate control chart trends, actions must be immediate and constructive towards a solution.

Without Commitment, Rapid Delivery will fall into a pattern of missed transactions, apologies, and unmet expectations.

Without Mentorship, Rapid Delivery will expose deficiencies in training, and reveal inconsistencies in personal capabilities.

Without Preparation, Rapid Delivery will simply fall short of expectations due to missing components or delayed processes which affect the “just-in-time” demands of such delivery.

Quality has a place, but obsolete quality methods do not, which is why our practices need to evolve as part of a QualitEvolution.

Posted in  All, Planning for Quality | Tagged , | Comments Off on Quality for Rapid Delivery

None Shall Pass…unless? Managing Risk with Quality Gates

A common element to a test strategy or master test plan is to include a description of how the project will mature the software system towards release, and how the project team can be sure that progress is on track and of quality.  One aspect of that description is to set expectations around entry/exit criteria and/or suspension/resumption conditions, aka “quality gates”. Continue reading

Posted in  All, Planning for Quality, Test Planning & Strategy | Tagged , , | Comments Off on None Shall Pass…unless? Managing Risk with Quality Gates

You Are a Scientist

On May 15, 2012, Christin Wiedemann presented “You Are a Scientist” at the Let’s Test Conference in Stockholm, Sweden.

A software tester is nothing less than a scientific researcher, using all his/her intelligence, imagination and creativity to gain empirical information about the software under test. But how do we prove to others that software testing is indeed a scientific method, that testing actually requires certain skills and that our work deserves recognition and respect? And even more importantly, how do we convince ourselves of our own value?

View the full presentation …

Posted in  All, Planning for Quality, Test Planning & Strategy | Tagged , , , | Comments Off on You Are a Scientist

It’s Raid Night! Gamification for Software Test Teams?

I presented “It’s Raid Night! Gamification for Software Test Teams?” to VANQ.org, the Vancouver Software Quality Assurance User Group and I wanted to share that material with you.

People, processes and technology are the pillars of any company, but without the team nothing gets done.  Motivate your people, keep them engaged, and successful projects can happen.

Team building exercises, public and private recognitions; these are not new and are expected – at least on an intermittent, perhaps annual basis.  But, then the impact of these activities may be as (in)substantial as bringing in a trainer for a day to lecture from a podium on a given topic.  With no practical incorporation into the fabric of the team, little value is added for the organization and its people.

So, what can be done in the workplace, on the project, every day…?  Especially with limited budget, no time, and/or overworked, sceptical team members.

The goals of gamification are to achieve higher levels of engagement, change behaviours and stimulate innovation by increasing the feelings of accomplishment, fun, and cooperation through a continuous feedback/rewards system.

In this presentation, we discussed and explored as a group how the ideas behind gamification could be applied to creating high performance software test teams.

You can download the slides here: It’s Raid Night! Gamification for Software Test Teams?

Posted in  All, Business of Testing, Team Building | Tagged , , , , | Comments Off on It’s Raid Night! Gamification for Software Test Teams?

A Mandated Tool

In my current context I’m required to use a certain tool for managing the test effort; you probably know the tool. I won’t mention it by name unless the vendor pays me to, but it’s the first on the list when non-testers choose to purchase a test tool.

My approach is to use this tool as a checklist manager and it works really well for that purpose IF you don’t over-engineer your use of it.

Forget Requirements – List Test Targets

This means avoiding the requirements management trap, that is, using the requirements section for anything but helping you to organize the test effort. A test target is something that needs testing. A requirement, user story, feature, benefit, risk, performance criterion, security criterion, etc.

Test targets are in checklist format and organized in a way that makes it easy to do the next step, create the playbook.

In my current project, I have device specifications (temperature operating range, voltage operating range, etc.) that are clear and unambiguous test targets; I’m lucky. We will employ the same concept when we need to test business processes though.

Forget Test Plans – Create a Playbook

Think of this section as designing/creating a playbook. When we get a new release – we do this. When we test this feature right here, we do that. You should organize the plays in the playbook according to the conditions that exist before you run the play.

Back to my current project – when we receive a device firmware update or upgrade – the set of tests (the play) that we should run to accept that new configuration should be easy to find.

The Test Lab is for Test Sessions

Think of this section as recording the results of test sessions. For any given release or time period, pull plays from the playbook, run the play, discover what more you can/should do, update the play book, run the new/revised plays, rinse, repeat, wipe hands on pants.

At the end of the session, upload your session record so that you have evidence of having tested. Revisions of the playbook are evidence of having learned something about the product and continual improvement.

Current project example again – the February 12 release firmware tests were run over a period of a few days by two engineers and their session record (a Word document) was uploaded into this section in the test management tool. We will create a new folder for the March 29 release and go back to the source – the playbook – to define the firmware test session that will be held at that time. We will not re-run the checklist in the February 12 release section.

Principles

DRY – Don’t repeat yourself. This works in code, and it works in checklists. Don’t organize your test targets by release since that limits your checklist’s value when used three years from now to test a new release or upgrade. If your list of test targets and your list of set plays look the same, then you really haven’t done any design work and you’re not helping your future self as much as you could be.

Ignore the temptation to put a release/time/date anywhere but as metadata for test sessions. Nothing else needs a date since they should survive every release of the solution until they are decommissioned. Test targets and the plays in the playbook are for all time. Well, at least as long as the solution itself survives. I would organize the test sessions

Forget you’re on a project. You’re creating the list of test targets and a playbook for all releases, for the duration of the solution’s useful life. Without this goal – why are you using this tool again?

Posted in  All, Automation & Tools, Requirements & Testing, Test Planning & Strategy | Tagged , , , , | Leave a comment

Why Are You a Tester?

I am always curious as to what drives people – what their motivation is – especially when it comes to other testers.

I know why I am a tester. My driving force is my curiosity and the need to learn and gain experience. I want to know how things work, and preferably also why. That is why I went to graduate school and got a Ph.D. in physics, and it is also why I am a tester. To me testing is a quest for information: I test to learn about a product and everything that surrounds it.

As much as I love science and research, I decided that I did not want an academic career, and did what many other physicists do: I took a job as a developer. At least programming was something I knew how to do, while the demand for experimental astro-particle physicists outside of the academic world is…somewhat limited. By coincidence, I was asked to pitch in and help the test team, and I was immediately hooked: I had found a research substitute! As a tester I am able to take full advantage of my curiosity, attention to detail, observational skills, logical thinking and ability to analyse and draw conclusions. Software testing is something I am very passionate about, something that occupies my mind constantly, and something I am so enthusiastic about that I do not really consider it “work”. I have found my true vocation.

But what about other testers? What brought them into software testing?

Asking around, a common answer seems to be “curiosity”; the need to find out how things do – or do not – work. Not surprisingly, it seems as if testers have a tendency to want things to work, and they get more annoyed than the general public when software they encounter fails. Maybe being a tester is a way to make the world function a little bit better and bother us a little bit less. There is of course also the thrill of the hunt and the excitement when you catch your prey, even if it is just a bug.

Quite a few testers start out as developers and then – like me – make the transfer, after finding that testing is more interesting and fulfilling. Why is it then that software tester is still rarely presented as a viable career path, comparable to software developer? I find it interesting – and important – to ask testers that I encounter why they are testers. Not everyone starts out as engaged and enthusiastic testers, and some might need a little bit of encouragement and coaching to realise how much fun it actually is.

Take the time to think about why you are a tester, and you might learn something new about yourself – and others.

Posted in  All, Team Building | Tagged , , | Comments Off on Why Are You a Tester?

Beyond the Agile Testing Quadrants

You can build the right product and you can build it right, and still not deliver value to the customer/user. For any number of reasons, they don’t adopt it easily, completely, or on time.

You can blame them. Luddites.

You can  blame others. Microsoft.

You can blame yourself. Incompetent. Need a hairshirt.

Or you can evolve your testing to include user adoption and benefits realization. Ask questions aimed at finding user adoption issues and explore risks to benefits realization.

I remember reading a Twitter post from Joshua Kerievsky about usage data and how evolving a product without it now seemed so inadequate once he/they started using it. In my mind, this extends the agile testing quadrants to finding adoption issues in addition to helping discover the right product.

A/B testing is another example. This is using real customer behaviour to guide the evolution of the product. Imagine what a tester could do – with their skills tuned towards asking the important questions at the right time – to this field. I think it’s filled with opportunity.

In the enterprise domain (where I spend all my time) the agile testing quadrants are not enough. You can follow them bravely and assuredly and still not deliver value because of:

  • an inadequate end-user communications plan
  • an inadequate end-user training program, or having a gap between training and when the end-users need to start using the solution
  • using the same testers in every test cycle or continuously, making them more expert and less skilled in finding adoption issues
  • not translating pre-release performance testing to post-release performance monitoring

Consequently, because I love the agile testing quadrants for getting the right product built the right way, I thought to extend the idea to include supporting adoption and supporting benefits realization.

Beyond Agile Testing Quadrants

Q1: Discover barriers to solution adoption by the support/sustainment/operations group(s). For example, assess the communications and training for support/sustainment personnel.

Q2: Discover barriers to solution adoption by end-users/customers. For example, assess the communications and training for end-users/customers, use A/B testing to determine/optimize features/interactions the customer cares about.

Q3: Discover risks to benefits realization that originate with the end-users/customers using the solution. For example, monitor the benefits to see if there is progress towards their realization.

Q4: Discover risks to benefits realization that originate in support/sustainment/operations. For example, monitor the solution performance on an on-going basis so that performance bottlenecks don’t become barriers to effective usage that would in turn lead to the planned benefits being realized (already a common practice).

It’s a start. I almost put the agile testing quadrants themselves in Q2 and I might yet put them back there. For now, I’m hoping this conveys the way that testers need to start thinking:

  • write a test strategy that lasts forever, not merely to the end of the project and/or release; deployment is not done
  • create checklists that the solution delivery team can evolve forever, not to just get the solution shipped/in production but one they can use to continually increase the likelihood of user adoption and benefits realization; deployment is not done
  • explore barriers to solution adoption; expand the list of test targets to include end-user communications and training; deployment is not done
  • explore risks and barriers to benefits being realized; deployment is not done
  • do this continually; deployment still isn’t done

Maybe you detected the theme that deployment is not done in the above points.

You can’t afford to think like this if there are product defects that decrease the likelihood of user adoption. You’ll be too busy writing bug reports. So yeah, this is complementary to agile testing (and the agile testing quadrants concept). These new quadrants are the next step, at least in the enterprise.

Posted in  All, Agile Testing, Planning for Quality, Test Planning & Strategy | Tagged , , , , , , | Comments Off on Beyond the Agile Testing Quadrants

Test Management: Leading Your Team To Success (Course Extract)

I have extracted a small deck of slides from my course “Test Management: Leading Your Team To Success”.  Hope you enjoy.

You can download the slides here: Test Management – Leading Your Test Team to Success (Course Extract)

Posted in  All, Business of Testing, Team Building, Test Planning & Strategy | Tagged , , , | Comments Off on Test Management: Leading Your Team To Success (Course Extract)

Follow-up on xBTM

Background

At STARWest 2011, I gave a talk about xBTM together with Michael Albrecht. Jon Bach was in the audience, and he gave us some very valuable feedback on our idea and how we presented it. This blog post is a follow-up on our conversation in Anaheim.

Recently I was testing version 1.5 of AddQ’s SBTM reporting tool SBTExecute. The team wanted to release the new version as soon as possible, and I was travelling so there was not so much time for testing. We agreed that I would spend one morning – four hours – testing the final version. My method of choice was of course xBTM. In this blog post I will go through how I spent those four hours, and what was the outcome. For more background on xBTM and the tool, please refer to my earlier post.

Test plan

My initial step was to make a mind map test plan. My preferred (free) mind mapping tool is XMind. I opened a new mind map and placed my application under test (SBTExecute) as the central topic. Next I identified my key areas (also known as function areas). I spent a couple of minutes thinking about some obvious groups and came up with:

  • Configuration
  • Documentation
  • Running tool
  • Import
  • Generation
  • Report

I added these six key areas as subtopics in the mind map. Then I decided I also wanted to some stress testing and added that as a subtopic too. See Figure 1.

SBTExecute 1.5 testplanFigure 1: Mind map test plan. The central topic (SBTExecute 1.5) is the software under test. The subtopics are key areas, or test techniques, and grouped under the key areas are the test threads.

Then I spent about twenty minutes thinking about test ideas, or test threads, and writing them down in the mind map under the appropriate key area. Since this was not the first time I tested the tool, I already had some ideas of things to test. After a total of maybe half an hour or less, I had my test plan, see Figure 1.

Testing

I decided to start by testing Import, since that is the key feature of the tool, if you cannot import data from the session reports nothing else is really worth testing. I looked at the threads I had listed under the import node and figured that I could probably test all of them in one 45 min session. To show this in the mind map, I changed the colour of all those threads to blue, see Figure 2.

Session 1Figure 2: Testing all threads under the key area Import in one session.

I write my session reports using the SBTExecute Excel template, and I use the mind map note functionality to connect the session report to the mind map. The yellow paper icon on the subtopic Import shows that there is a note, which can be viewed and edited by clicking the icon, see Figure 3.

NotesFigure 3: Adding notes in the mind map program. The note refers to the corresponding session report.

I ran the session, making notes in the session report. When I felt I was “done” testing a specific thread in that session, I visualised that in the mind map by adding a green check icon to that thread. Once in session, I realised that I didn’t really want to test the thread Incorrect data, since there is data validation in the Excel template. I decided to pause that thread for now, and maybe come back to it later if I had time. Hence I added the pause icon to that thread. I also added some notes on why I paused the thread, see Figure 4.

Notes 2Figure 4: Pausing the thread Incorrect data.

Then I realised I had forgotten to prioritise the key areas, so I did that using the colourful number icons in the mind map program. The highest priority is 1 and the lowest 6. See Figure 5.

PriorityFigure 5: Adding priority.

It turned out that the tool only reads files in xlsx format, and not old xls files. I wasn’t sure if this was a feature or a bug, so I marked the thread with a question mark and made a note of it, see Figure 6.

Notes 3Figure 6:  When there are questions, the thread is marked with a question mark and a note is added.

I ended the session, but the fact that xls files were not read made me curious so instead of starting a new session I decided to look at the configuration key area for a while. I spent a few minutes trying to create session reports in Office 97-2003 and Open Office and have the tool read them. These two threads were tested as threads rather than in a session. I only spent a few minutes on them since it was a low-priority area, made a short note, then paused the threads and decided to come back later. If I were to resume these threads (in the end I never did), I would keep making notes in the notes window, see Figure 7.

Notes 4Figure 7: Testing two threads for a short time, then pausing them.

Next I decided to test all threads under the key area Generation in a session, the same way as I did with Import, see Figure 8.

Notes 5Figure 8: Testing all threads under the key area Generation in a session.

Here I found a few defects, which is illustrated by the red X in the mind map. Whenever I found a bug, I made a note in the mind map of the ID number and added a short description. Of course this information was also added to the session report, see Figure 9.

Notes 6Figure 9: Defects found are marked by a red X, and a note of the ID number is added.

After completing the Generation session, I started looking at the Report key area. Here I decided that the two threads Iteration Reports and Summary Reports were extensive enough to make up a session, see Figure 10.

Notes 7Figure 10: Testing two threads in a session.

After running three sessions, and testing two threads separately I had the following status in my mind map, see Figure 11.

Three SessionsFigure 11: Test status after running three sessions and testing two threads separately.

The documentation for the tool consists of three manuals, and I felt they were best tested as threads. At this point I was running out of time, and decided to simply quickly skim through the manuals. I used the partially filled square icons to visualise how far I felt I had gotten with the manuals and made short notes in the mind map (no session report since I tested them as threads). The final couple of minutes I decided to spend on testing running the tool with correct parameters, which I also tested as a thread since there was not enough time for a session, see Figure 12.

Notes 8Figure 12: Testing threads, using the partially filled squares to visualize progress.

Test report

Finally my four hours were up and I stopped all testing activities. At this stage I had a test report in the shape of the latest version of the mind map, see Figure 13.

SBTExecute 1.5 stopFigure 13: Test report.

I also had three session reports (Import, Generation and Report) and an error list.

Given more time, I would have returned to the paused or partially tested threads and continued, adding notes in the notes window. I would also have spent some time on the previously untouched threads. Due to the very limited time in this case, the above story is not a very good example of thread-based testing, but I hope to have one soon.

Posted in  All, Agile Testing, Test Planning & Strategy | Tagged , , , | Comments Off on Follow-up on xBTM