In Part II of our Testing the Limits interview with Michael Bolton, we get his opinions on the corporate fear of Rapid Software Testing; the challenges of coaching testers; the similarities between testing and sex; why programmers should learn to test; writing about testing; negotiating with the other Michael Bolton and more. Did you miss Part I? Then you can find it here.

uTest: It seems that your primary audience is fairly open the principles of RST. But for those who aren’t, what are their main objections? Have the skeptics made you rethink or refine any aspect of RST?

MB: The primary objection appears to be that people are reluctant to give up their safety blankets. They’re frightened of reducing bureaucracy and paperwork, because those things appear to make testing work more legible.  But that’s an illusion:  bureaucracy and paperwork make illusions about testing work more legible. (Have a look at James C. Scott’s Seeing Like a State for a wonderful description of legibility and how the neo-Platonists and the high modernists get it wrong for everyone except—sometimes–for themselves.)  People seem frightened to invest in skill, because even though skillful work can be very well documented, it doesn’t necessarily leave a familiar kind of paper trail.

People seem frightened of telling a different kind of testing story in a different way, because managers have become used to a certain kind of test reporting.  I think most companies are frightened of finding out what’s really going on in a product or a project, because the truth would be pretty horrifying in a lot of cases.  People are frightened of acknowledging the role of skill and tacit knowledge in technical work, because they’re frightened of having to replace people who leave. The assumption there is that the new hire only learns through documentation, but that’s clearly false; we learn through social interactions, by interaction with our products, and by doing meaningful work for which we’re held responsible.

One more thing:  many people whose jobs are titled “quality assurance” seem unwilling to give up their perception of their own authority. People want to be “influential”, to “own quality”, to “be the gatekeeper”, to “speak for the customer”.  I don’t have authority over the project unless I’m the project manager.  As a tester, I don’t have that authority, nor can I claim to speak for the customer more credibly than anyone else. I’ve met testers who believe that it’s their prerogative to tell programmers what to do or how to do it.  I recommend that such testers reflect on how they feel when they’re told what to do by people who’ve never done testing work.

As for what we’ve done to rethink or refine things, that’s a continuous process. James and I are currently working on a few important threads. I learned a great lesson from Jerry Weinberg in his Problem Solving Leadership workshop a few years back.  Someone accounted for a less-than-successful attempt at problem solving by saying “The complexity of the problem screwed us up.”  Jerry peered over the top of his glasses and replied, “Your reaction to the complexity of the problem screwed you up.”  So in the delivery of the class, we’re trying to focus on helping testers to see the simplicity behind complex situations, so the testers can be more confident in their ability to deal with them. On the other hand, we’re also focusing on helping testers to see the complexity behind apparently simple situations, so the testers have the wariness that they need to avoid being fooled too easily.  We’re also working on showing how to use Rapid Testing approaches in highly formalized or highly regulated environments, pointing to our experiences in financial and medical contexts. Excellent format testing (which is often confirmatory or demonstrative) begins with excellent informal testing. Consistent with that, we’re trying to make people aware that the bulk of their work is exploratory in nature, even though they might not have noticed it.  “Formal testing”, which often takes the form of dog-and-pony shows for regulators or auditors, is one thing. Testing to make sure that people don’t die or lose a fortune or pile on some horrible risk is another thing. Excellent testing of the former kind of testing depends on excellent testing of the latter kind.

uTest: If the Context-Driven School of Testing were a traditional school, there’d be a lot of students on the waiting list. In other words, the community is growing rapidly every day. What’s surprised you the most about the emergence of the Context-Driven community thus far?

MB: How slow it’s been, and how small it remains; how quick it’s been, and how big it’s getting. What’s surprised me mostly is that context-driven principles still seems non-obvious to other people. But I suppose they’re context-oblivious, or context-specific, or context-imperial as James has pointed out here.

uTest: We were interested to learn that you – along with your friend and colleague James Bach – spend a lot of time coaching testers over IM, free of charge. What sort of questions do these testers come to you with? Are they generally practical or abstract in nature? And what’s been the most significant thing you’ve learned from this experience?

MB: The questions are usually pretty specific.  They tend to be focused on how to relate to the rest of the project team, especially managers and programmers.  The general form of the answer is this:  learn how frame your testing; tell the product story; tell the testing story; and tell the story about the quality of your testing.  And practice doing that.  Then most of those problems go away.  The general form of answering the question is to give the testers model problems to solve, and then to help them work through those problems. I often get questions about how to deal when there’s no (or bad, or incomplete, or inconsistent) documentation; we help people understand that documents and artifacts are only one way (often a very poor way) to learn about something. I often get questions about how to estimate testing effort.  I’ve answered that here and here, but people learn better when they experience the dialogue.

uTest: A noted testing figure was recently quoted as saying “Testing is like sex. If it’s not fun, then you’re doing it wrong.” First, can you guess who that certain someone might be? Second, do you agree? And third, what are some simple steps testers can take to make testing more like sex (i.e. fun)?

MB: I’ve said this myself for years, but pretty circumspectly. I’m not claiming I was the first to say it; to me, the joke is so obvious that claiming credit for it would be embarrassing even for the first person who said it. But yes, absolutely I agree.

As for the third question… oy vey, it’s going to be tough to answer that without getting into lots of trouble. Mischievous fellow, aren’t you?  Okay, let me give you a few things that you can say about both sex and testing:

a) Don’t ever, ever use it to hurt or embarrass people.

b) We shouldn’t be scared to learn about it, because if we are, many people will be inclined do it irresponsibly and unsafely, which leads to it being not fun at all.

c) It’s how the human species has survived this long, although not without some cost.

d) Don’t let your eyes make your decisions for you.  The good-looking ones aren’t always the best, or the best for you.

e) Whatever your thinking about human sexuality might be, ideas weren’t meant to be monogamous, and they weren’t meant to live alone. Let ideas be frisky, and let them play with each other and make new ideas together. That goes double for ideas about testing.

There is one other thing that I have said before about the relationship between testing and sex.  Testing certification the way it’s currently practiced goes mostly like this.  You go to a room, typically in a hotel. You greet someone you’ve never met. You spend a few hours together, answer a few awkward questions.  Then you get up and leave a goodly sum of money on the table, they say “Thanks, you were great,” and then you never see each other again.  Does that remind you of anything?

uTest: You recently wrote a blog saying that testers should learn to program. Conversely, should programmers learn to test? Why or why not?

MB: Programmers should learn to test. They do learn to test. Most programmers attempt to run the code they’ve written and look at it critically to some degree. Great programmers do that testing in a really diversified and yet focused way. What I’d like to get rid of is the idea “I program, I test, and therefore I know all I need to know about testing. I’m good.” To test really well requires study of many ways that things can go wrong, and many ways in which we can be fooled, and many approaches for defending ourselves against them.  The best programmers I’ve ever worked with were themselves excellent testers, but they were also aware of their own limitations. They were really respectful of good testers, and, of course, good testers were respectful of them. It was a virtuous cycle.

