Sometimes, work can be difficult without the proper mindset. If you’re tired, angry or frustrated for instance (like Patriots fans this morning) then you’re almost guaranteed to make some careless mistakes. This is true of almost every profession. Software testing in no exception.

So what’s the proper mindset for a software tester? Much has been written on the topic – and it’s critical to your success in the field – so I figured I’d offer a view different points of view.

Here’s one from softwareprojectmanager.com:

A professional tester approaches a product with the attitude that the product is already broken – it has defects and it is their job to discover them. They assume the product or system is inherently flawed and it is their job to ‘illuminate’ the flaws.

This approach is necessary in testing.

Designers and developers approach software with an optimism based on the assumption that the changes they make are the correct solution to a particular problem. But they are just that – assumptions.

Without being proved they are no more correct than guesses. Developers often overlook fundamental ambiguities in requirements in order to complete the project; or they fail to recognise them when they see them. Those ambiguities are then built into the code and represent a defect when compared to the end-user’s needs.

Here’s another view from onestopsoftwaretesting.com:

Pedantic, sceptical, nit-picking to software

Some years ago, we were asked to put a slide together, saying who makes the best testers, and we thought and thought, but eventually, all we could think of was, they’ve got to be pedantic and sceptical and a nitpicker. Now, if you called someone a pedant, a sceptic, and a nitpicker, they’d probably take an instant dislike to you. Most folk would regard such a description as abusive because these are personal attributes that we don’t particularly like in other people, do we? These are the attributes that we should wear, as a tester, when testing the product. When discussing failures with developers however, we must be much more diplomatic. We must trust the developers, but we doubt the product.

Most developers are great people and do their best, and we have to get on with them – we’re part of the same team, but when it comes to the product, we distrust and doubt it. But we don’t say this to their faces. We doubt the quality of everything until we’ve tested it. Nothing works, whatever “works” means, until we’ve tested it.

Impartial, advisory, constructive to developers:

But we are impartial, advisory and constructive to developers. We are not against them, we are on the same team. We have to work with them, not against them. Because it is human nature to take a pride in their work and take criticism of their work personally, bear in mind this quote: ‘tread lightly, because you tread on their dreams’.

Here’s a similar view from kualitatem.com:

All software must possess bugs as the developers are human and you can’t eliminate the error factor from humans. Therefore it’s very important for the tester to think from end user perspective and try to find out all the possible bugs that a user can face. The approach to use Mindset Testing is to treat the software as it’s full of bugs; the developers deployed an application that will crash when end-user will use it and testing its all possible flows. Here begins the work of a tester to find out all these bugs and loopholes that will make this application go crashing.

Don’t take any bug lighter, “Report all bugs you have encounter with”, as you will be responsible for it at the end.  Although sometimes with the mutual understanding of the developers and QA, some bugs are not addressed right away, but still, from QA perspective one should not skip reporting any bug.

What do you think? Is there a proper mindset for testing? If so, what is it? Please share your thoughts in the comment section below.

Testing usually means looking for bugs in software. But to Sport Evac, it means ensuring everyone gets out of a stadium safely in an emergency situation. The software was designed by the National Center for Sports Safety and Security and tests every scenario imaginable to help security personnel and first responders at big sporting events prepare for an emergency. But, as it turns out, testing is testing whether you’re testing the latest mobile app or an evacuation strategy for the big game. The goal is to find as many of the nasty bugs as you can before everything goes live. FoxNews has more on Sport Evac:

The Sport Evac program trains teams for those “what if” scenarios, by creating virtual 3D stadiums drawn from actual blueprints and packing them with up to 70,000 animated human avatars designed to respond to threats as unpredictably as their human counterparts.

It’s advanced technology fans won’t see on game day — but tech that behind the scenes makes watching the big game safer.

Evacuation in the event of an emergency is a critical challenge, and rehearsing the how to move around tens of thousands of people isn’t realistic. So sports security planners turn to computers to make sure it all goes smoothly.  …

The virtual stadium allows them to simulate how fans will respond in those first few critical minutes after an attack. Stadium and team security can use the virtual stadium to practice moving players and fans to safety and to run exercises with local first responders. …

As with any test, the ability to scale to meet different demands is key to success. Only testing for the “best case scenario” isn’t very effective.

Sport Evac isn’t the only evacuation software program, but others have struggled to meet the scaling challenge of sporting events. Other simulations also failed to include the wide range of human behavior variations and the multitude of factors that may disrupt the best-laid aid plans.

All sorts of curve balls can appear in a threat: parking gridlock, for example, making an orderly exit disorderly, or the elderly having a hard time with a crushing crowd.

Sport Evac allows security teams to test the robustness of their planning against the full range of possible factors — fans fighting against the stream to retrieve forgotten wallets and handbags, spilled beer creating too-slick floors, emergency lights failing and so on.

Not only did the makers of Sport Evac create and test desktop software, they are also working on a mobile app version of the software for stadium employees and first responders to use on-site. This app sounds like a perfect candidate for some in-the-wild testing because any sports fan can tell you that the middle of a sold-out stadium isn’t the best place to get a signal. Plus, this is the last app you want to crash, freeze, load slow or glitch at the exact moment you need it most.

A smartphone app, known as Sport Evac Lite, will become available as well, so security staff and ushers can see where fans and cars could bottleneck.

Read the full article at FoxNews >>>

Every once and awhile, when there’s nothing topical to blog about, I decide to go back in time and focus on a software testing classic. Today is one of those days.

With that in mind, I wanted to draw your attention to Classic Testing Mistakes by Brian Marick. Whether you’re a tester or manager, experienced veteran or wide-eyed newbie, this 25-page article outlines some of the most classic testing mishaps and offers valuable tips on how to avoid them.

So what are some classic testing mistakes? One would be not reading this document in its entirety. As for the others, here are a few clips I found interesting. Note the bold titles are mine, everything in italics in Brian’s.

Mistake: Testers Not Responsible for Usability
If usability problems are not considered valid bugs, your project defines the testing task too narrowly. Testers are restricted to checking whether the product does what was intended, not whether what was intended is useful. Customers do not care about the distinction, and testers shouldn’t either.

Mistake: Misunderstanding the Role of “QA”
A first major mistake people make is thinking that the testing team is responsible for assuring quality. This role, often assigned to the first testing team in an organization, makes it the last defense, the barrier between the development team (accused of producing bad quality) and the customer (who must be protected from them). It’s characterized by a testing team (often called the “Quality Assurance Group”) that has formal authority to prevent shipment of the product. That in itself is a disheartening task: the testing team can’t improve quality, only enforce a minimal level. Worse, that authority is usually more apparent than real.

Mistake: Bad Timing on Load Testing
Putting stress and load testing off to the last minute is common, but it leaves you little time to do anything substantive when you discover your product doesn’t scale up to more than 12 users.

