James Bach is no stranger to this problem, and his latest blog post is a blueprint for making that relationship more productive and professional. Titled A Tester’s Commitments, James starts by writing:

Dear Programmer,

My job is to help you look good. My job is to support you as you create quality; to ease that burden instead of adding to it.

What follows are twelve commitments a tester should make to their programmers. They include things like:

• I provide a service. You are an important client of that service. I am not satisfied unless you are satisfied.
• I will learn the product quickly, and make use of that knowledge to test more cleverly.
• I will not carelessly waste your time. Or if I do, I will learn from that mistake.

But James is not in usual form unless he invites controversy, and that first bullet struck quite a chord with some of his readers. Testers provide a service!? Since when?

James wrote some follow-up that makes a fascinating and compelling case for more “service” between people within an organization, and that it’s not a bad thing for someone to serve their peers:

Please meditate on the difference between service and subservience. I am a servant and I am proud of that. I am support crew. I spent my time as a production programmer and I’m glad I don’t do that any more. I don’t like that sort of pressure. I like to serve people who will take that pressure on my behalf.

This doesn’t make me a doormat. Nobody wipes their feet on me– I clean their feet. There’s a world of difference. Good mothers know this difference better than anyone.

Take a look at the whole post for more of James’s commitments to programmers as well as his great thoughts about improving teams with a greater emphasis on service.

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?

The only constant in life is change, it’s said.  And over the next 3-5 years, it’s going to be interesting to watch every stakeholder in the Apple ecosystem silently cast their vote about the saliency of the brand, and collectively determine the company’s future.

Consumers will judge with their pocketbooks whether iDevices remain revolutionary.  Enterprises will decide to invest in the iPad…or not.  Talent will vote with their pen, signing job offers from Apple…or not.  App developers will watch marketshare and and competing platforms’ ability to drive revenue with app discovery and merchandising technologies. Suppliers will re-evaluate their strategic alliances and preferred partners.

And investors? Competitors like Google?  Watching all of these subtle harbingers like hawks.

Acutely aware of his fragile mortality, Steve Jobs must surely have accelerated his succession planning and spent hours meditating on how best to expand a corporate culture of entrepreneurialism.  I can only begin to imagine the burden of responsibility he (like all CEOs) must have felt to maintain job security for the nearly 50,000 Apple employees worldwide.  And not the least, the utter determination he must have felt privately to ensure that his vision…his passion… continued beyond his lifetime.  This was a man who worked on Apple until his last day.

In a 2008 interview with CNN Money, Jobs confirmed:  “I mean, some people say, ‘Oh, God, if [Jobs] got run over by a bus, Apple would be in trouble.’ And, you know, I think it wouldn’t be a party, but there are really capable people at Apple. My job is to make the whole executive team good enough to be successors, so that’s what I try to do.”

Time will tell.

What do you predict for Apple in a post-Steve Jobs world?

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?

JB: Useless test documentation is a candidate for that– frequently compounded by wasting huge effort trying to automate the simplistic documented checks and keeping that automation running. Test metrics are also a waste, most of the time.

Of course you know I think that certification is a waste– a tape worm parasite, living off our flesh– but probably not the biggest waste.

Since testing maturity models bring all this together into a grand festival of waste, that has to be closer to the biggest.

That new ISO testing standard is a magnificent waste, too. It will not help anyone do anything worthwhile, I predict.

Okay, here is the biggest waste as I see it: All those things I mentioned conspire to keep our craft in a childlike state of fantasy and ignorance. Managers are coddled by cynical and/or craven consultants, like self-indulgent perennially drunk rich kids, instead of being doused in cold water and told to sober up. And this has led to a world where technology is routinely poorly tested, medical devices routinely recalled, security breaches routinely routine, and terrible sums of money are wasted cleaning up messes that didn’t need to happen in the first place.

That’s a lot of waste.

uTest: We were interested to learn that you spend a fair amount of time coaching testers over Skype…for free. 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?