It’s hard to figure where this goofy idea “programmers can’t test” came from.  It’s ridiculous. It’s probably a misstatement of the idea that programmers have blind spots with respect to their own work, but that’s just like everyone else in every discipline.  If you think a programmer can’t test, give him or her someone else’s code or product to look at; they’ll usually do really well at finding problems and inconsistencies.  I invite organizations to send programmers to the Rapid Testing classes, and they always do fine. Not surprisingly, they often find stuff that testers tend not to find. For example, during testing exercises, the programmers often go looking for source code, and then they find certain problems there that other testers don’t find.  But like everyone else, programmers get trapped by something in the exercises, and therefore like everyone else (including me), they learn something new about testing.

To me, the real issue, the real reason why we need testing specialists is this quite gross generalization:  in my experience, most programmers more passionate about creating programs than about exploring them and all the stuff around them.  They’d probably be fine at it, but it’s not where their centre of gravity is.  That’s okay; that’s what we testers are here for.

uTest: You’ve built quite an impressive readership on your blog dating back to 2004. We always urge testers in our community to start a blog themselves, so we’re wondering if you could offer them some quick advice on how to get started, how to keep it fresh and how to encourage discussion and debate among their fellow testers.

MB: Write from experience.  Write about the things that interest you, both inside and outside of testing.  Write from your head and your heart.  Read and watch and observe and synthesize like crazy to bring new stuff into the craft from whatever you do or whatever you see.  And once you’re written about it, let people in your community know you’ve written about it.  Use Twitter and LinkedIn and Facebook for that.

uTest: Similarly, you’re also constantly being introduced to new personalities in the testing space through your blog, your courses and presentations. Any rising stars of software testing that we should keep an eye on?

MB: The Weekend Testing community worldwide.  Pete Houghton. Markus Gaertner. Goranka Bjedov. Ben Yaroch. Griffin Jones. Anders Dinsen. The Dutch Exploratory Workshops on Testing community. Lynn McKee and Nancy Kelln in Calgary. Just this month, Eric Jacobson did a killer job at his first conference presentation, at STAR West. I’m really proud that Eric and many of these folks are Rapid Testing alumni. Those are just a few of the stars that I see rising. Google and Twitter will help you find them.

uTest: Obligatory Michael Bolton question: It’s looking like you’ve made quite a name for yourself on Twitter and in the press for not relinquishing your handle to the other Michael Bolton. Hypothetically, what would it take to wrestle that handle away from you? We’d be more than happy to act as a broker.

MB: Enough money for me to retire and to pay you the commission that you would so richly deserve for swinging the deal. Not that I want to retire; I’d just like to have enough money that I could. Oh, plus an apology for adopting my name.  His isn’t really Bolton, you know.  It’s Bolotin.  Russian, I believe.  He changed it because he was sure that radio DJs would never pronounce it correctly.

uTest: Where can we expect to see Michael Bolton next and what will you speaking/presenting about?

MB: I’ll be at EuroSTAR in Manchester this year, talking about measurement in a new one-day workshop, and talking about dashboards in a track session.  I’ll be doing public Rapid Testing classes in Nieuwegein, London, and Oslo before the end of the year, and there’s a public class penciled in for Finland in January.

Rapid Fire…..

Better beer: Canadian or German?

Duh. Guinness.

Favorite Frank Zappa album?

One Size Fits All.  Sofa, the instrumental, is a heartbreakingly beautiful piece of music.  But I also like the vocal arrangements on the mid/later period stuff—You Are What You Is, and Joe’s Garage.

Exotic pet of choice?

I used to be a dog person; then I was a cat person.  Now that I have a daughter who’s obsessed with horses, I’m seriously into low-maintenance mode.  Can I choose something stuffed?

Favorite inventor?

I’ve met Ward Cunningham.  He invented FIT—the requirements tool that’s at the conceptual core of FitNesse—and the Wiki. That’s a pretty good track record, plus he’s a great soul. Gotta consider what Les Paul did for us, though.

Mac or PC?

I’ve been around PCs for a long time.  What I liked about them at first was the idea that I could comprehend them, that I could control them.  That’s totally out the window (Windows?) now; both platforms are absurdly complicated and neither of them give me any sense of control.  Give me TTY, the anti-GUI!  That said, if only they made a Mac with a TrackPoint mouse, Apple would get all of my money.  Every time I use one of those touchpads, I feel like a kid pushing a toy car across the floor… vroom, vroom!  Give me something where can type AND point without taking my fingers off the home row!

MB: One more thing:  these have been great questions, and I very much appreciate the opportunity to chat with you.  I’ve really enjoyed reading other interviews in the series.  So thanks to you and to uTest!

Editor’s Note: Thanks for reading – and thanks to Michael Bolton for taking time out of his busy schedule. Until next time…happy testing!

Our Testing the Limits “reunion tour” rolls on this month with Michael Bolton, back for another lively session of Q&A. Michael is best known as the founder of DevelopSense, his Toronto-based testing consulting firm, and as a leading figure in Rapid Testing and the Context-Driven school of testing. In short, he’s one of the industry’s most highly regarded writers, speakers and teachers – and it’s a real pleasure to have him back. For more on Michael, be sure to check out his website, blog or follow him on Twitter.

In part I of our healthy two-part interview, we get his thoughts on test cases not being related to testing; the sub-par debate skills of testers; the quality chain of command; objections to Rapid Testing and much more. Be sure to check back tomorrow for Part II. Enjoy!

uTest: It’s been almost two years since our last interview. Where does the time go? We’ve followed you pretty closely during that time (on Twitter, don’t worry), but for those who haven’t, what have they missed? New publications? New courses? New ideas on testing? What’s new with Michael Bolton?

MB: I’ve been traveling like crazy this year, and I’m booked pretty heavily through the end of the year.  I’m beginning to set up my schedule for next year—so if people would like to schedule an in-house class, now is a great time to ask.  For new publications How to Reduce the Cost of Testing, a new book edited by Matt Heusser and Govind Kulkarni, has just been released. I’m pleased to say that I’ve got a chapter in there, with a number of other members of our community.

I don’t specialize in new ideas in testing so much, but rather in refining and reframing ideas we’ve had for years in more specific and, I hope, more useful ways. The other thing that I love to do is to bring ideas from elsewhere into testing.  Currently I’m fascinated by the work of Harry Collins, who studies the sociology of science and the ways in which people develop knowledge and skill. Tacit and Explicit Knowledge is his most recent book; The Shape of Actions is older.  I’m most interested in the idea of repair, which is Collins’ notion for the ways in which people fix up information as they prepare to send it, or as they receive and interpret it.