Mistake: Relying on Beta Testing
Beware of an overreliance on beta testing. Beta testing seems to give you test cases representative of customer use – because the test cases are customer use. Also, bugs reported by customers are by definition those important to customers. However, there are several problems:

1. The customers probably aren’t that representative. In the common high-tech marketing model4, beta users, especially those of the “put it on your web site and they will download” sort, are the early adopters, those who like to tinker with new technologies. They are not the pragmatists, those who want to wait until the technology is proven and safe to adopt.

Mistake: Having Programmers Test
Using testing as a transitional job for new programmers is one of the two classic mistaken ways to staff a testing organization. It has some virtues. One is that you really can keep bad hires away from the code. A bozo in testing is often less dangerous than a bozo in development. Another is that the developer may learn something about testing that will be useful later. (In my case, it founded a career.) And it’s a way for the new hire to learn the product while still doing some useful work.

Mistake: Testers Not Domain Experts
Be especially careful to avoid the trap of testers who are not domain experts. Too often, the tester of an accounting package knows little about accounting. Consequently, she finds bugs that are unimportant to accountants and misses ones that are. Further, she writes bug reports that make serious bugs seem irrelevant. A programmer may not see past the unrepresentative test to the underlying important problem.

Mistake: Poor Bug Reporting
It’s not enough to find a failure; you must also report it. Unfortunately, poor bug reporting is a classic mistake.

Mistake: Unrealistic Expectations
Whatever approach you take, don’t fall into the trap of expecting regression tests to find a high proportion of new bugs. Regression tests discover that new or changed code breaks what used to work. While that happens more often than any of us would like, most bugs are in the product’s new or intentionally changed behavior. Those bugs have to be caught by new tests.

What other common testing mistakes have you experienced? Please share in the comment section.

If you’ve worked in the software industry, chances are you’ve encountered words and phrases that you did not understand. I certainly have. So to help make sure we’re all on the same page (that means common understanding), I’ve decided to start a running thread of some of the more common slang terms that apply to software testing. Of course, this list will be woefully inadequate without your input, so please add your slang terms in the comment section below.

Here’s a few off the top of my head, as well as some that I found in this Quora thread:

• Dogfooding: When a company tests its own software internally before releasing to beta
• Low hanging fruit: Easy tasks that can be completed in short order
• WAG: Wild ass guess
• SWAG: Scientific wild ass guess
• Staging: A development enviroment; one level before production
• Automagically: Describes something that occurs in software that is either too complicated to explain, or the person describing the process really has no clue how it works
• Quick and Dirty: A quick and simple solution to an otherwise complicated problem
• Showstopper: A bug that makes software unusable
• Brown-bagger: A very embarrassing bug found soon after release
• Whack-a-mole: The practice of repeatedly getting rid of a bug, only to have it continually reappear
• Drink the Kool-Aid: Lacking objectivity
• Heavy lifting: Difficult and challenging work
• SoLoMo: Social, location and mobile – testing components of many mobile apps
• Burndown: a chart that is a graphical representation of work left to do versus time
• FUBAR: F#@cked up beyond all recognition
• PEBKAC: Problem exists between keyboard and chair (good one John Montgomery)
• RTFM: Read the F#$cking manual
• Fast-track: To speed up a process

Like I said, I’m certain that I’ve left out 99.99% of all the great testing slang terms. So please, pick up the slack (help me out) in the comment section below.

Guess what? The No. 1 biggest security threat to your website is still SQL injections (not one of those hacker collectives that have been taking down websites left and right recently). SQL injections aren’t anything new – they’ve been on the Open Web Application Security Project‘s list of Top 10 threats since 2004 … when they started compiling the list.

Despite being on the security radar for literally years, injections still make up the vast majority of security issues today. From PCWorld (emphasis added):

SQL injection attacks have been around for more than ten years, and security professionals are more than capable of protecting against them; yet 97 percent of data breaches worldwide are still due to an SQL injection somewhere along the line, according to Neira Jones, head of payment security for Barclaycard.

Speaking at the Infosecurity Europe Press Conference in London last week, Jones said that hackers are taking advantage of businesses with inadequate and often outdated information security practices. …

In October 2011, for example, attackers planted malicious JavaScript on Microsoft’s ASP.Net platform. This caused the visitor’s browser to load an iframe with one of two remote sites. From there, the iframe attempted to plant malware on the visitor’s PC via a number of browser drive-by exploits.

Avoidable Attacks

Microsoft has been offering ASP.Net programmers information on how to protect against SQL injection attacks since at least 2005. However, the attack still managed to affect around 180,000 pages. …

“I always say, if anyone says APT [advanced persistent threat] in the room, an angel dies in heaven, because APTs are not the problem.,” said Jones. “I’m not saying that they’re not real, but let’s fix the basics first. Are organizations completely certain they’re not vulnerable to SQL injections? And have they coded their web application securely?”

Generally it takes between 6 and 8 months for an organization to find out it has been breached, Jones added. However, by understanding their risk profile and taking simple proactive measures, such as threat scenario modelling, companies could prevent 87 percent of attacks.

Read the full article >>>

Not only are these attacks avoidable (OWASP even gives you tips on protecting your site), but they should be unheard of by now. Here’s an excerpt from a PCWorld article from 2009:

We should have eradicated SQL injection attacks by now. SQL injection should be the Internet generation’s smallpox or polio — gone for good. Countermeasures are readily available and understood. They’re easy to impleArtwork: Chip Taylorment. And yet, I keep seeing headlines like, “Huge Web hack attack infects 500,000 pages.”

Security testing is just as important as functional testing. It doesn’t matter if your site works if it’s just going to expose visitors to malicious code. Most importantly, you need to keep testing! The tech world is ever evolving and hackers are often on the cutting edge of that evolution. Testing V1 of your site when you first launched five years ago isn’t going to protect you forever. Security breaches can only result in bad press (it isn’t true – not all press is good press) and some very angry customers. From Neira Jones (via PCWorld):

“Data breaches have become a statistical certainty,” said Jones. “If you look at what the public individual is concerned about, protecting personal information is actually at the same level in the scale of public social concerns as preventing crime.”

“I’m sorry that testing is complicated, folks. No wait. I’m not sorry at all. Go away if you don’t like it.” – James Bach, Testing the Limits, 2010

James has a point here: If you’re not willing to learn testing the proper way, then you should probably find another line of work (something that could be said of almost any profession). So what is the proper way to learn software testing? Well, that’s very much up for debate.

As many of you know, uTest has gone to great lengths to ensure that testers of all experience levels can learn by doing (uTest Sandbox program and paid projects), learn by studying (Crash Courses) and learn by peer-to-peer discussion (uTest Forums). Apart from uTest, there’s also tester certifications, college courses, training seminars and a host of other methods.