JB: Yeah, I like Skype coaching. I charge for some of it, but most I do for free. When I do it for free I tend not to schedule it in advance (people just catch me online) and I require that the student allows me to publish the transcript of our sessions. In this way, I’m gathering material for my test coaching book.

Sometimes the coaching is about answering questions. Mostly it’s about testers getting taking on challenges from me and working through them.

One of my goals is to create a change in the testers minds so that they can begin to perceive and process ideas that have been obscure to them, up to that point.

Sometimes it’s quite concrete. Other times it’s conceptual. This exchange happened yesterday:

—————–

James Bach: Whom do you serve?

Sue: The business.

James Bach: No, that’s not a person. You serve people, not concepts.

If you do a bad job concepts will not fire you, people will. I mean what people in your organization depend upon you to do your work? Who will be upset if you do it badly?

Sue: hhhmmmm you are making me think about this…if wrong insurance rates are produced; legal would be involved. But, I never considered them my client.

James Bach: You don’t have a manager? You don’t work in a group that has a leader? You don’t have co-workers?

Sue: Yes, I have a manager and co-workers.

James Bach: Is there some reason why you don’t consider your manager to be your client?

Sue: I never really did.

————–

Here, I’m working with Sue, who is a very experienced tester, to help her get a whole lot clearer about what she actually does for a living.

I asked her to write me a list of what she’s good at, and what she’s not so good at. I noticed her list was remarkably vague. This suggested to me that she wasn’t used to thinking about testing skills and issues in any pointed way, so I decided to use a common coaching pattern: drilling down.

I asked her to list skills of testing. I picked one item on her list (“mission setting”) and asked her to get specific about what that meant. This is when the exchange, above, happened. It was like walking into a very cluttered closet that turned out to be a kitchen connected to a parking garage. Later in the conversation she gets clearer about her job, and we begin to sort things out. Like a lot of testers, Sue knows what she’s doing in a visceral way, but has trouble putting it into words. That’s partly because no one has pushed her before to learn a useful rhetoric of testing.

When I encounter conceptual confusion I sometimes roll up my sleeves and begin to offer some operational distinctions that I hope will make communication and thinking clearer. I try to lead the tester there by framing questions that make them aware of the confusion they are laboring under. My questions can be pretty aggressive, so I generally coach people who are highly motivated.

Other times, I will suggest an exercise to develop a shared experience that will help cut through the confusion.

Also, sometimes I just come out and say “Here’s a good way to think, why not try that?”

That’s how the sessions go, more or less.

uTest: On a similar note, is there a particular skill or trait that you find most testers to be lacking? And what can they do to improve this?

JB: There are several that I notice in particular. One is practical mathematics. Another is writing. Another is, um, reading. (My theory is that people who were forced by their parents to go to university often decide to swear off all educational development once they get out of school. But I don’t really know why more testers don’t seem to study their craft all that much.)

Maybe more vital than those: rhetorical skill. This includes verbal self-defense as well as story-telling skill. This is a skill that requires practice, and apparently testers aren’t getting it, because many of them look like frightened bunnies to me when I challenge them to give a professional test report. Rhetorical skill improves when you practice giving presentations to your colleagues. This is why I try to start peer conferences wherever I go. I just did one in Estonia, and we’re planning one in Romania, next year.

If there’s a single skill that testers HAVE, that I wish they had LESS of, it’s the skill of faking their work. All over the world, fake software testing (what they call “Possum Testing” in New Zealand) is an accepted, normal practice. It’s disgusting. But, of course, testers are often afraid that they will be fired if they stop doing it.

Editor’s note: Continue reading Part II.

Let’s begin with a simple fact – developers are the ones who “create” software defects in the first place. To be fair, they don’t knowingly create buggy software, but that’s the widely accepted norm – we’re human after all. However, when bugs are discovered after the product launches, testers are typically singled out and blamed. Why?

