Testing the Limits With Michael Bolton – Part II

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?

Read more…

Testing the Limits With Michael Bolton – Part I

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?

Read more…

Life After Steve Jobs: Has Apple Lost its Core?

I found myself deliberating on something unexpectedly the other night.  I was thinking about buying the iPad–which I’ve wanted for a long time–and it occurred to me: What’s the future of Apple?

Previously, the issue was whether I should I invest in iOS and start the conversion over from a lifetime on Windows.  After all, my dad was a 30-year IBM vet, which put food on the table and paid my tuition.  I grew up seeing mammoth mainframes, punchcards…glowing green DOS.  No Apples of any color in our Big Blue household.

But on this occasion, it wasn’t a question of brand loyalty. It was the obvious: the loss of Steve Jobs.

I still find myself processing his passing both emotionally and practically. I remember how the AP alert popped up on my phone and it literally felt like someone had punched me in the stomach.  I admired him for living authentically, taking billion dollar gambles on ideas, picking himself up after billion dollar failures, and holding steadfast (stubborn?) to his vision.

I’m convinced his near-religious zeal over every minutiae of product design stemmed from the same social ethic that led to Apple’s creation:  to make computers so easy and user-friendly that everyone could benefit from computing’s powerful potential.  Not just the technical, highly-educated and elite. Computers for Everyman.

Attention to detail.  Risk-taking. Singular focus. These are among the core values of the Apple brand. As I considered buying the iPad, I wondered:  Are these values sufficiently infused in Tim Cook and the company DNA to continue on without Steve?  Or will Apple employees slowly lose direction like followers of the North Star left without guide over too many cloudy nights?
Read more…

What is the Best Easter Egg of All-Time?

I was reading a story about some of the hilarious Easter eggs in Apple’s Siri and got to wondering where they ranked on the all-time list. For those  who aren’t familiar with the term, an Easter egg is defined (per Wikipedia) as a ” intentional hidden message, in-joke or feature in a work such as a computer program, web page, video game, movie, book or crossword.”

So what’s the best Easter egg of all-time? Since some of you may not have much of a reference point, I’m including a top ten list compiled by Focus.com. Take a look:

  1. Photoshop CS2: Merlin Li … : Hold down both the Alt key and the left mouse button, then move your mouse over Palate Options in the Layers window. Let go of the mouse, and Merlin appears.
  2. Gnome: Wanda a Fish: Go to the Run dialog in Gnome and type “free the fish.” Click the Run button and a fish called Wanda should pop up and wander around the desktop.
  3. Skype: A Few Hidden Emoticons in Skype: Enter a chat session and type words like “drunk” and “ninja” with the brackets to view amusing emoticons.
  4. uTorrent: Tetris in uTorrent: Select About in the Help menu and press “T” on the keyboard.
  5. Microsoft Paint: Hidden Drawing Tool Options: Use the Ctrl key to stamp, scuff and use brush pressure, as well as to draw straight or diagonal lines with the pencil.
  6. Bloodshed Dev-C++: Fish: Click About Dev-C++ in the Help menu, then click and drag the Really Flash Dev-C++ logo onto the authors button. A fish should appear, and if you click it, it will change direction.
  7. OpenOffice.org: Star Wars Game: Create a new spreadsheet in the OpenOffice.org Calc. Type “=game()” intoa cell and validate it by pressing Enter. The cell will display, “Say what?” to which your typing finger will reply “=GAME(“StarWars”).” A new window will open with a little game called Star Wars.
  8. Spybot — Search and Destroy: Game Hidden: Click the little icon that appears in every window you open by selecting an option on the left-hand panel. You will get access to a game where you have to fill in as may squares as possible.
  9. Cool Edit Pro: Game in Cool Edit Pro 2.1: Go to Help, then click About CoolEdit Pro. Click over the two silver balls to have some fun.
  10. Winamp: Spinning Fish: Bring up the Preferences box and go to Plug-ins > Input. Click the Nullsoft Vorbis Decoder, then click About. Click the fish to make it spin.

Let us know your favorite in the comment section below.

