Software Testing Blog

Testers and programmers are two groups of people who should get along, but often don’t. It’s a sad fact of life that testers (by virtue of what they do) often bring bad news. And programmers, by virtue of what they do, are the source of the defects that create the bad news. Rather than both accepting that this is a reality of life and working together, they allow the relationship to become acrimonious.

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?

Read more…

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…

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…

Okay, call this a bait and switch if you will, but the bottom line is you cannot test quality into an application. So if you can’t test quality into an app, do you then build it into an app? Or perhaps the more pertinent question is, ‘who contributes more to app quality – software developers or software testers?’ Playing with dynamite here, I know…

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:

Read more…

Not long ago, I wrote a post about tester stereotypes – where I dispelled the notion of testers being the lazy, blame-shifting robots they are often portrayed as in the tech world. Today, SixRevisions.com reminds us that testing is not the only profession subject to such generalizations. Here’s their funny graphic explaining the differences between web designers and web developers (click to enlarge).

Apps! Apps! And more apps! As the summer starts winding down here at uTest, we’ve been able to take a step back and a closer look at the big trends emerging all around us. What has been most apparent is the tremendous spike in mobile app testing needs. From top marketing agencies to retail giants to social gaming startups, our customers are developing more mobile apps to grow (or define) their businesses than ever before.

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. He’s also a former Bug Battle winner, a guest judge, a Tester of the Year, a Forums junkie, a crash course author and he’s here today to discuss how interpersonal skills can make or break a tester’s career. Enjoy!

*******

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.

Read more…

Whenever a major crime has been committed – or whenever foul play is involved – a software bug is sure to be one of the usual suspects.

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)

Read more…

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.”

Read more…

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?

Read more…