Testing Roundtable: What Do You Like Most About Testing?

Let’s face it: Testing isn’t always fun. There’s missed deadlines, missed bugs, stubborn developers, office politics and – well- you get the idea. Despite these pains, however, most people in testing truly love the work they do. But what do they like most about testing? To find out (and to brighten your day) I decided to make that the topic of this quarter’s Testing Roundtable discussion. Check out some great answers below from Jerry Weinberg, Scott Barber, Matt Heusser, Michael Cooper, Pradeep Soundararajan, Steve Vance and Peter Shih. Enjoy!

*********************

Gerald Weinberg, Author and Consultant

I like my software to do what I bought it for, and not do other things. Without testing, that won’t happen.

If you’re asking what I like most about *doing*, testing, well I like the software I help produce to be good at doing what people buy it for, but I think that’s not the answer you’re looking for. (You should be, though, because that feeling of pride in one’s work is essential to a successful profession.)

As for the actual work of testing, I like the intellectual challenge most. While testing, I feel like, say, Sherlock Holmes—-and nobody has to be murdered (usually).

*********************

Scott Barber, CTO at PerfTestPlus

I like the diversity of it. Take a recent week for example. I was helping one client devise a performance testing strategy for a database that is growing at the rate of 1TB per month that supports an application that enables M.D.s, Medical Test Labs, and Pharmacies to share relevant patient information, prescriptions, lab results, etc. essentially in real-time. I was working with a small team to figure out how to performance test a web-based voting application for a national (not North American) election that reasonably expects to need to securely & reliably process over 1 million votes per hour. I paired with a complete stranger to test a desktop application using screen and voice capture tools to document our testing and report defects. And I was testing a “teach programming to kids” application with my son.

But what I *really* like is the virtual impossibility of it all. While complete testing is not practically possible, balancing that against time, budget, technology, market, and human factors with a host of unknowns that feels bigger than the knowns, is the most fascinatingly challenging puzzle I’ve ever actively tried to solve. It’s a puzzle that always keeps me on my toes, always keeps me actively studying new things; from new technologies, to human psychology, to organizational management, to whatever industry my current client is in. For a person who loves to learn, loves to make a difference, is motivated by seemingly impossible challenges, gets bored easily, yet doesn’t want to be looking for a new career every 3 months, I simply can’t think of a field that is a better fit.

*********************

Matt Heusser, Writer and Consultant

Two decades ago I was a military cadet in the Civil Air Patrol, and I vividly remember a poem over our commanders desk:

“We the willing, led by the unknowing, have been doing the impossible, for the ungrateful.  We have been doing so much for so long for so little that we are now qualified to do anything for nothing.”

While the spirit of that poem was a little passive-aggressive, I have to say, I was inspired by the content, this idea of doing the impossible under tough constraints.

In some ways, I see this in software testing. From an infinite set of possible tests, we need to derive the most powerful ones.  We need to figure out what to test right now; what to do quickly, what to automate.  We need to figure out what the results of those tests tell us, and to give answers that stand up to scrutiny.

I call this the “Great Game of Testing,” and I don’t think it’s too much of a stretch to say that I am in software testing “For Love Of The Game.”

*********************

Continue Reading

Essential Guide to Mobile App Testing

Bug-Hunting Techniques From Matt Heusser

When it comes to finding defects in web applications, timing is everything. A bug found in production, for instance, will generally complicate matters more than a bug found in pre-production. This is also true of uTest projects, when testing is sometimes compressed into a shorter (than ideal) time-frame.

So to help you find the right bugs at the right time, we suggest checking out the latest article from our old friend Matt Heusser. In Seven Ways to Find Software Defects Before They Hit Production, Matt shares some valuable tips on ways to reinvigorate your testing. Here are three techniques that I think uTesters will find especially useful. Enjoy!

Technique 1: Quick Attacks

If you have little or no prior knowledge of a system, you don’t know its requirements, so formal techniques to transform the requirements into tests won’t help. Instead, you might attack the system, looking to send it into a state of panic by filling in the wrong thing.