As an example, I’m 5’ 8” tall.  If I ask you how tall I am in centimeters (and provide you with the ratio of 2.54 centimeters to the inch), you’ll probably do a little math in your head to translate 5’ 8” into 68 inches.  If you do that, it’s because you have tacit knowledge that a foot is 12 inches, and it’s quicker to do five times 12 in your head and add eight than to work it out on the calculator.  Then you’ll report that I’m 173 centimeters (or 172), rather than what the calculator tells you:  172.72.  If you round the answer up or down to a whole centimeter, it’s because you have tacit knowledge that the extra precision is useless when my height changes more than that with every breath. The calculator doesn’t know that, but people often fix up the interaction with the tool, applying that kind of tacit knowledge without noticing that they’re doing it.  Collins argues that we give calculators and computers and machines more credit than they deserve when we ascribe intelligence or knowledge to them, even when we do it casually or informally.

My latest hobby horse is definitely not new, but I’d like to have a go at it anyway.  I’d like to skewer the idea of the test case having any serious relationship to testing.  Test cases are typically examples of what the product should do. That’s important; we often need examples to help explicate requirements and desires. But examples are not tests, so I’d like to call those artifacts example cases or examples rather than test cases. They’re confirmatory, not exploratory; checks, not tests. Brian Marick has written a lot about examples; Matt Heusser has too; so has Gojko Adzic. James Bach has been railing about test cases for a long time.  Often test cases are overly elaborate, expensive to prepare and maintain.  They’d be even more expensive if testers didn’t repair them on the fly, inserting subtle variations making observations that the test case doesn’t specify.  Just as Collins suggests about machines, test cases get more credit than they deserve.  As Pradeep Soundarajan would say, the test case doesn’t find the bug.  The tester finds the bug, and the test case has a role in that.  Now: the development of checks and the interpretation of checks—those things require all kinds of sapience and skill.

A test, to me, is an investigation, not a bit of input and output for a function.  Yet people tend to think of testing in terms of test cases.  Even worse, people count test cases; and even worse than that, they count passing and failing test cases to measure the completeness of project work or testing work.  It’s like evaluating the quality of a newspaper by counting the number of stories in it without reference to the content, the quality of the writing, the quality of the investigation, the relevance of the report, whether a given article contains one story or a dozen, and so forth.  Counting stories would be a ludicrous way of measuring either the quality of the newspaper or the state of the world. Yet, it seems to me, many development and testing organizations try to observe and evaluate testing in this completely shallow and ridiculous way. They do that because seem to think about things in terms of units of production. Learning, discoveries, threats to value, management responses… none of these things are widgets. They not things, either, for that matter.

uTest: In a recent blog post, you wrote about the inability of some testers to properly frame tests, mainly because they haven’t been asked to. Generally speaking, what other qualities or skills do you find testers to be lacking in?

MB: Oh, dear, it’s so sad because there are so many gaps. James Bach, in a recent chat with you, identified rhetoric—how to speak and write clearly, articulately, and precisely—as something that many testers are missing.  Many testers aren’t so good at developing an argument (in the sense of a line of reasoning rather than a fight).  Many testers see obstacles to their work as problems for testing, when in fact they’re pretty much always problems for the project.  Testing helps to reveal those problems if you have an appropriate mind set.  (I wrote about that recently here.)   It seems that many testers, like many programmers, often lapse into the binary fallacy—something is either one thing or another, yes or no, true or false, pass or fail.

Tom Waits put it beautifully in an interview a couple of years back, when someone asked him about how he finds the truth of his character. “Truths,” he said.  “Truth isn’t a word that should be used in the singular. It should always be used in the plural.”  Rob Sabourin has been observing gaps in testers’ command of math, and how to apply it in testing.  As a craft, we seem to be aiding and abetting management in bad measurement; we need more people to study how to do measurement well. At the Pacific Northwest Software Quality Conference, I was delighted to see Kristina Sitarski—who studied anthropology in university—deliver an excellent analysis of interactions between herself and a tester she was pairing with, focusing on learning and perceptual styles.  If we want to be well regarded as a craft, we need more reports like this, based on studies of what we actually do.  We don’t need any more of the inept works of fiction and fantasy that you see in neo-Platonist process manuals.

uTest: We see that you were disappointed in the New Yorker iPad app, tweeting something to the effect of “it might have been tested, but it wasn’t fixed.” In your view, is quality lacking in the mobile space? If so, why? Is mobile inherently more of a testing challenge than its web and desktop cousins?

MB: When I tweeted that, the New Yorker app was crashing for me within a few moments of starting up.  I had to wait a few weeks while that got sorted out. The magazine as delivered to the iPad is typically on the order of 150MB in size, where (comparable product heuristic!) The Economist is on the order of 3MB.  The product would frequently crash during a download, and wouldn’t pick up where the download had left off.  Even if downloads were successful, downloading the New Yorker every week would wipe out the base amount of data consumption on my mobile billing plan.  It would be cheaper to buy the dead tree version of the magazine.

Certainly there’s a great deal of extra complexity to be dealt with in the mobile space, when we look at the number of different systems and functions through which a given bit of data passes, or the enormous number of platforms on which people want to run apps.  Before Windows came along to abstract the hardware, there were drivers for each video card, each printer, each mouse, each network card times each operating system.  But then each application program came with special drivers to talk to each kind of hardware.  Developing and supporting all that stuff was completely nuts. Since there’s a perception of lots of opportunity and lots of money in the mobile space, there’s a gold rush and lots of people are heading for the Klondike. Now there are competing mobile OSs, times all those versions of those OSs, times all those handsets and tablets and mobile browser versions and interconnecting apps and services.  So in a way, we’re back to the late 80s and early 1990s, back in the DOS days, when I first got involved with programming and support and testing.  Hey you kids, get out of my yard!

uTest: You’ve said before that “decisions about quality are inherently subjective” and that “testers are not responsible for making decisions about quality, but rather for informing decisions about quality.” So our subjective question for you is this: Should testers be responsible for making decisions about quality?

MB: Like everyone else, testers should be responsible for making decisions about the quality of their own work. But we already have lots roles and titles for people who make decisions about the work of other people:  we call them “product manager”, “program manager”, “project manager”, “product owner”, “director of development”, “vice president”, “CEO”.  I urge testers: You want to manage a project? Become a project manager.  I urge quality assurance people: You want to assure quality?  Make sure you have real, final authority over the product and the people who produce it. That is, become a manager. You’re not a gatekeeper of quality; you’re a speed bump on the road to quality.  (Speed bumps are also known as “sleeping policemen”.  That’s apt.)

uTest: You’ve been traveling the world the last few years teaching courses in Rapid Software Testing. In your experience, are certain regions of the world more open to this testing mind-set than others? If so, why do you think this is the case?