Oh, and in case you were wondering, we’ve embedded an Easter Egg of our own in the uTest iOS app. To my knowledge, it has yet to be discovered. If you’re up for the challenge, you should give it a shake – I mean shot.

W.M.D. Powered C.A.R.S. Coming to a Game System Near You

First off the title of this post will require a bit of explanation. W.M.D. in this context stands for “World of Mass Development,” which is a new platform for games creation from the award-winning games developer Slightly Mad Studios. Not only does this new platform crowdsource ideas and designs for games among the developer/designer communities, but they also expand the crowdsourced community to include investors. W.M.D.‘s first title will be a racing game called “C.A.R.S.” which stands for “Community Assisted Racing Simulation”.

Members of the public may pay a subscription fee to the community and help develop the game, and even possibly get a return on their investment once the game ships. Those who participate will be able to play the game from its pre-alpha builds up to its final release version. Slightly Mad plans to take 30% of the profits, with the other 70% being divided among the community investors.

Traditional development puts developers at the mercy of publishers,” Slightly Mad said. “The development process offered by WMD shifts the focus back to creating great games that your target audience wants to play, whilst still offering the chance to get proper funding for development and testing.”

Read more…

v4.3 – Next Generation Tester Profile

Check out uTest 4.3

Click the thumbnails below to see a larger screenshot.

Choose Your Testing Types

Describe Your Expertise

Ratings by Testing Type

Just two months after announcing an expanded suite of testing services, uTest has now launched its next generation tester profile and ratings system (Platform v4.3). These changes come at an opportune time – customers’ testing requirements are on the rise, followed by an increasing need to optimize project invitations for our global community of testers.

First, the new Profile includes the ability to control which types of projects a tester wishes to participate in. For example, if I’m only interested in security testing, I would simply fill out that specific portion of my profile.

On the other hand, you may be interested in usability testing – specifically designing surveys for end-users to complete and analyzing the results. The new profile allows you to drill down to specific flavors of testing (e.g. designing usability surveys); not just at a high level (e.g. functional, security, load, localization, and usability testing). Lastly, you can control the amount of incoming project invitations by noting your general availability for uTest projects each week.

Moving on to the rating system, testers now have the ability to earn a badge across the five major testing types. For example, instead of being a Gold uTester, one may now be a Gold uTester in security testing and a Bronze uTester in load testing. Aside from these changes, the new Rating System also places heavier weight on the quality aspect of a tester’s participation (quality over quantity). Therefore, testers who continue to submit very valuable reports will likely witness an increase in their rating. And as usual, ratings are calculated dynamically and adjusted daily based on activity across all testing projects spanning the entire community.

If you’re a uTest customer, most of these changes are under the hood – although you will directly benefit from our enhanced rating system. But if you’re a uTester, you will need to update your profile to enjoy the benefits of fewer emails hitting your inbox and more projects that are relevant to you.

uTest Fall Tour 2011

While everyone is preparing to take it easy and “fall back” this November, uTest is picking up more speed and springing forward! We hope you can meet up with us at one of these upcoming events or at least join us for a quick conversation on Twitter – be sure to stay connected by following the hash tags below.

Oct 11-13 ANAHEIM:  CTIA Enterprise & Apps – we’re here right now! #CTIAEnA

Oct 10-12 SANTA CLARA: Localization World – also attending now, hash tag streaming on their site! #LWSV

Oct 18-20 SEATTLE: SIG Global Leadership Summit – uTest CEO Doron Reuveni joins Google Engineering Director James Whittaker and President of Massolution Carl Esposti for “An Introduction to Crowdsourcing” on Wed,  10/19 @ 3:40pm.

Oct 24-27 DALLAS: STPCon, Software Test Professionals Conf – uTest CMO Matt Johnston keynotes the event on Tue, 10/25 presenting “In-The-Wild Testing: Your Survival May Depend On It”. #STPCon

Oct 26-27 MOUNTAIN VIEW: GTAC, Google’s Test Automation Conference #gtac2011

Oct 28-29 LONG BEACH: SoTeC, Southland Technology Conf – uTest CTO Fumi Matsumoto presents the “10 Tech Trends Altering The Testing Landscape” on 10/29 @ 9:45am.  #SoTecConf11