If a field is required, leave it blank. If the user interface implies a workflow, try to take a different route. If the input field is clearly supposed to be a number, try typing a word, or try typing a number too large for the system to handle. If you must use numbers, figure out whether the system expects a whole number (an integer), and use a decimal-point number instead. If you must use words, try using the CharMap application in Windows (Start > Run > charmap) and select some special characters that are outside the standard characters accessed directly by keys on your keyboard.

Technique 3: Common Failure Modes

Remember when the Web was young and you tried to order a book or something from a website, but nothing seemed to happen? You clicked the order button again. If you were lucky, two books showed up in your shopping cart; if you were unlucky, they showed up on your doorstep. That failure mode was a kind of common problem—one that happened a lot, and we learned to test for it. Eventually, programmers got wise and improved their code, and this attack became less effective, but it points to something: Platforms often have the same bug coming up again and again.

Continue Reading

Essential Guide to Mobile App Testing

#STPCon Interviews – Matt Heusser

Next up in our STPCon 2011 video series is Matt Heusser – one of the most popular figures in the testing universe. Matt is currently the Editor of STP Collaborative, in addition to being an active member of the board for the Association for Software Testing.

In this short interview, he explains the ideas behind what he calls “complete testing.” Good stuff. Take a look:

Want to see more interviews from STPCon? Check out the full list here.

Essential Guide to Mobile App Testing

The Book On Software Testing

Ok, so it’s one of many books on the topic of testing. Still, how many crowdsourcing companies can honestly say that their community includes a published author (not to mention a top journalist in their space and former Testing The Limits guest)? Well, that’s the case here at uTest with Matt Heusser (@mheusser).

Anyway, this is a worthwhile read for two reasons:

  1. Heusser knows of which he speaks, as he’s not just a pundit. This guy has lived it, running QA organizations within large and small companies.
  2. Whether they’ll admit it or not, the TCO of testing is a major concern for tech execs in all industries. So any book that tackles that issue head-on is both ambitious and timely.

For those who purchase How to Reduce the Cost of Software Testing, drop us a note and let us know what you think. We’ll publish your comments in a follow-up post.

Also, we’ll see if we can wrangle an interview with the brains behind the book (Heusser and Govind Kulkarni) in the next week or so. Want us to grill them on anything in particular? Drop us a comment and we’ll put ‘em on the spot.

Essential Guide to Mobile App Testing

Mobile App Testing: This Is Different!

We’ve spent the last year (that’s 253 posts on mobileapptesting.com) explaining to the world that mobile is an entirely different animal than its web and desktop cousins. Whether the differences be in terms of OS, browser, screen size or GUI – you name it, we’ve covered it. Extensively.

Yet this concept is….well, just a concept…until it’s experienced first-hand. Matt Heusser, one of the very best testing writers out there, recently shared some details on his (first?) foray into mobile app testing with SearchSoftwareQuality. His account covers screen-size discrepancy, the expanding device matrix, GUI issues and other testing topics we all know and love.

I was particularly drawn to his “ah-ha” moment in the second paragraph (emphasis added). Take a look:

So there I was, on my iPod Touch, trying to get to a list of users whose name started with the letter “I.” It worked great on the simulator with a mouse, but with the actual iPod, my finger was too fat to click the single line of pixels.

Suddenly it hit me: This is different. Sure, all of the old GUI rules apply, but suddenly we have a new set of ways the application can fail. This tip provides a quick set of guidelines to consider, primarily for Web-based mobile applications, but much of it applies to native applications a s well.

Screen real estate

You might use a mobile device just like a regular 1024×768 pixel application, but your users probably won’t. Try to actually use the application on a number of devices — just use it. You’ll likely come away suggesting a mobile interface, perhaps an automatic re-direct on login when your application senses a mobile device. Even then, you’ll want to explore the application in a number of devices, looking for usability problems.

Continue Reading

Essential Guide to Mobile App Testing