MB: It seems that Rapid Software Testing has a lot of traction in certain circles in northwestern Europe, especially Sweden, places where there seems to be a deal of room for intellectual rigor and independence at the same time.  Rikard Edgren had an interesting explanation for the success of rapid and context-driven testing there.  He said that the Swedes in particular believe really strongly in the social contract, that people are interdependent, that society should take care of everyone, that things like education and health care are rights, not privileges, and that people should reasonably expect get them at a high level of quality. And to pay taxes for them.  Although, he said, the Swedes aren’t crazy; no one likes paying taxes, but it’s part of the deal if you want all this other good stuff.  So there’s this sense of mutual support and strong government, and the Swedes (broadly speaking, of course) believe in that… but they don’t like other people telling them what to do.  When Rikard say that, I thought it fit really well with what we espouse:  We’re all in this together.  We give ourselves and each other freedom to do the right thing and to screw up.  We also take responsibility for our actions, and we take responsibility for taking care of each other.  We work collaboratively, but we recognize that few people like being under someone else’s thumb.  That kind of freedom combined with responsibility allows people to blossom, I think.  I’d argue the Baltic countries have been ahead of North America for a while in terms of politics and social issues. Rapid Testing is popular in New Zealand and Australia too, to some degree. It’s that spirit of independent interdependence, if you will.  James is excited about Estonia, too, but I haven’t been there.  Yet.  The UK has this emerging group too.  So we’re seeing shoots coming up through the snow.

uTest: In our last interview, you mentioned specifically that New Zealand and Scandinavia were producing some excellent testers with fresh insight and new ideas. Have your travels uncovered any other areas of testing innovation?

MB: When I do, they’re almost always local geographical pockets, or some skunkworks when they’re inside larger organizations.  Steve Green runs this cool little testing services company in England that focuses on skilled testers and very fast turnaround. Paul Holland has been doing rapid testing for years at Alcatel-Lucent, with excellent results. Pradeep Soundarajan is running a testing services company in India that specializes in rapid testing approaches. That company is profitable in its first year.  Darren McMillan has done some really great work in explaining the ways in which he’s been using mind mapping. Those are only some of the prominent people. Alas, NDAs, company confidentiality policies, modesty, and fear restrain people from saying too much about what is and isn’t working.

In addition, everyone does rapid and exploratory work to some degree, but I’ve never seen process enthusiasts who have actually observed processes closely enough to notice that.  If you want to observe process, you have to observe people.  Most process enthusiasts I’ve seen observe artifacts, rather than real work in action.  The Social Life of Information talks about how quickly we could find blatant errors in our process models if only we took a more diversified anthropological approach.  Don’t get me wrong; I’m at best a dilettante in that stuff myself.  But I think we have to start getting serious about it.

Editor’s note: That’s it for now. Be sure to check back for Part II tomorrow!

Naturally, the first thing we asked him about was the subject of sharing a name with Michael Bolton, the famous singer. See his funny response below the fold.

Anyway, Michael Bolton (the testing expert) was recently featured in a Toronto Star news story for not relinquishing his Twitter handle to Michael Bolton (the singer).

Here’s a hilarious excerpt:

Michael Bolton remembers the day he discovered Michael Bolton.

It was 1985, and he was in a record shop in Sudbury.

“I remember thinking two things,” said the 50-year old software consultant from Toronto. “‘Oh my God, I hope he’s not successful’ and ‘If he is my life is ruined.’”

As Michael Bolton unbuttoned his denim shirt and let his long hair blow in the wind for 90s music videos, the Toronto Bolton dealt with the repercussions. Every time he rented a car, there was a pause, a laugh, a comment.

And now, more than 25 years later, there is another wrinkle in the forced relationship: Twitter. Toronto’s Michael Bolton signed up for Twitter first, and he’s not willing to relinquish the username @michaelbolton, even if it means receiving random messages about his lovely voice or requests for autographs.

Classic. We generally don’t take sides on this blog, but this is one issue where we simply have no choice. Michael Bolton, we’re with you!

As mentioned, here’s what Michael told us back in early 2010:

uTest: You’ve been a thought leader in the testing space for a while now, but people still seem to get you confused with Michael Bolton (the singer) on Twitter. Ever thought about creating a tester alias? Or have you considered asking him to change his name since “he’s the one that sucks.” Assuming you (and our readers) have seen Office Space, I bet this joke never gets old.

MB: Yeah, it never gets old.  Try renting a car with this name.

A couple of things on that. First, Office Space captures very well what it’s like to have my name. Second, it’s not his real name; he changed it already. Way back when, before Office Space, I was working in tech support at Quarterdeck Canada.  American callers would occasionally turn north when there were long phone queues in Santa Monica. On one call, when I introduced myself to the customer, he laughed. “Really? That’s your real name?” “Yes, really,” I said, expecting one of the usual jokes. He said, “You know, it isn’t his real name. I used to be his bass player.”  The singer’s real name is Bolotin, but according to the bass player, there was no hope that radio DJs would ever pronounce “Bolotin” right, so he changed it.

So whose side are you on?

In case you hadn’t noticed, the context-driven school has amassed a global following in just a few short years years, despite some initial confusion on the part of newbies…What is a context-driven tester? What is the basic premise? How is it different from the other prominent “schools” of testing? And what does one have to do to become a member?

James Bach – the founding father of CDT – posted a great overview of the principles this past weekend in an article titled “The Dual Nature Of Context-Driven Testing.” He offers some key distinctions on what the term means, what it doesn’t mean, and how you can grow as a tester by learning more about its principles. Here are a few important excerpts (emphasis mine), beginning with an abridged definition:

The Context-Driven School of software testing is a way of thinking about testing, AND a small but world-wide community of like-minded testers. There are other, larger, schools of testing thought. But CDT represents my paradigm of testing. By paradigm, I mean an organizing worldview, an ontology, a set of fundamental beliefs.

CDT is not a style of testing. It’s not a toolbox of methods. It’s more fundamental than that. You could think of  CDT partly as an ethical position about testing. All methods or styles are available to Context-Driven people, but our selection of methods and reactions to testing situations are conditioned by our ethical position. This position is defined here.

Reading further, it occurred to me that the context-driven school is well-represented on the uTest Blog. To illustrate this alliance, I’ve included links to the names of those “Jedi Knights” who have made contributions on this site. Here’s the excerpt:

Because testing (and any engineering activity) is a solution to a very difficult problem, it must be tailored to the context of the project, and therefore testing is a human activity that requires a great deal of skill to do well. That’s why we must study it seriously. We must practice our craft. Context-driven testers strive to become the Jedi knights of testing.

Aside from the idea, this is also a community. It is a world-wide movement. The most prominent leaders within the CDT school include: Cem Kaner, James Bach, Jon Bach, Michael Bolton, Doug Hoffman, Paul Holland, Matt Heusser, Mike Kelly, Rob Sabourin, Ben Simo, Henrik Andersson, Ajay Balamurugadas, Shrini Kulkarni, Pradeep Soundararajan, Bernie Berger, Selena Delesie, Sajjadul Hakim, Julian Harty, Karen Johnson, Jonathan Kohl, Tobbe Ryber, Meeta Prakash, S. Dhanasekar, and Jerry Weinberg. I may have left a few people out. This list is off the top of my head.