Part of the reason is due to the misnomer that QA should stand for “quality assurance.” Do QA professionals truly assure the quality of a product, or do they assist in delivering high quality products (as Jon Bach has suggested)? So if you’re a tester by trade, I sympathize with you. On the one hand, buggy software leads to job security. On the other hand, you are constantly on the hot seat and looking over your shoulder, wondering when and where the next bug will surface. But instead of despairing over these details, testers should rise to the challenge.

Here are a few examples of how testers can lead the quality initiative:

• Continually preach (and put into practice) that quality is a group effort across both development and testing groups (without shifting the blame back to the developers)

• Work with executive and project management to understand prioritization of features and bug fixes

• Provide as much information as possible for high-priority bugs in order to help developers quickly address the root cause of these defects

• Clarify use cases and user scenarios from a wide variety of the end user base

• If there is a high developer to tester ratio within your group, expand and complement your testing efforts by leveraging a trusted third party (now who could that be? )

These are only a few examples of how software testers can become effective quality ambassadors. If you have other recommendations, please reply with a comment below.

According to Game Developer Research, 25% of game developers are now making mobile games – that’s up from a mere 12% in 2009!

In addition, a survey conducted by iGR found that more than half (53%) of US mobile developers are building apps for Apple’s iPhone OS. BlackBerry was the next most popular, followed by Android and Windows Mobile.

In response to this incredible momentum, this year marks the launch of Mobile App World 2010, where global leaders in mobile tech and app development and entrepreneurs will gather to network and learn about the latest developments and innovations.

uTest will be among the outstanding line-up of more than 40 speakers, which includes Google, Microsoft, Ericsson, Orange Global and the BBC, who will be discussing the future of mobile apps. Shoot us a note if you’ll be around!

Note: If you’re looking for some cool, new mobile apps, check out Mobile App World’s August Apps Of The Month. You may spot a uTester’s favorite app!

Our guest blogger this month is Atul Angra. A resident of India, Atul is one of our more accomplished testers (a Gold Tester in fact), with over six years of professional experience. He’s a photographer at heart, but a tester by trade, with domain expertise in healthcare and finance.

*******

Let’s take a scenario where a tester follows the rules and reports 100 bugs. Some of these bugs were traced to non-documented requirements that are implicit in nature, such as a drop-down list not populating alphabetically and things of that nature. These bugs are quite common and usually end up in conflict, as development teams reject them based on the argument that it’s not a defined requirement.

Here, both the developer and tester are not ready to close this issue – and they are both correct. The traditional way these issues are resolved is by involving someone from management to intervene and make a decision. The time spent in escalation and argument is much greater than what it would have taken to actually fix the issue.

At a high level, we could blame the team which collected requirement, but this may not be the case when it comes to implicit requirements. Many of these situations could be resolved if the tester demonstrates interpersonal skills.

Testers play a challenging and critical role in the organization. They dare their developer counterparts and are constantly challenged by release managers, as they pose significant risk in delaying the release. This may even stop the organization from achieving a financial target on time. In other words, testers play the role of Devil’s advocate when it comes to improving quality of a deliverable.

As such, good testing skills and good interpersonal skills make the KILLER COMBO that suits this role. Critics are rarely appreciated for their work, but coaches are. Yet coaches and critics do the same thing: they point out your mistakes and give you a chance to perform better the next time around.

The difference is in their approach. An ideal tester should become a coach instead of a critic. Developers turn defensive when testers approach them with a statement such as “This is not working as intended.”

With good interpersonal skills, these discussions can become more effective. A good tester will put forth a scenario that makes the developer consider the impact if the bug is not fixed.

A tester who reports the maximum number of critical bugs with a low rejection ratio is considered efficient. Other expectations from testers are to meet deadlines, ensure process compliance, and practice good documentation with complete functional testing. They ignore a very important attribute here:  interpersonal skills.

Conclusion:

A tester might have all the required technical skills, but may still fail because of his/her interpersonal skills. A bug that could have been amicably solved turns into a management issue with leads to a lot of wasted time.