So which method is most likely to help you successfully learn testing? Before you answer that, let’s consider a few points from a recent Wired.com article Everything You Thought You Knew About Learning Is Wrong:

Taking notes during class? Topic-focused study? A consistent learning environment? All are exactly opposite the best strategies for learning…

…first, think about how you attack a pile of study material. “People tend to try to learn in blocks,” says Bjork (director of the UCLA Learning and Forgetting Lab), “mastering one thing before moving on to the next.” But instead he recommends interleaving, a strategy in which, for example, instead of spending an hour working on your tennis serve, you mix in a range of skills like backhands, volleys, overhead smashes, and footwork. “This creates a sense of difficulty,” says Bjork, “and people tend not to notice the immediate effects of learning.”

Instead of making an appreciable leap forward with your serving ability after a session of focused practice, interleaving forces you to make nearly imperceptible steps forward with many skills. But over time, the sum of these small steps is much greater than the sum of the leaps you would have taken if you’d spent the same amount of time mastering each skill in its turn.

Bjork explains that successful interleaving allows you to “seat” each skill among the others: “If information is studied so that it can be interpreted in relation to other things in memory, learning is much more powerful,” he says.

There’s one caveat: Make sure the mini skills you interleave are related in some higher-order way. If you’re trying to learn tennis, you’d want to interleave serves, backhands, volleys, smashes, and footwork — not serves, synchronized swimming, European capitals, and programming in Java.

Let’s be clear: Since everyone learns differently, there is no right or wrong approach. So I’ll end this post by asking: How did YOU learn software testing? Please share your experience in the comment section below.

Having just finished Steve Jobs biography, and being of the school of gated platforms – at least for my phone, where I don’t want to deal with bugs the way I might in my work laptop (sorry Matt B and the uTest IT team) – I found this concept very interesting.

According to the BI article, “Android Hackers Plan App Store of Banned Apps,” a group of Android Developers are looking to start their own app store for all the banned and rejected apps that didn’t make the cut.  The article includes a quote from the potential founder that, “apps removed from the Market include, one-click root apps, emulators, tether apps, Visual Voicemail apps, and more.”

It sounds great but we already know about the growing number of malware on phone operating systems, the Android especially.  The other alternative for apps is to create mobile-specific landing pages (i.e. HTML5 apps), like Grooveshark (music) and Untappd (beer reviews) have done, making the apps available via your mobile browser.  Since their launch, Untappd has launched a native app for iOS and Android but has not shared details on traffic comparisons.  [It won’t be applicable to most mobile users but we cover some security exploits and common attacks in our Security Testing whitepaper.]

Am I the only one uber-sensitive about the integrity of my phones OS and Apps?  Would you download an app that isn’t scrutinized for security?

Answer: In-the-wild testing.

This according to our very own CMO Matt Johnston, who recently sat down with Rich Hand of softwaretestpro.com for an in-depth discussion on the growing importance of in-the-wild testing. This lively Q&A was then adapted into a featured article  (no word yet on its big screen debut).

Anyway, if you’re new to the concept of in-the-wild testing or want to know more about it, then I highly recommend giving it a proper read.  Here are a few clips to get you started.  Enjoy!

Does it ever seem that no matter how much time, effort and money your QA team spends improving and refining software testing processes that some sort of defect is always found in the application, website, or mobile app after launch? Surprisingly, it has little to do with your organization’s in-the-lab testing – whether in-house or outsourced, manual or automated. In fact, it’s likely due to the fact that the lab environment you’re testing in cannot adequately replicate real-world conditions (real users, real devices, diverse locations, imperfect connectivity, not to mention a range of devices, operating systems, browsers, etc.).

And thus, companies test extensively in the lab, launch their apps into the real-world conditions of users, and we’re all surprised when these products don’t perform as expected. But what kind of testing can fill this gap effectively and affordably? It was out of this persistent question that uTest and crowdsourced testing was born. And the by-product of this was a new category of testing which has become a must-have for mobile, social and local apps known as “In-The-Wild Testing.”

“In-The-Wild Testing” (ITWT) is an effort to educate tech leaders about how to help QA teams and organizations launch higher quality software, quicker, faster, and cheaper. The idea of in-the-wild testing is about providing organizations with the real-world testing data necessary to make informed decisions about releasing products to market. According to Matt Johnston, Chief Marketing Officer for uTest, “Don’t be fooled by the word ‘wild’ when it comes to testing software. When you think of the term ‘In-the-wild testing’ think of it as ‘real-world vs. laboratory conditions.’” This is not outsourcing or beta testing, and it’s definitely not suggesting you replace the QA teams or solid processes you have in place within your test lab. Rather, this is about complementing, scaling, and aligning professional testing resources with your in-house or outsourced QA team. I predict that this concept will explode in the next five years . But the first step is to understand what ITWT is (and isn’t).

Continue reading >>>

Today, we’re thrilled to announce the results of our third annual uTester of the Year Awards. Every year, we recognize uTesters who have consistently gone above and beyond their call of duty in their participation with uTest projects. This year’s winners were selected by our community and project management teams, who have had the privilege of working closely with such an extremely talented community of professional testers. From test automation to test team lead, these winners are truly experts in a variety of testing domains. The level of talent continues to impress, with each year’s accolades becoming more and more difficult to attain (and judge). So without further ado, let’s meet our 2011 winners!

Top honor for the 2011 award goes to David Honeyball from the United Kingdom!

David joined uTest in June of 2009. Since joining us, David has become a Gold rated tester in Functional, Load and Localization testing, as well as having achieved the silver rating in both Usability and Security testing. David also became our Top Test Team Lead in 2011, successfully leading nearly 200 projects alongside of uTest project managers. David had this to say about his experience with uTest during the past year:

I joined uTest back in the summer of 2009 and have to say I have never looked back. What started out as something extra in my spare time has taken up more and more of my time in a good way and has increased my confidence as a tester to levels I never thought possible. I have been a tester for nearly 15 years but can safely say that every day with uTest is a new experience and a new challenge.

I have met so many wonderful people including other testers, CMs, PMs and customers who are all committed to achieving their goals and creating a wonderful service. They have guided me and helped me in the last year and increased my communication skills as well.

TTL (Test Team Lead) Experience:

2011 has been a big success for me personally, as it has for uTest in regards to growth and development, in many ways due to my journey from tester to TTL. I started out as a TTL early in the year and felt at the time that it was a great way forward and would be of huge assistance and help to customers. Since then I have been involved in something nearing 100 cycles as TTL, but that could be more now!  I enjoy the TTL role immensely as I get to speak to the PMs and testers and help out others who are stuck. I hope if you have worked with me that you know that I take that side of things very seriously. One of the great rewards is helping someone who is stuck to complete a test case or test for example. Above all, I believe that with my experience I am a very fair TTL and have the best interests of customer and testers close at heart.