We urge everyone interested in learning more about CDT to read (and re-read) the thoughts of its leading practitioners. As James reminds us, you don’t have to learn a secret handshake or memorize the Greek alphabet to gain entrance:

Context-Driven Testing is an open community in the sense that anyone can speak up and contribute. The way you become leader in our circle is by having ideas, offering them publicly, and engaging in debate about them. Then, as your ideas are tested, you earn your reputation.

Happy testing.

Not that we’re encouraging you to leave the testing profession, but if you absolutely had to, here are a few options for you to consider:

1. Software developer / engineer: Aside from werewolf hunter, this is probably the most obvious career alternative, as great testers will eventually acquire the skills and understanding needed to succeed as a developer. But as a blog reader recently brought to my attention, this works both ways. He said that at his former place of employment, developers aspire to be testers, NOT the other way around. He writes, “ the Tester/QA path is the destination/pinnacle of the career path in SW development. You start out as a Jr. Programmer then… Sr. Programmer then… eventually Architect/System Designer…then…you eventually make it to Testing. Their thinking was that you can’t adequately test until you have proper understanding of the development process. In other words, you are truly considered an expert by the time you get to that level.”

2. Detective: Much like a detective, a tester’s bug-hunting prowess will depend largely on intuition – i.e. knowing the right questions to ask and having a sixth sense for odd irregularities. Testers are already possess the other traits found in successful detectives, including sound logic, analytical skills and patience. The only thing they are missing is an assistant named Watson and a trench coat. Both are available on Craigslist.

3. Journalist: There’s a very thin line between a tester and an investigative reporter. Like their journalistic counterparts, QA professionals must ask tough questions, dive deep into complex issues and report them to the layman in a clear, concise and objective manner. The hours stink and the pay is terrible, but there is some downside to the job however.

4. Actuary: As an actuary, it’s your responsibility to prepare and protect your client from risk in the financial world. Replace “financial” with “software” and you’ve got yourself a tester. Like QA pros, actuaries evaluate and quantify possible outcomes in order to minimize losses associated with uncertain undesirable events (like showstopper bugs). In this profession, you’ll need analytical skills, an understanding of human behavior and of the vagaries of information systems. Does that sound like it’ll be a problem?

5. Demolitionist: Sometimes, software testing really is about “breaking things.” So if testers can thrive while breaking web, desktop and mobile apps, it’s not much of a stretch to see them enjoy wrecking houses, office buildings and stadiums. And like real demolionists, testers must wield the virtual wrecking ball carefully, so as to not damage the surrounding structures.

6. Professor: As evidenced by the thousands of blog posts, forums chats, webinars and other mediums, testers have shown an amazing willingness to pass on what they have learned. A few notable testers who have already served in this role of professor (or course instructor) include James Whittaker, Cem Kaner, James Bach, Michael Bolton, Gerry Weinberg and dozens of others.

7. Architect: The same traits that would enable testers to thrive in demolishing buildings would also help in constructing them – that being knowledge of safety standards, usability and design, functionality, etc. As they say, “If you can build it, you can break it.”

8. Psychologist: Testers are often masters at understanding the mindset of their users. Not only do they know how the typical user will navigate a website; perform certain actions;  respond to error screens, etc. – they know why they are likely to do it. So if you ever become bored with the mind of the everyday software user, perhaps you could try your hand at the mid-life crisis guy or those suffering from Apeirophobia (fear of infinity). For this job, you’re going to need a more comfortable couch.

Have you recently made the jump from testing to another profession, or vice-versa? Please share your experience in the comment section.

“The problem with troubleshooting is that trouble shoots back.” – Author Unknown

“A pinch of probability is worth a pound of perhaps.” – James Thurber

“Everyone knows that debugging is twice as hard as writing a program in the first place.  So if you are as clever as you can be when you write it, how will you ever debug it?” – Brian Kernighan

“If you don’t care about quality, you can meet any other requirement.” – Gerald M. Weinberg

“Testing is an infinite process of comparing the invisible to the ambiguous in order to avoid the unthinkable happening to the anonymous.” - James Bach

“When your car is about to go off a cliff, it’s a weird time to be thinking about gas mileage and drag coefficients; better to take the right control action—look out the window and steer or use the brake until you’re back on course.” – Michael Bolton

“If at first you don’t succeed, try, try again. Then quit. There’s no point in being a damn fool about it.” – W. C. Fields

“I never make stupid mistakes. Only very, very clever ones.” – John Peel

“Treat your password like your toothbrush. Don’t let anybody else use it, and get a new one every six months.” – Clifford Stoll

“It’s more important to have the right people involved than it is to follow the process exactly right.“ – Rex Black

“There are 10 types of people in this world: those who understand binary and those who don’t.” – Author Unknown

“There are two major products that came out of Berkeley: LSD and UNIX. We do not believe this to be a coincidence.” – Jeremy S. Anderson

“Knowing a great deal is not the same as being smart; intelligence is not information alone but also judgment, the manner in which information is collected and used.” – Carl Sagan

“The internet? That thing is still around?” – Homer Simpson

“I love deadlines. I like the whooshing sound they make as they fly by.” – Douglas Adam

“Everything is theoretically impossible, until it is done.” – Robert A. Heinlein

“Have a great weekend everyone.” – Mike Brown

As you probably know, the latest uTest Bug Battle is officially underway. This means that for the next week, testers from around the world will be competing to find bugs in three prominent e-tail sites. But there’s a lot more to the competition than just submitting some random bugs and hoping for the win. In our latest guest post, uTester Anna Danchenko (a former Bug Battle winner herself) offers some advice to testers on how they can best position themselves for Bug Battle success – and of course, some prize money for good measure.

*******

The Bug Battle is a software testing competition open to anyone on the uTest website. The essence of this quarterly competition is simple: You have about a week to find and report defects in the pre-selected websites or applications. The results will be judged on several criteria such as: the “clarity of the bug report”, the “innovativeness of the bug” and the “depth of understanding of the problem.” To put it simply, the more serious the bug found and the better its description, the greater your chances are of winning the battle. As a top tester in Q310 Bug Battle, I’m going to offer some advice on how to find the worst bugs and how to write the best bug descriptions.

I will start with an overview of the available materials that newcomers can use to get ready for the competition. After this, I will move to the main topics: how to find defects and how to write bug reports. Finally, I will write some recommendations on completing the final stage in the competition: feedback survey.

Available Materials
This section is a collection of the important links to be explored by uTest newcomers. I have divided it into 3 parts: “Registration”, “Bug Battle” and “Bug reporting in uTest”. To participate in the Bug Battle you need to be registered in uTest. In addition, I highly recommend that you become a member of uTest forum. This is an invaluable resource for learning about past Bug Battles, uTest and testing. In the “Bug Battle” section there are links to pages with the competition rules and advice from other participants on how to win. The last section on bug reporting contains the most important resources with uTest recommendations. I will comment on how to get the most out of these resources because a good bug report is one of the keys to getting the Best Bug award.