Testers should spend time in enhancing their interpersonal skills. People always like to have colleagues who are a good listeners and who love to share knowledge. One who shares information and resources, and is helpful by bringing conflicts to the surface and getting them resolved in an ethical and professional manner.

Editor’s note: If you would like to write for our Guest Blogger series, send your posts and ideas to me at mikeb@utest.com

Without the right to a fair trial however, many of these bugs are  found guilty of crimes they did not commit. Perhaps a witness confused them with a similar looking feature, or maybe they were framed by a developer…

In any event, when they are to blame, software bugs hardly ever face the cruel and unusual punishment they deserve. Most of the time, they are back on the streets web the very next day. Where’s the outrage? Won’t somebody think of the user!

So just how lawless have software bugs become? Here’s a list of recent crimes for which they are suspects:

Market Manipulation
“The House Financial Services securities subcommittee plans to hold a hearing to examine what caused the US stock market to plunge almost 1,000 points in a half hour Thursday, and it called on the SEC to investigate possible problems with computer algorithms that may have exacerbated a human order-entry error and led to the precipitous drop. ‘Reports have surfaced that much of this movement was potentially as a result of a computer glitch,’ Committee Chairman Kanjorski said. ‘We cannot allow a technological error to spook the markets and cause panic. This is unacceptable. In this day and age and with the use of such complex technology, we should be able to make sure that our financial markets are effectively monitored and investors are protected.’” (From Slashdot)

Voter Fraud
“Presidential elections will proceed next week as scheduled and a voting machine supplier has promised to correct defects that had sparked fears of chaotic failure in the Philippines’ first automated vote, officials said Wednesday.The Commission on Elections ordered the recall Tuesday of 76,000 memory cards to be used in optical counting machines after some malfunctioned in tests….The glitches were discovered just six days before 50 million Filipino voters elect a new president, vice president and officials to fill nearly 18,000 national and local posts in elections that have been sullied by suspicions of possible vote-rigging….” (From the Associated Press)

Kidnapping
“A Twitter security glitch left celebrities and members of the public mourning the temporary loss of their legions of online fans yesterday….The technical flaw, which allowed any Twitter user to force another to subscribe to their ‘tweets’ without the ‘follower’ giving permission, was discovered by staff yesterday….It means thousands of star users found themselves following complete strangers….Reality TV star Kim Kardashian wrote: ‘Someone hacked my account and direct messaged me! They have added over 200 new people! Ughhhh.” (From DailyMail.co.uk)

Driving to Endanger
” Toyota instituted the Vehicle Stability Control system in 1997 on Lexus vehicles, which it describes as “sensors, actuators, and computer electronics (that) help avoid and recover from vehicle skids and spins.” Sensors detect when the vehicle’s direction of travel does not correlate with “driver steering inputs.” The system then uses throttle and selective brake intervention to help maintain the path of travel.

In the case of the Lexus GX 460, “it was a bad choice of (programmed) settings,” said Jeff Bartlett, online deputy editor for autos at Consumer Reports, which first identified the problem. “If you were decelerating from a highway to an off-ramp–they just gave it too much latitude, really,” he said in a phone interview. “It wasn’t an electronic problem per se, it was more of an engineering software decision.” (From CNET)

If you have information that could lead to the arrest or exoneration of a software bug, you should sign up to our tester community to claim your reward.

Our Testing the Limits guest this month is testing guru Scott Barber, the Chief Technologist of PerfTestPlus. A speaker, writer, teacher and entrepreneur, Scott has one of the most impressive resumes in the business, particularly in the realm of customized testing methodologies, embedded systems testing, personal security systems and other topics – all of which are discussed on his blog.

In Part I of our 3-part interview, Scott discusses the Manifesto for Agile Development (almost ten years after it was created); the expectations of today’s testing managers; the notion of testers as an “unfortunate necessity”, the 1983 War Games movie and more.