As time goes on I hope to grow more and more into this role and improve further as there is still so much to learn.

Special Projects 

Apart from testing and TTL work which does take up some time as you can imagine, I also help with test case writing for certain PMs which I enjoy and get value from. I was also heavily involved in the startup of the test case conversion to uTest which is the new system we see today. This side of things linked in with my testing and other roles forms a vital component of what I do as well and hope it adds value to the company as a whole.

So, just want to say a huge thanks to everyone involved with uTest for the opportunity and long may we continue to grow together and become invaluable to customers across the globe…

The complete list of winners is shown below:

• Most Valuable Tester: David H., United Kingdom
• Top Test Team Lead: David H., United Kingdom
• Top Android Tester: Elena H. , United States
• Top iOS Tester: Bo V., United States
• Top Forums Moderator: Amit K., India
• uTester of the Year: Anand A., Australia
• uTester of the Year: Andy M., United States
• uTester of the Year: Arsiadi S., Indonesia
• uTester of the Year: Atul A., India
• uTester of the Year: Bo V., United States
• uTester of the Year: Brian R., United States
• uTester of the Year: Carl S., United States
• uTester of the Year: Jason Y., Canada
• uTester of the Year: John K., United States
• uTester of the Year: Moritz S., Germany
• uTester of the Year: Nicola S., United Kingdom
• uTester of the Year: Paul T., United Kingdom
• uTester of the Year: Peggy F., United States
• uTester of the Year: Shruthi P., United States
• uTester of the Year: Travis H., United States

We’d like to congratulate and thank all of our 2011 winners. As mentioned in the opening paragraph, each year has seen so much growth and improvement. Therefore, the bar for 2012 will undoubtedly be set even higher! With several weeks into the new year, the competition has already begun for our 2012 accolades. Remember, it is your consistent performance throughout the year that matters, engaging in as many opportunities as you can without sacrificing quality work. With that said, best of luck to our 2012 candidates and please take some time to congratulate our 2011 winners by dropping a comment below!

In the second part of our Testing the Limits with Anne-Marie Charrett, we get her thoughts on the meaning of exploratory testing, the challenge of agile adoption, how to grow as a tester and more. Enjoy!

uTest: Certain industries appear to be ahead of the curve when it comes to testing practices, while others remain in the proverbial stone age. Is this an accurate statement? Or have testing practices evolved at similar pace across all industries? As someone who has spent time in many sectors, we’re interested to hear your thoughts on this.

AMC: I think companies that demand value from their testing are generally more receptive to new ideas and change in testing. I don’t think it’s fair to silo this into industries.

Take for example the finance industry, yes many large insurance and bank corporations are risk averse and resist change but not all. For example Barclays Bank are using coaching & Rapid Software Testing.

I’ve worked with small companies in R&D who you would associate with flexibility and being pro-active, yet they want very traditional, heavily documented testing processes. Often this is because someone did testing ‘once’ and this is what they did.

I’ve seen testing practices change within sectors too. For example, the telco sector in the mid 1990‘s were typically heavily documentation orientated. Often testing went on for years before a product was released. By the late 90’s and early 2000’s testing practices had to evolve as smaller companies with lighter and more flexible delivery approaches challenged this paradigm.

uTest: There’s a good debate right now on the true meaning of exploratory testing, with people like James Bach and Michael Bolton chiming in with their opinions. What is your definition of exploratory testing? And in your view, what is the most misunderstood term in testing today?

AMC: So many questions!! The beauty of Exploratory Testing is that it can mean different things to different people. Thats why there are so many different perspectives on it.

There are some core values to Exploratory Testing, namely that it’s an approach (not a technique), it’s simultaneous learning, design and execution and that it’s tester centric.

The latter ideal is something that I cherish and hold dear.  I think it’s essential that we take responsibility for the testing we do. This means each tester decides on their testing approach, what they test and when they’re done. Owning these decisions is what matures a tester, helping them become skilled, confident and motivated to excel in their testing.

uTest: On a similar note, software testing is sometimes seen as a career with a definite ceiling. What advice do you have for testers who feel like they have peaked in terms of title, salary and responsibility?

AMC: This is a really difficult question to answer, but it’s so dependent on the tester what they want and the other factors in their lives.

Personally, I’ve experienced the frustration caused by lack of recognition, especially early on in my career as a tester. I’ve also quickly become disillusioned by roles I’ve taken to the point where I’ve asked myself, is this all there is to testing?

A couple of things radically changed how I viewed myself, my career and testing.

The first was to re-discover the joy or learning new things. There are always new things to learn, new things to discover in testing but have you sufficient curiosity to find them?

I’ve discovered how owning and taking responsibility for your learning liberates you. You own the learning. You’re not doing it because your job demands it, or your boss expects you to do it. You are doing it to satisfy your own curiosity, it’s yours. I find a sense of freedom from that. It makes me really happy.

But this is my own personal experience, it’s up to each individual tester to discover what floats their boat.

uTest: What’s Anne-Marie Charrett doing when she’s not making testing a better place?

AMC: I spend time with my two boys Nikolai and Alex and I enjoy running. One of my biggest pleasures is an early morning run, and then sitting by the sea watching the sun rise.

Rapid Fire:

Better wine: Australia or California?

You make wine in California?

Favorite testing blog….other than uTest :

My personal favourite has to be James Bach’s blog but other bloggers I hugely admire are Michael Bolton and Catherine Powell. Closer to home are Trish Khoo and Ben Kelly.

Twitter or Facebook:

Twitter for work, Facebook is strictly for family and friends.

Next vacation:

Up the coast to Hawks Nest for a week by the beach with my very supportive husband, two boys and our new addition to the family, our pet bear.

Ever walked out of a movie?

What a question! Funnily enough, I don’t think so. I keep waiting to see if the movie improves, or if it’s because I haven’t quite understood something.

Favorite waste of time:

My boys Nikolai and Alex.

Editor’s Note: We hope you’ve enjoyed our latest Testing the Limits interview. Until next time, happy testing!

To kick off another amzing year of Testing the Limits we reached out to Anne-Marie Charrett, an independent tester who has worked for the likes of Mercury Interactive, IBM (twice) and Nortel – just to name a few. She also arranges for speakers to visit Ireland as part of Softtest Ireland and blogs about her testing experience and offers coaching at mavericktester.com. 

In part I of this month’s interview, we learn what motivates Anne-Marie to coach via Skype, what’s caught her interest lately, how her book with James Bach is coming and what the biggest mis-conception about testing is. Come back tomorrow for part II.

uTest: In terms of writing, speaking and researching, you are one of the most active testers in the business. So we’ll start by asking you this: What hot topics within testing have captured your interest recently?

AMC: 2012 has kicked off with a flurry of activity. Key topics appear to be, How we learn, Rapid Test Management and more recently James Bach has been looking Exploratory Test Documentation.