Registration
Join uTest
Join uTest forum

Bug Battle
Help section: “What’s a Bug Battle and how does it work?”
Forum thread “Is This Your First Bug Battle? Click Here To Get Started!”
Forum thread “How to win the Bug Battle”
Blog post “How I Won the uTest Bug Battle (and how you can too!)” by Santhosh Tuppad

Bug Reporting in uTest
Help section “How do I report a new bug?”
Help section  “Bug Title (Subject Line) Standardization”
Help section “How do I classify bug type (GUI, Functional, Technical)?”
Help section “How do I classify bug severity (Show stopper, High, Medium, Low)?”
Help section “How do I document and prove that a bug is real?”
Crash Course “Bug Reporting 101”
Crash Course “Bug Reporting 102”
Forum thread “The secrets of a good bug report”

At first glance there seems to be a lot of information on the bug reporting and it’s easy to get lost in the classifications and the guidelines. Fortunately, there is a simple way to get a clear understanding: repeated practice. Write down all the fields from the screen shots of the uTest bug tracker (see “How do I report a new bug?”) and fill in the fields with the real defect descriptions.

Some experienced testers might wonder why they need to practice with bug reports? The main reason is to get used to the uTest format which might be different from your reporting conventions. For example, there are less fields in the bug tracker than I used to have; report title can’t be more than 100 characters and there are only 3 types of defects. You might find even more surprises when writing a bug report in the uTest format. To uncover all of the differences, and have time to adapt your style to the expectations, you need to practice writing bug reports according to the uTest guidelines.

Bug Hunting
In this section I will do 2 things; firstly, share links to the well known “must-read” materials, and secondly, write about my own way of testing that has been highly influenced by these well known sources.

Must Read

•    Michael Hunter’s checklist “You Are Not Done Yet”;
•    Materials from “Rapid Software Testing” course by James Bach and Michael Bolton:  Slides and Appendices;
•    Materials of “Black Box Software Testing” course by Cem Kaner and James Bach;
•    Book “How to Break Software: A Practical Guide to Testing” by James A. Whittaker.

My Approach to Testing
I want to repeat that almost everything I will say later in this section is not new and has already been described in the materials in the “Must Read” section. In describing my approach, I will show how I apply some of these methods. In a moment you will see that the whole process is all about asking questions and looking for answers.

Start testing by defining your context and your mission. This is the “light” that will help you with finding the right direction later on in the testing. What is my mission in the Bug Battle? My mission is to find serious bugs or at least interesting bugs, so I’m not looking for simple broken links. What is the context? In general, the context is some alive and highly-used website or application without any requirements or experts available: only the help section and my own common sense. How to start testing? Start with the proper attitude: all software contains bugs. Do not be fooled by shiny welcoming screens. All software contains bugs and some of them are waiting just for you.

Where to start testing? With the proper attitude you can start from any place and this is time to remind yourself about the mission and the context. Do you expect to find serious bugs in a core feature used by thousands on a daily basis? If you were a test manager of an in-house test team for this website what would you choose as the most important features to test? Do you (now as yourself and not as a test manager) want to re-test these features? What might you (now as test manager and not yourself) forget or exclude from your plan? Are there more chances of finding issues if you look into new features? Are you sure that you know what features are available? Are you sure you know how the user will use the feature? How do you know that the result is correct? What are the typical data used by majority of users? Do you want to re-test with typical data? What other specific questions are important to ask? Do you need help with building other questions by yourself? If your answer is yes, then read the materials listed in the section “Must Read”. If your answer is no, then find the bug that is waiting for you and we’ll move to the “Bug Reporting” section.

Bug Reporting
Let’s say you’ve found a defect and you want to describe it. This simple reporting task becomes a challenge if you need to follow an unfamiliar format or if you have no experience with bug reporting. If you belong to the first group then consult with the resources from the section “Bug Reporting in uTest”. For the second group I would suggest reading “Painless Bug Tracking” by Joel Spolsky and only then moving on to the section “Bug Reporting in uTest”.

You might ask why I list all of these resources and insist on reading them again and again? The answer is because it’s how I started with bug reporting on uTest. Although I have about 10 years experience with describing found issues, I’ve studied each recommended page carefully to know the uTest rules and follow them. And to be honest, I was amazed by the number of Bug Battle participants who demonstrated little knowledge of uTest recommendations on the title format or the report content. It’s as if you found a “diamond” bug and then immersed it in the “mud” of a sloppy bug report. Great bugs need great descriptions, so read and apply the uTest guidelines, and your “diamond” bugs can be valued by everybody.

At this moment in time, I am assuming that you have practiced with bug reporting in the uTest format. My other assumption is that you have some questions and doubts about it. How do I know? Because I had questions and doubts too. Fortunately, all of my questions were answered and I will share some of those answers with you now.

My first question was: where is the “summary” field? Where I can put the complete bug description before writing 15 long steps to reproduce? Will any reader stay with me and read these steps without getting a general idea of the problem? What to do if I cannot describe a problem using only 100 characters of the bug title? The solution is to look again at the screen shots on the page “How do I report a new bug?”. In particular, find the picture “Action Details” and look at the first field “Action Performed” with an example of the content. This example fully answers my first question: if you do not have a separate field to write a summary then use the existing field “Action Performed” and split it into 2 parts: the first part “Overview” will contain the summary text and the second part “Steps to Reproduce” will contain a detailed description on how to reproduce an issue.

The second question concerns the steps to reproduce: How to write a single step? How detailed should it be? Should I write “click on button Save to save a note” or just “save a note”? Are there any examples of the “golden” bug description? When I asked these questions myself I didn’t find any guidelines from uTest and decided to keep using my own pattern.

Here is the pattern for a single step:

place + action + data + GUI + data values + result

Explanation:

1. Place – the place where the action should be performed. For example: On the page “Resume examples”;
2. Action + data – the action to perform and the data for this action. For example: sort the list of resumes by the date posted. Another example: log in as an administrator user;
3. GUI + data values – how to perform the action using GUI elements and the exact data value(s) used for the action. For example: click on the header “Date” in the table “Resumes”. Another example: in the field “Login” enter  “administrator”, in the field “Password” enter “123″; click on the button “Sign in”;
4. Result – the result of the action. Example: As a result, page “Resume examples” is refreshed and list rows in the table “Resumes” are sorted by date. Another example: As a result, the tab “Administration” is shown at the top of the page.

And now, an example of the complete step: “On the page “Resume examples” sort the list of resumes by the date posted: click on the header “Date” in the table “Resumes”. As a result, the page is refreshed and the resumes list in the table “Resumes” are sorted by date.”

Using this structure it’s easy to describe: the place, the action, the data values, the GUI elements and the expected result. This level of detail provides the reader with both a concept and a concrete way of performing the step. For a user who knows an application it will be enough to read the concept part. For a user who needs details you have precise names of all GUI elements along with the directions on how to use them. Both users can read the result description, so they know when the step is finished and they can proceed to the next step.