Nov 1-2 SAN FRANCISCO: CrowdConf – uTest’s Matt Johnston joins Amazon, LiveOps, Trada and GigaOm on Wed, 11/2 @ 2:10pm for a debate panel. #crowdconf

Nov 15-17 SANTA CLARA: E2.0, Enterprise 2.0 – Matt Johnston presents “Is this the Year Crowdsourcing Goes Mainstream?” on Wed, 11/16 @2:30pm. #e2conf

Nov 21-24 MANCHESTER (UK): EuroSTAR – uTest VP of Project Delivery John Montgomery presents the “What The Top 10 Most Disruptive Technology Trends Mean For QA And Testing” on Thurs, 11/24 @ 11:00am in the Apps & Mobile track. #esconfs

If you’d like to meet up, shoot us a quick email or tweet – see you there!

RIP Steve Jobs

Last night, the greatest entrepreneur, inventor and technical visionary of our age passed away. You will be missed Steve Jobs. We’ll be commemorating Steve – and the impact he made on all of our lives – by posting thoughts from the uTest crew throughout the rest of the day/week, but I wanted to first post a very inspiring clip from his 2005 Stanford Commencement Address. Please feel free to add your thoughts in the comments.

The only way to do great work, is to love the work that you do.”

Thoughts from the crew here at uTest (if you have a quote, story or link about Jobs that you’d like to share, please drop us a comment below):

@jennymoebius –”Today just isn’t the same. Although I personally didn’t know Steve Jobs, I strongly felt the blow of not having him around anymore – to invent, to create, to amaze and to connect us all in ways no one had ever dreamed before. Steve turned every one of us from passive users of technology into true creators – and those that give us the tools to further ourselves and the human race are remembered for all time.” #thankyouSteve

@spchampion“My first experience using a Mac was when I was in college. I had a job with the university doing technical support, and they assigned me a brand new Blueberry iBook as my work computer. It was such a simple and elegant little laptop, and I was amazed at its build quality and design. But something was missing – the iBook had a handle on the back for carrying it places, but I was still tied to the wall by an Ethernet cable.

Apple had thought of this, and inside that little iBook they had included an incredibly cutting-edge piece of hardware that would let you use Ethernet wirelessly. This was new and risky – no other computer manufacturer was doing anything similar. In fact, this technology was so innovative that only one company made the base-station needed to create a wireless network: Apple.

When Apple launched the first generation Airport (itself a very elegant piece of hardware), I bought one immediately and set it up inside my dorm room. Then I detached my iBook from the wall, took it outside, and sat down on the grass in a nearby courtyard. I checked my email. I surfed the web. I saw the future.

Eleven years later, I came home from work one night, picked up my iPad, and sat down on my couch. I asked the iPad to load CNN, and the wireless network in my house (a second-generation Airport) happily dispatched the request and delivered the result. The news stunned me: Steve Jobs, the man responsible for all this innovation at my fingertips, had passed away.

Before Steve Jobs’ return, Apple was a company that made respectable but odd hardware. They used a proprietary keyboard connector called Apple Desktop Bus. They used SCSI for their hard drives. Their networking was done with AppleTalk. None of these technologies were particularly bad, but none of them changed the world either. What Steve Jobs did for Apple was to force the company to push the boundaries of technology and hardware in a way that would change the world for their customers. The original iBook was a brilliant example of this vision. It combined innovative hardware (an 802.11b radio) with a wildly iconic design, included high quality components, used emerging standards for connectivity (USB), and sold at a price that every college student could love. It was a computer you could use anywhere and connect to anything. It changed my world.

Thank you, Steve. I hope that we can keep pushing ourselves and our civilization as well as you did. ”

@edlavalette “Steve Jobs had a unique ability to envision solutions to problems before us mortal users knew we had these problems.”