It goes like this. Typically we write tests and charters as artifacts for other people as evidence of work performed. But writing is a lot more powerful than that, it has the ability to assist in design (think brainstorming in mind maps). Exploratory Test Documentation is about changing the purpose of writing from an end product to a by product.

I also like the way new conferences and peer workshops are happening at a grass roots level, for example Lets Test in Stockholm. These are not necessarily big conferences, but ones that offer value to testers and that encourage participation. I hope that this will be the conference circuit of the future!

uTest: You’ve made quite a name for yourself as a testing coach; offering advice to testers free of charge via Skype. In your experience, what areas require the most coaching on your part? In other words, what does a typical tester coaching session cover?

AMC: Often testers come looking for coaching in a particular skill (e.g Test Automation), but many fail to understand basic testing concepts such as: “What is testing?” and “How do you determine bugs?”

Understanding testing is key to improving your testing skill.  After all, if you don’t understand something, how can you improve it?

Software delivery typically doesn’t allow for this type of introspection. Our jobs demand we focus on delivery, often to the detriment of how well we are doing our testing.

Coaching is the breathing space that all testers need to learn and grow.

In coaching I encourage testers to work through tasks to acquire skill. I’m there to guide and help them, but they need to work out the answers. That way, their learning experience is deeper and more meaningful and empowering.

uTest: James Bach, a fellow Skype coach, has said that one of the reasons he coaches testers for free is that he is “motivated by people who entertain [him] with their passion for learning.” What is your motivation for coaching testers?

AMC: I like to think there is a little testing genius in all of us. I get a sense of satisfaction if I can tap into that and liberate it.  If a tester leaves my coaching sessions feeling motivated and confident about their testing skill, I feel motivated too.

uTest: James also mentioned that he was working with you on a book about coaching testers. First off, how is the book coming along? And secondly, what is the most significant thing you’ve learned from your coaching sessions?

AMC: The content is at the point where there is sufficient content to hold a couple of workshops on coaching. In fact, I’m holding one on the 4th May in London, and one with James Bach in Sydney on the 29th May.

I think this is a significant point in the maturity of the coaching model.

Coaching has taught me to be humble and respect people. I have a tremendous admiration for testers who ask to be coached. I think this takes courage especially for testers who have been in the industry for a while.

It also helps me gauge the amount of knowledge and skill I have as a tester. If you want to fully understand a topic, try teaching it! This has given me a tremendous confidence boost. I’m reaching goals I’d never even imagined possible a year ago.

uTest: Speaking of publications, you were an author of the popular book How to Reduce the Cost of Software Testing. Your chapter dealt with the cost of setting up a test team. For those who haven’t read it, what is the biggest misconception managers and executives have with regard to the cost of setting up a test team? And how can they avoid making these mistakes?

AMC: There’s a misconception that creating a visible testing structure is the equivalent of testing. This is not true. What makes a house a home? Not the roof or the external walls, but the people inside the house.

It’s the same for testing. Testing is about the testers, their skill and discipline and how they interact and behave with others.

That’s what companies need to focus on when setting up a team.

uTest: In terms of money, time and effort, what is the biggest waste of resources you see in testing today? Certifications? Test reports? Automated tools? You tell us.

AMC: Behind this waste lies the concept that there is a simple solution to a complex problem. The above solutions are wasteful when they aim to easily resolve a complex problem. If we could stop looking for the silver bullet, then perhaps these wasteful solutions wouldn’t look so tempting.

uTest: True or false: Startups are less concerned with quality and testing than larger, established companies.

AMC: Its not true or false.

There is never an easy solution to quality, both startups and larger companies struggle equally with it.

Many startups create quality products because if an idea is sufficiently new and valuable, people will consider it good quality.

Peoples perceptions on quality change over time, they start expecting more from a product. Often what was acceptable when a product is launched quickly becomes unacceptable to a user. It’s important that a startup understands and manages the transient nature of quality. One possible solution is a skilled tester, but it’s not the only solution.

Many larger companies equally struggle with quality. As companies grow and mature they become more concerned about demonstrating due diligence than being diligent about quality and become fixated on process and demonstrable results.

These are not easy problems to solve, but it helps to understand what quality is and how much it means to you.

uTest: We noticed that you spent a few years as a Y2k test specialist with IBM. First off, thanks for keeping civilization together. Seriously though, tell us a little bit about your responsibilities in that role. Was the run up to 2000 as hectic and scary as it’s often portrayed to be?

AMC: Glad to be of service!

On hindsight, Y2K was more about compliance and limiting liability than testing. Perhaps there was a valid cause for concern, but I never experienced any of it where I consulted.

In the software business, it’s all about precision, as even the slightest coding mistake can lead to catastrophic failure. This lesson is clearly not lost on the folks over at the United Nations telecommunications agency, who are meeting as we speak to decide whether or not to abolish the leap second. That’s right, the leap second.

The Sidney Morning Herald explains how this relates to software testing:

Unlike the better-known leap year, which adds a day to February in a familiar four-year cycle, the leap second is tacked on once every few years to synchronise atomic clocks – the world’s scientific timekeepers – with Earth’s rotational cycle, which, sadly, does not run quite like clockwork. The next one is scheduled for June 30 (do not bother to adjust your watch).

The United States is the primary proponent for doing away with the leap second, arguing that these sporadic adjustments, if botched or overlooked, could lead to major foul-ups if electronic systems that depend on the precise time – including computer and cellphone networks, air traffic control and financial trading markets – do not agree on the time.

Abolishing the leap second “removes one potential source of catastrophic failure for the world’s computer networks,” said Geoff Chester, a spokesman for the US Naval Observatory, America’s primary timekeeper. “That one second becomes a problem if you don’t take it into account.”

By now, you’re probably wondering what the “debate” is all about. Is anyone voting in favor of catastrophic failure? On the other hand, how can a unit of time be abolished, even if it’s only a second? The story continues:

But Britain, along with Canada and China, would like to keep the current system, arguing that, in the 40 years that leap seconds have been gracefully inserted in our midst – most recently in 2008 – there have been no problems to speak of, and the worriers have greatly exaggerated the potential for havoc. Remember Y2K?

“It’s the devil we know,” said Robert Seaman, a software engineer at America’s National Optical Astronomy Observatory. While he is an American, he is also a member of another group wary of the change: astronomers. If a software-guided telescope is not pointed in the right direction, it may not capture the right image, and updating software could be a sizeable task.

Since the 1950s, the world has run on two sets of clocks. One is the ticking of atomic clocks, defined by the precise frequency that electrons jump around in atoms. The other is based on the traditional notion of a spinning Earth.

Anyway, I wanted to bring this story to your attention for two reasons. One, I find it fascinating. And two, to find out what experiences you’ve had with small bugs that led to big mistakes. So please, share your experiences in the comment section below….and be sure to take your time