The last question I asked myself was about the quality of my bug reports: Are they good enough? How can I check that they are as good as they appear to me now? Fortunately, I found the solution in the middle of bug battle: I re-read my reports 2-3 days later and this simple exercise helped me to notice what could be improved. The secret is to feel like a “first-time” reader and not an author.

As a reader I have only the text of the bug report. I have no “vivid demo” in my head of how an application crashed 10 minutes ago, I’m just starting to build this “demo” and familiarize myself with the found problem. I’m not in a hurry to warn the world about the crash. I’m interested in small clear steps on how to “arrive” at the crash. And this is the moment when you start to notice some omissions in steps, unclear directions and other surprises from your own bug report.

So, invest your time in re-reading and you will see what can be improved. I know that it’s not very natural for testers to come back after 2-3 days and edit defect descriptions. On the other hand, bug battle is also something that doesn’t happen on a daily basis. The only outcome of the competition is your bug reports and one of the criteria they will be judged on is the “clarity of the bug report”. Remember about this and find some time to check the clarity by yourself. In fact, I was re-reading and editing each of my 12 reports about 4-5 times and I think that such an approach helps with getting the “top tester” award.

Feedback Writing

According to the Bug Battle rules: “Once the competition has ended, all contestants who submitted bugs will be sent a link to a feedback survey. …  Submissions for this portion are optional, however we strongly encourage those interested in Top Tester to complete the survey.” The feedback survey looks like a set of multiple-choice questions with predefined answers except in the final part. There you have to write the most important comments about each of the tested websites as if it would be read by the website development team.

My questions when I started to write were: What to write? How many sentences? Are there any examples? Well, now I know that there are some examples in the detailed report for each Bug Battle. Unfortunately, I can’t find any part of my feedback in that detailed report, so I cannot insert a link and finish this section. Instead, I will list the key points of my feedback:

1. Write the comments as if they are for a friend who developed a website and asked you for honest feedback. Obviously, the number of “waffle” pages you can produce is not important. What is important is to write honestly and give your friend a chance to improve the website. It’s also important to compliment good features and design decisions, so that they remain on the website.
2. Use a spellchecker.
3. It’s OK to write only 3-5 sentences.
4. The following questions might help you to generate some ideas for feedback:

• Do you want to stay on the website or do you prefer other similar ones? What are the reasons?
• Do you like the general site idea? Why? (if not – then it makes little sense to write about small improvements and it’s time to stop)
• What in the website makes the difference so that you like/hate it?
• Are you missing something? What? Why do you need this “something”?
• What features/design decisions do you love/hate? Why?
• Are you using the website in your usual (not battle) life? If the answer is yes, then how often and what are your typical use cases?
• Do you need any changes in the GUI, features, structure? What are these changes and why do you need them?
• Do you have any not-reported small issues? List them here.
• Do you want to say “thanks” to some particular team members like “technical writes”, “designers”, “programmers”, “product managers”, “testers”, “translators”, others? For what exactly do you want to thank them?

Conclusion

In this article, I have given you some advice on how to win the Bug Battle. I have started with the section for newcomers to list the “quick start” pages from the uTest website. Than I have written about the resources that helped me to become a better tester and tried to demo my approach to testing. After this, I have shared my initial questions on bug reporting along with the answers which I found later. Finally, I have listed the key points for writing a feedback survey. I have tried to describe everything that helped me to become a top tester in one of the bug battles, so you can read and benefit from my “winning secrets”. I hope that it will help you to win the Bug Battle and wish you good luck in the next competition. The most important secret to remember is this: there is always one bug waiting just for you.

About the Author:

“My IT career began 11 years ago in Ukraine. I’ve started by combining developing and testing. Luckily, the customers were very close, so since that time I know how does it feel if you did a great 2-hours job that saved them a week; or if you forgot to enable “that small button”. Later on, I moved to “pure” testing (it does not mean that I didn’t program). Luckily, developers were very close, so I know how does it feel if you submit a bug without steps to reproduce, or how 5-minutes talk with developer can help you to find 10+ serious issues. Afterward, I moved to test management. Luckily, testers were very close, so I know how does it feel if 1 misprint in your test platform matrix throws away 3 days of test team’s work; or if you entrust the first test project to your recent “test trainee” who learned testing from you. Three years ago I’ve moved to The Netherlands to work as a senior tester. I’m making mistakes from time to time, so do my colleagues. Luckily, I know how to deal with these mistakes, so we can be proud with what we achieved when it will be time to move to something new.”

In part II of our Testing the Limits interview with Ben Simo, we’ll discuss whether you should trust automated testing tools; the proliferation of testers on Twitter; the true meaning of “QA”; how testing evolves differently in each company; the long lost Bach brothers and much more. You can catch up on the conversation by reading part I. We’ll wrap things up tomorrow with part III.

********

uTest: Jon Bach mentioned that changing the meaning of “QA” to Quality Assistance would help outsiders (engineers, executives, et al) better understand the role of this discipline.  Agree or disagree?

Simo: I believe I first heard  “Quality Assistance”  from Cem Kaner.  I agree with Jon. When testers bear the title Quality Assurance, it often implies that they actually assure the quality of other people’s work. Testers are in a position to help assist quality; not assure it. Let’s not assist the setting of unrealistic expectations with inappropriate titles.

uTest: While we’re on the subject, are you anyway related to James and Jon Bach? The resemblance is uncanny.
Simo: I don’t think so. I’m available for adoption if the Bach family is interested.

uTest: You’ve said that you frequently use automated tools, but that you don’t trust them entirely (back to that whole defensive pessimist thing again). What advice do you have for testers and managers wanting to strike a healthy balance? And what’s currently in your arsenal of automated tools?

Simo: My mistrust in tools is based on the fact that tools can’t think for me. Automated checking can only process whatever decision rules someone thought to program when the checks were created. Automation will consistently do what it is programmed to do and consistently not do what it is not explicitly programmed to do. I find test automation to be useful. In fact, there are some things I’d not want to even try to do manually. I do, however, distrust the green bar. When automated checking passes, I ask myself what the automation does not tell me. I also try to keep aware that people who don’t understand what the automation does are likely to assume that it does more than it does.

Tools are much more than test automation. Tools are essential for testing. I don’t want to test without tools. I have some old programming books that promote testing in which a programmer manually executes code, step-by-step, with pencil and paper in order verify that the code works as expected. This is manual testing. This is a testing practice that came from a time when computer time was rare and cost more than people. We’d now laugh at someone proposing testing in this manner.

Today, whether we call it “manual” or “automated”, tools and automation are part of coding and testing software.
Programmers use fancy integrated development environments that do a great deal of the tedious work of managing and checking code. Programmers have unit testing tools that allow them to write tests as they write the code. We use tools to track and version source code. We have continuous integration tools that automatically run pre-defined tests and report results when programmers save code into shared code repositories. Today, programmers rely on interactive tools to do work that used to be done manually. These tools support people coding software rather than trying to replace them with batch processes.