@matjohnston –  “They could (and will) write libraries on Steve Jobs’ career — the break-through products he envisioned; the entirely new categories he created; saving Apple from the brink; saving the music industry; reinventing a big piece of the movie-making business. But what stands out to me is Jobs’ utter disrespect and disdain for the status quo. This man simply could not play by the rules that govern most execs and brands in modern times:

  • Manage expectations… tamp down what customers, competitors and media expect from you. Jobs and Apple continually raised expectations to frothy heights — and then met or even beat them.
  • Stick to what you’re good at… brands and execs are taught to focus on their core competencies and not to stray from it.  Jobs and Apple were never constrained by the preconceived notions of “experts” about industry lines, price point or market segment. And we have the iPod, iPhone, iTunes and iPad because of it.
  • Give the market what they want… we look endlessly at market research, customer satisfaction surveys, web analytics hoping to uncover what the market wants. But Jobs connected with the market on a deeper level and knew where tastes were heading before anyone else — competitors, media, or even consumers themselves.
  • Play nice… in this hyper-connected world, brands and leaders are afraid to make a mistake or ruffle someone’s feathers, lest a customer, employee, or blogger take to Twitter and lob a critique at them. Jobs made an art form of autocratic-yet-engaging leadership. He proved that you don’t have to stoop to benign platitudes and empty talk to reach an audience — that people can and will rise to a challenge.
  • Be bold… Many execs and brands play it safe these days (too often, this includes uTest). But Jobs put it all out there — in his vision for technology & design; in his management style; and in the tenor of his yearly Stevenote addresses at Mac World.

Thanks Steve. Thanks for showing us that we don’t have to choose between form and function. For inspiring a new generation of tech leaders who have a similar single-mindedness and audacity of vision.  Here’s hoping we all remember to #ThinkDifferent

@Mahhcc – “My first experience with an Apple product was in the 1st grade, and since then I’ve owned 2 iPhones and numerous Mac computers, all of which I’ve loved. Although I didn’t know him personally, I will always admire Steve for creating products that people love and for turning Apple into the company that everyone races to catch up to.”

@jamesc_utest– “It’s an unfortunate thing to lose a mind like Steve Jobs, especially to such a heartbreaking thing like cancer. Someone with so much more he could’ve accomplished in technology with more time. We could’ve been sitting here 10 years from now, talking about how Steve jobs innovated the first Apple Car (iCar), for all we know. I was always a fan of Apple products, but never really understood my fanboy obsession until after college when in my first job I was given a macbook for every day use.

The ease of being able to pick up a product and just use it is something that wasn’t just Steve’s mantra, it was true in every sense. With Steve gone, I think one of the most lasting quotes I want to remember is when he said “Do you want to spend the rest of your life selling sugared water or do you want a chance to change the world?”

@roysolomon — “For me Steve Jobs represents what entrepreneurship is all about, a lot of ups and downs, but if you stick to your truth and you are really gifted then you can change the world. In many ways we are like those in the 1400s who had the privilege of living in the age of Leonardo Da Vinci.”

Testing the Limits With James Bach – Part II

In part II of our latest Testing the Limits interview with James Bach, we discuss what it would take to get him back on the client side of testing; free testing tools that he’s currently using; required reading for new testers; his upcoming speaking/book tour, sniper rifling in Middle Earth and more. Enjoy!

If you missed part I, you can find it here.

uTest: Your brother recently made the leap to the client side at eBay….will we see James Bach cross back over as well?

JB: Well, maybe a super-villain out there buys out my company and hires me full time to be chief tester for their front corporation. I would wonder at first why I was being paid three million dollars a year to test a variation of Angry Birds, but the money would blunt my natural inquisitiveness (I have my wife’s medical bills to pay, after all).

Only after a British secret agent drops in (literally) at my office to confront me with the horrible truth (that the program I was testing was actually a doomsday device) would I and Cortana (an AI construct rendered as a perky young female that switched sides after spontaneously evolving a sense of ethics) manage to skillfully mis-report critical bugs prior to sign-off. This would lead to the destruction of the doomsday machine seconds after our daring escape through the test data exhaust port.

But I doubt that will happen.

Basically, it would take an unreasonable amount of money to make me give up my independence.