uTest: As a signatory on the Manifesto for Agile Development, can you comment on the progress being made by software companies in upholding these principles? Have they exceeded your expectations, or is there still a long way to go?

SB: Honestly, I think the buzz around the “Agile movement” has, in many cases, taken the industry in an unfortunate direction. I meet far too many people and companies who are completely unfamiliar with the Agile Manifesto and think of Agile as a collection of practices, processes, and tools. The reality is that Agile is a far more a mindset and a culture than it is a collection of practices, processes and tools. Agile isn’t the best fit for every situation, or for every person.

I believe that the trend to “go Agile” is misguided. If a company is developing good software, the people involved in developing that software are happy working there, the software development is sustainable, and the business is being adequately served by that software, there’s really no need for them to try to be more or less Agile. Agile has challenges like any other culture, but the single biggest challenge I find is companies trying to solve development, process, management, and/or schedule problems by “going Agile.” Teams who have grown up in a culture that is fundamentally different than Agile simply will not find it easy to “go Agile.”

Think of it this way. Telling a team to “go Agile” between projects is like telling a professional baseball player to switch from being a right-handed hitter to being a left-handed hitter between seasons – and expecting that to break their hitting slump. You simply don’t see that. What you do see is batters working with coaches to re-evaluate their swing, work on their timing, spend more time in the weight room, etc.

Personally, I am happiest when I’m working in an Agile culture, but that is a personal preference, nothing more. What I do think would serve individuals and teams well, would be to read the Agile Manifesto and really think about whether or not those principles are a good fit for themselves, their team, and/or their organization. If so, I recommend embracing them.  If not, I recommend finding or developing an equivalent set of principles to build a culture around.

uTest: In a recent article, you highlight the critical point that “the perceived value of testing varies widely from individual to individual, team to team and company to company.” Can you further elaborate on how testing managers can do a better job of setting clear expectations?

SB: Consider these scenarios:

• Company A executives are looking for the testing to be their defense in case of failure and lawsuits
• Company B project managers want testing to say “ship it” so that if there are problems in production, they don’t get in trouble
• Company C developers want testing to show them the issues before management notices them and mandates changes to the development process… yet again.
• Company D is developing software for a client who expects testing to ensure their needs are met
• Company E just spent millions on a marketing campaign and is counting on testing to ensure that the company doesn’t get egg on its face when the campaign is released.

In each of these cases, the test manager is certainly the person who needs to lead the test team to adding the most value to the project. The challenge is that the test manager is often in the worst position to get straight answers.  Test managers are typically the lowest-level role in a company to hold the title “manager.” They don’t generally get to sit in the board meetings where defense against lawsuits are discussed, they don’t frequently have direct contact with the client, developers don’t often treat test managers as confidants, and who would tell a test manager that the purpose of his/her team is to take the blame if something goes wrong, even if it is completely out of their control?

How test managers, and testers, can do a better job is to take a step back and really consider what is going on in the company, what instructions they are being given, what questions they are being asked, and who seems happy or grumpy with the test results being provided.  Paying attention things like those will frequently make the “real story” pretty clear, and once the story starts to become clear, you can start asking smart questions that actually lead to pretty straight answers.

What doesn’t work is assuming that because you are the test manager, or the tester, that you *know* how your testing adds value to the company, that you *know* what the most important testing is, and that you *know* the managers and executives are idiots because of what they are telling you to test.  The fact is that even if your managers and executives are idiots, that doesn’t mean that they don’t have a sound and reasonable business reason to want what they are asking for. It’s not up to us to judge them for either being idiots or for making clumsy requests that don’t actually help them resolve their concern. It is up to us, however, to help them figure out what they actually need, help them figure out how to meet that need, and then guide our testing to best serve that need.

uTest: You have an impressive knack for drawing testing analogies from your lessons learned as an officer in the U.S. Army. What is the true value of outlining the situation, mission and intent of a software development/testing project?