A teacher in Massachusetts dedicated a computer class to developing and testing mobile apps. The Education Secretary in the UK is calling for a total program overhaul of country’s computer education curriculum. Now, the Mayor Michael Bloomberg of New York City has declared that an entire public high school will be devoted to teaching students software engineering. From Government Computer News:

“Today, far too many of our graduates are leaving without the skills they need to succeed beyond high school. Not every student wants to go to college, nor is college right for everyone. But all students should leave prepared to succeed in the next phase of their lives,” Bloomberg said. “It’s a new way of thinking about secondary school based on today’s economic realities.” …

Frank Thomas, a spokesman for the city’s Department of Education, anticipates that the school will have between 420 and 460 students by 2015, when all four grade levels are enrolled, Adrianne Jeffries reported in BetaBeat. The school will start with a ninth-grade class this year and add on another grade level for the next three years.

The city has other specialized high schools for science, math, the performing arts and other subjects, but it did not have one focused on computer science. …

Joel Spolsky, a board member of the new school, said one reason he’s a proponent of the school is that it could can train many excellent software engineers who are not currently at the top of their class academically.

“I think this is the best thing about the school,” he said in a blog post. “A lot of kids are just not interested enough in other academic subjects to get good grades, but they would make great software engineers. A lot of immigrants (especially in New York) are not yet proficient enough in English to get good grades in all their subjects, but they’re going to make great software engineers, too.”

I have to say, one instance is cool. Two instances make you raise an eyebrow. Three instances (especially when they’re consistently bigger examples) might just be the start of a trend. And this trend of focusing not only on computer basics, but on more advanced – more engaging – computer topics that can lead to lucrative, fulfilling career paths is long over due.

While our usual maniacal focus is on quality over quantity, it’s not unreasonable to recognize a major milestone that occurred today, January 18, 2012: surpassing 50,000 testers in the uTest community! Just to be clear, that’s over 50,000 testers from 185 countries around the world – from experts in automation to gurus in usability testing. Here are several other facts about our community:

• Every month, there are approximately 1,000 new tester registrations
• Over 99.9% of these registrations are organic – word of mouth, tradeshows and conferences, tester referrals
• The majority of testers span rather evenly across North America, Europe, and Asia. The rest fill out in South America, Africa, and Australia
• Over 80% of uTesters have a Bachelor’s degree or higher
• uTesters bring a wealth of knowledge and diverse set of skills to the table: creating test cases, usability surveys, load and performance scripts, automation scripts, security coverage reports, usability audits and expert reviews; executing test plans, usability surveys, live load test cases, security scans, exploratory tests, and translation tasks and proofs

And…back to our maniacal attention to quality. Although there is certainly strength in numbers and meaning to this milestone, the real excitement stems from the various “homegrown” programs that shape our crowdsourcing model. Less than a year ago, we announced several new initiatives that have transformed the uTest community from an unruly crowd to one that is self-sufficient, self-teaching and self-policing. From paid leadership roles for our top testers to unpaid auditions for newbie testers, there is a role for nearly everyone and a path for the most ambitious. And now that most of us have embraced the New Year, it’s only fitting that there are new programs just around the corner – ones that leverage the foundation built in the past year and continue to benefit our community at large. More details to come shortly!

For now, please join me in raising your glass to celebrate this major milestone with us!

Think optimizing for mobile web isn’t important? Think again! This was reported by PCWorld:

Tablet computers will eventually replace laptops, according to nearly half of Americans polled earlier this month.

But don’t panic yet …

Of course, “eventually” is a very long time, and the recent rollout of Amazon’s Kindle Fire and anticipation over the Apple iPad 3 might have survey takers overreaching a bit.

While the Poll Position phone survey of 1,155 registered voters found great enthusiasm for tablet computers, with 46% saying tablets would surpass laptops eventually, 35% said tablets will not replace laptops and 19% had no opinion.

Among younger Americans (18-29 age group), 49% said tablets will not replace the PC and 37% said they will. A higher percentage of men (53%) than women (39%) foresee tablets overtaking laptops.

The tablet market was hot last year and is expected to remain so this year. IDC recently said it expected 2011 worldwide tablet shipments to total more than 63 million units, with Apple selling about 6 in 10 of those. Recent Canalys figures show a total PC market of 356 million units in 2011, minus tablets.

While those numbers don’t point overwhelmingly in one direction or the other, it is food for thought. Plus, the prevalence of tablets (and mobile devices in general) has crept into quite a few 2012 predictions in the past few months, including this excerpt from Boston.com’s Global Business Hub:

Mobile and Tablet: Leapfrogging

In 2010, for the first time in the history of computing, tablet sales have surpassed desktop sales. Yet many companies continue to channel most of their investment into their web presence, continuing to think of their mobile and tablet use as an adjunct nicety. Expect that to change in 2012. The savviest of marketers will also know how to appeal to the untethered consumer. They will harness geo-localization technologies (Foursquare-style check-ins and soon even walk-bys) for customized offers, better use QR codes to gather data and link to in-store experiences. And outside of the US, mobile is increasingly playing a larger role as is mobile use is often stronger, with wireless technology often superior to older line-bound networks.

If you’re considering creating a mobile app or a mobile website (and you probably should at least consider it), don’t forget that mobile versions shouldn’t just be carbon copies of your desktop-based site/software. People are constantly on-the-go and increasingly expect their apps to know where they are and adjust accordingly. If your site/software is something that can be adapted to fit constantly changing environments and you want to jump into the local-mobile offers game, make sure you do it correctly with in-the-wild localization testing. Here’s why (again from Boston.com):

Internationalization and Localization: Relevance Rules

While in theory the internet has no borders, few companies know how to effectively garner and cultivate an international audience effectively. Expect that to change in 2012. Data shows that brands with localized web and social media presence enjoy far greater engagement and brand buzz. But the distinction between internationalization and localization is an important one. Successful localization efforts go far beyond language translation alone. They create and encourage content that is relevant to the local audience. Expect companies to pay more attention to the other 88% of internet users that don’t live in the US.

One of the biggest fears of companies developing new software or app or launching a new website is that some fundamental bug will slip through the testing cracks and only rear its ugly head post-launch.

That fear is compounded these days now that review sites and social media make it effortless for dissatisfied customers to voice their grievances not only to their friends, co-workers and next store neighbors, but to all the friends, co-workers, next store neighbors they’ve ever known. Plus a slue of strangers they don’t actually know.

Now, in addition to written complaints and bad reviews, the general public can share images of software bugs. Check out this story on TechCrunch about a guy who posted images of Facebook bugs on Pinterest (think of his board as flypaper for Facebook bugs):

Former Facebook engineer (and current Phabricator creator) Evan Priestley has taken the opposite route; In the spirit of coding excellence, Priestly has created a Pinterest log of over 30 Facebook bugs he’s tracked since September 2011. It’s really impressive.