uTest: You wrote a great blog post recently on the subject of tool vendors – specifically, how they can avoid your wrath. We’ve also heard you recommend free tools in the past (“because they can be freely abandoned”). What tools (either paid or free) have you discovered recently and how have hey helped your testing efforts?

JB: I’ve been playing with “R”. It’s a free statistical analysis system.

There are several books on it. I love tools that help me work with complicated data.

The tool that has helped me most recently is my Canon solid state video recorder combined with my micro tripod. I think I will never do professional testing again without a camera rolling. It’s so helpful to be able to roll back the film and watch what I just did in order to reproduce a difficult problem.

uTest: You’ve been following the testing of medical devices rather closely, recently highlighting that the FDA had come to recognize the value of exploratory testing. Are there other particular industries that need to make this same realization? If so, which ones?

JB: Banking, insurance, and aerospace come to mind. I’m working with a major world bank as well as a major insurance company right now, so that feels good. They are both “standardizing” on Rapid Testing. Which means that thinking for one’s self is becoming their standard.

uTest: We know you’re not much of a proponent of testing textbooks, but we know you’re a big fan of books and literature in general. Do you have a “required reading” list for new testers? If so, what are some of titles we could expect to find on it?

Read more…

Testing the Limits With James Bach – Part I

Back for another session on the Testing the Limits hot seat is James Bach – one of our most popular guests and one of the most widely recognized figures in testing today. A prolific author, speaker, coach and consultant, James has been disrupting the testing industry since 1987. For more on James’ background, his body of work and his testing philosophy in general, you can check out his blog, website or follow him on Twitter.

In part one of our latest interview, we get his thoughts on his previous life as a developer; how testers should interact with engineers; the biggest waste of time in testing today; the skills that most testers lack and more.

uTest: In a recent lecture you said that you hated being a developer, saying it was like completing 25 crossword puzzles every day (i.e. boring and repetitive). What’s the one piece of advice you would offer to those are who are thinking of making the transition from dev to testing?

JB: I advise: make that transition– but please, study testing as you do.

Testing is not just another programming problem. Yet, too often, a programmer mentality sees testing as just the process of manipulating software. Sometimes, programmers dream of robot armies to do their “testing.” The quest for the clever tool then eclipses the mission of excellent testing. This is a little like trying to invent an android that can talk to your wife so that you don’t have to.

You can use all your tech skills, programmers. It’s fine to write software. But what testing is really about is rapid, deep learning. To do that, you have to get your face, and all the rest of you, right up close to that product. You must wrestle with the product– yes– by hand. Or as we like to say where I come from: you need to do your testing sapiently.

uTest: In that same presentation you also talked about the importance of making friends with developers. Why is the tester-developer relationship so adversarial at times?

JB: I don’t know, why does my wife not like it when I report defects in her? People are strange that way…

Seriously, it’s easy to see the dynamic. Anyone who creates a piece of work and submits it for judgment is going to feel judged. That’s not a pleasant feeling. And the problem is compounded by testers who glibly declare that this or that little nit or nat is a “defect,” as if anything they personally don’t like is a quality problem for everybody. It is further compounded when programmers and testers are separated by large distances or other communication barriers, not to mention the process barriers.

Even though technical people are renowned and sought after for their social skills (I understand United Nations programmers were just about to solve the Arab-Israeli situation a few months ago, had it not been for the need to calm tensions between the Koreas.) testers and developers are people who see the world very differently. It’s a special challenge to relax and smile when a bug report seems to have been ignored.

Personally, I make a set of explicit commitments to any developer I work with on a project. I write them down and deliver them. This seems to help.

uTest: You’ve said many times that belief is a sin for testers – something we assume you’ve learned from experience. Was there anything in particular that led you to this truism? Or was it just years of experience?

JB: It’s not a matter of experience, but reason. Our job is vigilance. To lose vigilance is to abdicate our responsibility. Vigilance, in testing, means being a good skeptic. We must reject certainty in any form. We’re the Knights of May Be. To believe is to cease questioning; to fall asleep at our posts.

I use lots of information. I work hard not to believe it. This is my discipline.

uTest: What’s the biggest waste of time in testing today?

Read more…