SB: Thanks.  It’s not just the Army; it’s my life experience in general.  I suspect that has more to do with the fact that my parents were both educators and that I didn’t even know there was such a thing as software testing until I got hired to be a “Performance Engineer” and was introduced to the software test team on my way to my first client. So I pretty much had to figure it all out for myself with no real training in testing.

In this case, I was trying to figure out what my role really was. I clearly was not the decision-maker about whether or not to ship the product. I didn’t have the authority to tell the developers what should be fixed. So I applied the model I knew and asked myself “What is the situation here?”, “What is my mission?”, and “What is the overall intent of the client for the project as a whole?”

Over time, what I found was that the situation question helped me to understand things like where testing fit in the scheme of the project; who is panicked over what; how long I have to complete my tasks with what resources; who my allies are; what things are likely to block my success – that sort of thing. Much later, I learned that many testers refer to this as “context”, which I think is a very good word for it.

The mission question helped me figure out what was expected of me.  As it turned out, the folks I was reporting to often didn’t really know how to respond to my question of “What is my mission?”  They’d say things like “Well, test it and give me the results, of course.” My follow-up question of “Test it for what?” and “What kind of results?” didn’t help to clarify things either. So I learned to actually draft a little mission statement, like “Provide as much information as I can to management about issues I believe will cause lost clients or calls to tech support.” Sometimes someone would get very upset and change my mission statement, but that was fine by me because then I knew what their expectations were.

The intent question is what helped me stay focused on what really mattered.  The fact is that if the business we are working for fails, it doesn’t really matter how well tested a piece of software is.  No business pays testers for the sake of paying testers.  The truth is that most organizations feel that testers are an unfortunate necessity.  That truth makes it all the more important that our work add at least equal value to the business, as it costs the business to have us there in the first place.

It is at least as important as it is to have the situation, mission, and intent information individually, to look at those three items collectively. Often when I look at these three items collectively, what I find is that those three items contradict or work against one another. That is typically a good indication that either I have gotten things very confused, or it’s time for some stakeholders to have a meeting to figure out what is *really* important.

uTest: To our knowledge, no one has produced a movie entirely about software testers. However, there have been some notable software bugs in motion pictures (HAL from 2001: A Space Odyssey, the “Doomsday Machine” from Dr. Strangelove, the compound interest bug from Office Space, et al). If you had to suggest a movie that would inspire testers, what would it be and why? There are no wrong answers, except for The Net starring Sandra Bullock and Rocky 5.

SB: WarGames, 1983. All I have to say, is if you’ve built a computer capable of running WWIII simulations, and that is the same computer that controls the launch commands for nuclear warheads, and that computer is accessible via brute force hack of dialing phone numbers over a modem, you either didn’t have any testers or you didn’t listen to them.

Editor’s note: Here’s part II of the interview.

In Part II of our interview with Google’s Patrick Copeland, we discuss the challenges of managing a global engineering team; rewarding developers with food pellets; the difference between a good tester and a great tester; and why some companies will never launch a high-quality app. By the way, did you miss Part I of our interview?

uTest: What are some of the challenges that come with managing teams in dozen (or more) countries, as you’re currently doing? How difficult is it to maintain control over the people, processes and products? And when do you sleep?

PC: “Maintaining control over people” <smiling and laughing like Dr. Evil>.

But that’s not how it works at Google. The truth is…our team structure is atypical in the industry. For one, we are a flat company with many Nooglers being a few steps below senior executives. The expectation is that people and teams are semi-autonomous. In this model it’s impractical for managers to be controllers. And regardless, I’d rather set up teams that are made of great people who can run their areas themselves. My focus is on helping teams to be effective. Managers at Google are generally judged on their ability to enable smart people to get things done. Many have 15 or more direct reports, introducing some chaos and reducing the time available to micromanage.