The article goes on to say that bugs on Facebook aren’t that crucial because, let’s be honest, people aren’t going to stop using Facebook because Chat occasionally doesn’t load or you can’t update your status for a little while for some reason. But what if you’re a startup trying to get your product/app/site/game off the ground? Or a large company that’s been hyping a new product for months? A page full of image-documented bugs might just break you. Or in the case of a larger company, you’ll have some very visible, very public egg on your face.

Pinterest has been touted as the “next big thing” in social media and is growing rapidly. But before you say, “Well, it’s just Pinterest. You can’t even sign up without an invitation or going on a waiting list” don’t count the new to social site out. The top 10 Google News search results for “Pinterest” include a story about a website adding a Pinterest button its share options, seven articles detailing how popular and additive Pinterest is and two links to tips that will help brands leverage Pinterest’s popularity. Besides, you don’t have to be logged in to view boards (where images are categorized).

And if you need a refresher course in just how harmful a bad experience spread through social media can be, take a look back at the United Broke My Guitar debacle.

The moral of this post is don’t ignore testing. Don’t rely on just one type of testing. And make sure you test with every new release! Because you never know when “one small bug” is going to end up populating an entire board on the hot new social site.

Tired of useless, generic horoscopes that have nothing to do with software testing? Well then check out my useless, generic horoscopes that are written specifically for software testers!

Aries (March 21-April 19): It’s tempting to let the product team know how you really feel about their latest release, but you must resist. Workplace relationships hang in the balance. Your lucky numbers are 011000110101 and pi.

Taurus (April 20-May 20): The longer you test, the less successful you’ll be. A quick testing assignment, however, will yield great results. A test manager position is in your future. Also, the milk in the fridge is expired.

Gemini (May 21-June 21): You’ll have a competitive edge because you don’t mind using an open-source test tool. Others might say it’s “just for fun,” but part of the fun is that you’ll test more efficiently. By the way, the guy behind you is totally starring at your screen.

Cancer (June 22-July 22): You haven’t had the time to perform exploratory testing as much as you would like. An obligation will drop from your schedule, and the ideal way to spend this new-found time will be with your nose in a web app. A Facebook friend will post something stupid.

Leo (July 23-Aug. 22): One person sees a big issue and thinks: bug. Another person sees the same issue and thinks: feature. Either one could be correct. Realizing that others don’t perceive things as you do gives you an advantage today. You might also win the lottery (but probably not).

Virgo (Aug. 23-Sept. 22): There are those in marketing who will take up your time with pointless chatter. If it’s pleasant, you won’t mind. But if it’s both pointless and boring, you’ll take precautions not to be caught in the same situation again. Nod, smile and take comfort in the fact that you’re smarter than they are. Stay focused on testing.

Libra (Sept. 23-Oct. 23): There will be an opportunity to make money in localization testing. You probably won’t get rich, but the education is so valuable that you’ll come out very much ahead if you seize this chance. Not a great day for drag-racing, in case you were wondering.

Scorpio (Oct. 24-Nov. 21): If you’re not having fun testing today, you’re doing it wrong. Find ways to help others have more fun with their testing assignments. Be wary of tools vendors promising the world. A “reply-all” email mistake could cost you your job.

Sagittarius (Nov. 22-Dec. 21): Security testing is your calling card. You’ll embody the qualities of creativity and wit just when someone in your midst most need it the most. And if you think it’s a virus, it probably is.

Capricorn (Dec. 22-Jan. 19): Don’t over think your testing assignments. You could miss some serious bugs by approaching every test case from a purely intellectual standpoint. Automation should be avoided today, if possible. Googling yourself will yield a surprising new result.

Aquarius (Jan. 20-Feb. 18): Mix with those who have experience in the realm of test planning. Learn from someone who has “been there and done that.” You’ll gain insights and create the same success for yourself. A weekend in is your immediate future.

Pisces (Feb. 19-March 20): You’ll be surprised by the shards of past pain that reemerge in your regression tests. Be patient. Testing is a process. The answer to all of your problems is 42.

Loosely adapted – and I do mean loosely – from Holiday Mathis’ Daily Horoscope.

Have a great weekend everyone!

A few months ago I wrote about a high school computer teacher who worked mobile app development and testing into his curriculum. Well, it looks like he’s not alone. According to British news site The Register, Michael Gove, a member of the British Parliament who also serves as Education Secretary, is proposing a major revamp to the country’s computer education program. Here’s part of the Register article (emphasis added):

Education Secretary Michael Gove today proposed killing off Blighty’s ICT curriculum in September to give it a thorough reboot.

Launching a consultation into his plans, Gove suggested that from the start of the next academic year, schools should be able to teach what they want in computer classes. The Tory minister recommended MIT’s Scratch – a programming language for newbies – and the Microsoft and Google-approved Computing at School course for 11 to 13-year-olds.

The current ICT curriculum is “dull and demotivating”, he said in his speech to the BETT conference, and tweaks to qualifications and the curriculum in past have not led to “significant improvements”. …

Outlining the plan for 2012-14, Gove said:

Technology in schools will no longer be micro-managed by Whitehall. By withdrawing the Programme of Study, we’re giving teachers freedom over what and how to teach, revolutionising ICT as we know it. …

Imagine the dramatic change which could be possible in just a few years, once we remove the roadblock of the existing ICT curriculum. Instead of children bored out of their minds being taught how to use Word and Excel by bored teachers, we could have 11-year-olds able to write simple 2D computer animations using an MIT tool called Scratch. By 16, they could have an understanding of formal logic previously covered only in University courses and be writing their own apps for smartphones.

For those not living in the UK, ICT stands for “Information and Communications Technology.” As always, people are coming down on both sides of issue and there are still details to be ironed out. (For more details, read the full article.) But overall, I think it’s an interesting idea.

Having gone through the US public education system I can tell you from experience that the “computer” class I took in 11th grade might as well have been my daily nap time. By middle school I already knew what I needed to know about Word, Excel and Powerpoint. I can only imagine that it’s even worse for current students.

So why not divert the focus away from the basics as kids get older and teach them a new skill that might spark a life-long passion and career path. After all, there’s already an interest in it.

What is community management without measuring the pulse of your community? Every now and again it is important to take a step back from the frantic happenings of the day-to-day activities of uTesters and look at the bigger picture. All too often, we forget about the profound and incredibly human impact we have on the lives of uTest’s biggest asset, our testers.

At the end of 2011 we did just that and asked our testers to tell us about their uTest experience. Those of us on the community management team were certainly touched by the impact these experiences have had on their lives and we believe that they may be enlightening to other readers as well.

Here is a small sample of the great stories that were shared:

I found uTest on a fluke; I’d heard there was a group online looking for help and I searched for ‘online testing’ and uTest was found. Though I’ve only been with them for a couple of months, it’s been fun. Now let’s get it straight, work is not always fun, but with uTest the diversity of products and engaging clients and testers make it fun. I’ve worked in small startups and large companies; uTest seems to embrace the individual aspect of a small company though the clients may be very, very large. Always approachable and quick to reply, the folks running the group have earned my deep appreciation and respect. Of the dozen or so of projects I’ve worked on, each is unique, and sometimes has follow-up work.

I’m looking forward to 2012 with uTest.

Good going!

- Hamilton

2011 was a great year with uTest. I joined in March of 2010 after getting laid off from my job and quickly found that I could make a living without having to work directly for a company. I had always thought about it but the security the company provided was hard to give up. Well, after they laid me off that security was gone. Luckily uTest was there and I had a lot of time to give them.

So while 2010 was all about proving that I could not only get by on my own, but actually make a living, 2011 presented me with a challenge of growing myself as a tester. Once again uTest provided. I took on opportunities to get into automation, TTL work, some security and usability testing, all of which I had some experience in, but I made some big leaps forward this year.

One thing that uTest has done for me was to get rid of that nagging feeling that it would be too hard or too scary to be outside of the comfort zone I was so used to working in the corporate world. I have been able to work on many types of projects for companies both very large and very small and across the whole spectrum of the IT world. It has shown me that not only am I capable of working these projects but that I can do a pretty good job as well. So basically my confidence level is way up and that is a priceless gift.

Thanks to everyone at uTest for the opportunities and for the help when I needed it. And here’s to hoping for an even better 2012!

-John

I joined uTest in March 2010. I have to say that it has far exceeded my expectations as far as what I could earn and has been the one thing that I’ve tried online to bring in some extra cash. I really enjoy what I’m doing and plan on continuing for a long time, and maybe in 2012 I’ll be one of the ones who decided to take the plunge and become a full time freelancer. And even if I don’t, 2012 is still going to be an awesome year!

-Peggy

These are just a few of the stories that were shared. If you are a uTester you can read more of these stories in our community forums by visiting this link http://forums.utest.com/viewtopic.php?f=26&t=2737. And if you’re not a uTester but would like to be, sign up today and learn how uTest can change your life.

Our community of professional and passionate testers is at the heart of uTest and it is what makes us truly unique. As we kick of 2012 we recognize that there are vast opportunities available to our community, not only for more work but also to learn, to mentor (or be mentored) and network with nearly 50,000 software testers across the globe. We look forward to pushing the envelope of crowdsourced, in-the-wild testing and will certainly take another pause at the end of this year to look back into 2012.

Until then, Happy New Year and Happy Testing!

Need to find a nearby restaurant? There’s an app for that. Want to track your workout progress? There’s an app for that. Want to play a game to kill the time? There’s an app for that. Your kids want to play a game? There’s an app for that. Want to check the score? There’s an app for that. Want the latest headlines/facebook status updates/tweets? There’s an app for that. Want to access that document or program you use at work on the go? Maybe there’s an app for that, kind of.

Many consumer apps have figured out how to cater to the specific limitations of mobile devices (screen size variance, touch screen usability, the range of OS options) but professional apps are still largely lagging behind.

Quinton Alsbury (who owns a company – MeLLmo – that develops apps for businesses) highlighted where many business-minded apps are going wrong in this guest post on CNet:

We’ve all been there–squinting at a spreadsheet on a mobile device, zooming in and out in attempt to make sense of the information. Each swipe of the finger triggers a blank screen as the data renders and slowly reappears and our frustration builds. …

Why do apps aimed at business users continue to cram features and functionalities designed for the PC into a mobile phone, ignoring all the things that make consumer apps successful–namely, design, speed, and interactivity?

Many business app developers are fundamentally misunderstanding the mobile user experience by producing “shrink to fit” versions of solutions designed for the PC. The mobile experience isn’t about accessing several gigabytes of data; it’s about quickly accessing the information you need, when you need it.

By “shrinking” existing PC tools, they’re essentially jamming a large, complicated, and bulky system onto a smaller screen. What results are apps that contain too many features, respond too slowly and ultimately result in low user adoption and usage.

Information Week also recently featured a commentary piece on the bulky state of business apps. Maribel Lopez, the author, agreed that professional apps do not preform as well as most consumer apps. But she was careful to highlight some additional challenges to creating a professional app.

First, what should the company mobilize? Companies have dozens, if not hundreds, of apps, many of them custom built. … Also, the company needs to mobilize a whole process, not just an app. Mobilizing one app may allow an employee to complete only a portion of a process–finalizing a sale, for example, is often composed of transactions from multiple apps, such as CRM, inventory, and purchasing.

Second, how should I mobilize these apps? Does IT build apps that are native to the device, embrace an HTML5 mobile Web experience, or build a hybrid of native and Web? If it selects native app development, it also has to choose which mobile operating system platforms. … What companies are learning is that there’s no single software development model that works for every mobile scenario. Most businesses will use a mix of native, hybrid, and mobile Web. The decision will depend on the depth of functionality the app requires.

Third, what are the top priorities for mobile development? … Just taking an app that was created for desktop use and making it accessible on a mobile device won’t work. IT must understand what functions of the app should be accessible on a mobile device, and how much they need to be revised for mobile work.

Maribel is taking the angle of companies developing their own specialized, customized apps, but her points also apply to outside groups looking to develop a good general business-facing app. You can’t fit all the features of a desktop app into a successful mobile app – and honestly, you probably don’t need to. Maribel recommends taking a step back and starting simple:

Many businesses try to replicate the entire desktop app for a mobile device. For an initial mobile rollout, it is perfectly acceptable to pick one or two functions of the application and deliver those well. … And once the mobile app is live, be prepared to listen to employees, hear what’s missing, and quickly add new features.

That last sentence is really the key – figure out what the employees want and need, and forget everything else. A successful app is only successful because users decided to actually use it. And on that note, here’s a list from Entrepreneur of the “10 Must-Have Business Apps for 2011“:

• Square (payment)
• Evernote (task management)
• Scanner Pro (document scanning)
• Flight Tracker Pro (travel)
• MightyMeeting (presentation management)
• Gist (contact management)
• LinkedIn (contact management/networking)
• Print n Share (wireless printing)
• Jump Desktop (remote desktop)
• OmniFocus (task management suite)

These apps are fairly basic business/business person apps – nothing too specialized or intricate – but still important and useful to business in general. Interestingly, three of Entrepreneur’s top apps were also on a PCWorld top 10 business apps list in 2009 while others fulfill the same need but replaced the earlier top performers.

As the two lists prove, there’s been a fair amount of turnover in the business app market over the past few years, and that’s bound to continue. But with the use of smartphones growing and the new trend of companies allowing their employees to use their own phone, 2012 might be the year business apps catch up to the success of their consumer counterparts.