Many of the tools built for testers seem to still be stuck in the world of batch processing. Rather than assist testers by helping with tedious tasks, they try to replace test execution. Some of this comes from the design-all-tests-up-front-in-procedurally-scripted-detail thinking that made sense when computer time cost more than people.

I worked as a tester for nine years before I encountered a record and playback type test automation tool. In those nine years, tools played an essential role in my testing. We built all our tools in-house. We wrote macros and scripts to do tedious data processing. We wrote code to verify data formats. We created test interfaces for databases. We created test management systems. We depended on tools but did not have a single test case that was fully automated. This automation made testers both more efficient and effective.

Rather than look at testing as something to be either manual or automated, I encourage people to look at individual tasks that are part of testing and try to identify ways that automation can help testers evaluate software. Rather than limit tools to automation of test execution, I look for ways that automation can assist testers – to turn them into powerful cyborgs.

These tools include automated test execution tools, data setup and teardown scripts, communication tools, test management tools, test logging and reporting tools, test data manipulation tools, and more. Along with test execution automation tools (take your pick), my most-used testing tools are Excel, Picasa (for screenshots), a screen recorder, and the GNU Unix utilities (also available for Windows).

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.

Simo: I’ve not noticed great distinctions in testing practices based on industry.

What I have noticed is that testing practices seem to evolve within individual companies and test groups. Rather than learn from what others have done, it often appears that each tester, each test organization, and each company starts in some stone age and evolves on its own – making the same mistakes that others did long before.  Lessons learned don’t seem to be shared much across companies.

I’ve also noticed that “quality assurance” groups in large commercial businesses, regardless of industry, tend to be dominated by factory school thinking. Instead of viewing testing as cognitively complex work that requires critical thinking, good communication, and continual learning: testing is thought to be predictable repeatable validation work that can be done by automation or cheap labor.  These companies tend to view quality and process as things to be scripted, controlled, and quantitatively measured. In doing so, I believe these companies dehumanize their people and their customers.  These companies tend to have what Jerry Weinberg called “overstructured management” in a paper written nearly 30 years ago; management which attempts to manage people like code: with sequential work models, binary either-or choices, and mechanical repetition. These things may be good for computers, but aren’t great for people.

While many companies are still recursively calling on the mistakes decades past, others are recognizing that people aren’t to be controlled like machines.  While they may not be familiar with either document, these companies exhibit the values expressed in the Agile Manifesto and practice the principles of the Context-Driven School. These companies value people over systems.

uTest: Who should testers be following on Twitter to stay current on the latest industry trends (I mean, besides you and us, of course)?

Simo: I’m not as interested in trends as much as I am in experience reports, and new ideas and challenges. Some of my favorites who are active on Twitter are Pradeep Soundararajan (@TesterTested), Shrini Kulkarni (@shrinik), Matt Heusser (@mheusser), Lanette Creamer (@lanettecream), Elisabeth Hendrickson (@TestObsessed), Michael Bolton (@MichaelBolton), Jon Bach (@jbtestpilot), and James Bach (@JamesMarcusBach). Beyond that, I suggest people see who these people, and I, follow and interact with on Twitter. Use Twitter’s search feature to find people tweeting about things that interest you. Don’t limit yourself to only testers or those people you like. We can learn a great deal from those outside our field or with whom we disagree.

Editor’s note: Read part III of the Ben Sim Testing the Limits trilogy.

“Nonsense!” you say. “There’s plenty of software testers to go around.” Not for long, says SiliconIndia, who posits that a shortage of skilled software testers is only a matter of time. Citing various facts, figures and estimates from a recent Gartner study, the author examines the reasons behind this coming tester drought.

Pradeep Chennavajhula explains:

This shortage is now a major concern for the IT service organizations, considering that the academia is not geared up to support the program, and many of the training organizations are not geared up to meet the demand of the industry. In this scenario, the question still remains as to how is the industry planning to tackle the shortage of software testers?

Good question. Of course, we’ve dealt with these issues many times before on The uTest Blog. Here are a few posts with some answers:

Wishful Thinking On Software Testing, by Santhosh Tuppad
In this post, Santhosh explains why he thinks the current academic environment short-changes testers and their profession. He writes:

“Why are students not taught about thinking (example: lateral thinking) as a skill in most schools and colleges?” In the future, I wish to see schools dedicated only for software testing. We will see a great amount of value if an individual is taught about software testing from a much earlier age than college. That kind of expertise would be great for our craft.

Testing the Limits with James Bach, Part I
When we interviewed James Bach a few months back, we asked him how he would improve testing education if he were an all-powerful king for a year. Here’s what he said:

A spirit of exploration, experimentation, and debate would spread around the industry. It will seem to come from everywhere at once.

Weekend Testers would become Weekday Testers. TMap textbooks would be beaten into plowshares… and then recycled. Test plan templates and TPS reports would blow forgotten through streets lined with cheering crowds playing tester games designed to hone practical reasoning skill. By the thousands! FOR THE WIN!!

As far as university goes, I’ve already been doing my part. I helped found and run the Workshops on Training Software Testers, which brings university professors together to examine how to teach testing better.

I served on an advisory board for the Rochester Institute of Technology when they were trying to set up their degree program in software engineering, too.

But if I were king (not the modern Swedish kind but the old-school Caesar kind) I would make school a lot harder (much easier to expel a bad student) and instead of paying tuition, students would be paid.

Also, there would be no classes, as such, just constant projects and training. In other words, it would be almost exactly like Silicon Valley in the eighties, except with better corporate libraries.

Testing the Limits with Jon Bach, Part II
Jon Bach (James’ brother) chimed in on the subject of tester certifications. We questioned him on whether they were in fact worthwhile, to which he responded:

The only thing worthwhile about them is the debate they provoke. Window dressing is an apt metaphor because it’s only meant to enhance a window’s *appearance*. When there’s a flood or a storm or some other strong test of the window, the dressing often gets destroyed. Outside of the flood, people may prefer the look of the dressing; I just want to be a stronger window. Passing multiple choice tests about so-called “best practices” don’t do that for me.

Testing the Limits with Michael Bolton, Part I
Michael Bolton offered his views on where all the skilled testers are likely to come from, if such a shortage begins:

Scandinavia—Sweden in particular—and New Zealand seem to be percolating more excellent testing than other places.  Meanwhile, I observe that many Western firms—mostly the Americans—are making life difficult for testers in India and other developing countries. These firms didn’t know much about testing to begin with. They viewed it as a rote, clerical activity, piecework, checking work, commodity work that delivered little value. They knew how to do checking, sort of, very slowly and very expensively. But they didn’t know how to do testing, or how to increase its value, so they focused on cost and outsourced it.

So will we see a shortage of testers like some predict? Or will the industry take the advice of our esteemed bloggers?