One way we get everyone moving in a similar direction is to use OKRs, it came to Google thanks to board member John Doerr back in 2000. John stressed the importance of setting overall company Objectives and Key Results that would help develop departmental objectives; in turn, individual OKRs for every employee would support achievement of team and company wide goals. In Q1 of 2000, we rolled out our first company-wide OKRs, which included “8 million searches/day” and “Select CEO.” We’ve come a long way since then.

uTest: A lot’s been made of the unique and friendly work environment Google offers its employees. Does this also apply to your engineers? Or are they handcuffed to their desks and given food pellets for every line of code written (like we do at uTest)? Seriously though, how does an open atmosphere lend itself to better software?

PC: We have a pretty open culture where engineers have a good degree of freedom to invest in areas that interest them. We have an idea called “20% time” where engineers are encourage to invest a portion of their time in projects outside of their primary area.

Does culture help to make better software? I think so, but it’s a tough thing to quantify. On occasion the idea of collecting and measuring “productivity metrics” has come up (ex. lines of code, # of check-ins). We uniformly resist this because similar metrics can result in undesirable outcomes as people try to “succeed” in the system. Our biggest measure of performance, besides the velocity of innovation being delivered to customers, is quarterly peer reviews. This type of peer system reinforces ideas like teamwork, making sure you are having an impact, and building respect from peers. It’s more subjective, but harder to “game” and, ultimately, much more valuable in reflecting the real value and contribution of an individual.

BTW, “Food-pellets” wouldn’t work because our engineers already have free access to gourmet food.

uTest: What’s the difference between a good tester and a great tester?

PC: Good testers can be trained. Among many others, the basics you need to be good are: depth in computer fundamentals, an understanding of the application domain, an strong understanding of the use case, empathy of the user, mastery of metrics, and a focus on the development process.

Great testers, meaning the 90th percentile, are rare and special. Not everyone can be truly great. In my experience great developers do not always make great testers, but great testers (who also have strong design skills) can make great developers. It’s a mindset and a passion. From the 100s of interviews I’ve done, “great” boils down to: 1) a special predisposition to finding problems and 2) a passion for testing to go along with that predisposition. In other words, they love testing and they are good at it. They also appreciate that the challenges of testing are, more often than not, equal or greater than the challenges of programming. A great “career” tester with the testing gene and the right attitude will always be able to find a job. They are gold.

uTest: What’s the greatest barrier to designing, developing and launching high-quality products on a consistent basis (deadlines, prioritizing, competing visions, etc)? Said different, why can’t every company launch world-class apps every time?

PC: Every product I’ve worked on required a unique approach. There are so many variables in play and most of them are situational. Some of them you can control almost completely (e.g. technology choices). Many others you can control somewhat. Others still are completely outside of your control (ex. what the competition decides to do).

Some companies try to normalize their development process. One thread common to formal development models are that they focus on a few of the many variables: improving efficiency, predictable process, estimation of quality, or others. Process-heavy development models may work well for manufacturing airplanes and have been successfully applied by some companies, they have been viewed by many developers as burdensome and contrary to the creative nature of writing innovative software. Conversely, “process-less process”, can lead to a heroic culture that’s unable to repeatedly deliver. There needs to be balance.

Consider the physics of flight as an analogy to software process. In addition to reasonable flying conditions and an experienced pilot, the key to getting airborne is having an appropriate balance of factors that match the situation: too much weight or too little thrust can be disastrous depending on the situation. Similarly, teams, products and process all have virtual physics. For instance, adding engineers late in a product cycle doesn’t necessarily provide more lift. Adopting a new process may give a team more thrust momentarily, but may also incur a longer term drag that makes them incapable of innovation.

The popularity of Agile, while not a wholesale rejection of more rigid processes, indicates that developers desire more balance and creativity. Whatever we do to make software higher quality and more predictable to build, we must maintain a balance that encourages the innovative aspects of the art form. We need to motivate smart minds to solve hard problems and deliver rich features to customers. In other words, we need to be adaptable to stay airborne for the long term.

Editor’s note: Part III of our interview with Patrick will be posted tomorrow, so be sure to check back in.