Software Engineers: “Forgive Me Testers, For I Have Sinned”

A few days back, GigaOM posted terrific article on the 7 Sins of Software Development. When you read it, which I strongly suggest, I think you’ll see that testers play a huge role in absolving the various “deadly” sins of software engineers.

If you’re too apathetic to read the article (sloth is a sin, FYI) then check out the excerpts below:

Sloth
Sloth is apathy, not laziness. An apathetic programmer is the arguably the most detrimental, because he has zero interest in quality. On the other hand, a lazy programmer can be a good programmer, because laziness can drive long-term efficiencies. For example, if I’m too lazy to type in my password everywhere, I might create a single sign-on feature. Or, if I’m too lazy to manually deploy software, I will instead write an automatic deployment tool. Laziness and scalability go hand in hand.

Wrath
Although many software engineers seem peaceful, underneath the surface often lurks a passive aggressive personality. Take a look at source code comments to see examples of this hidden hostility. Usually profanity in source code is proportional to technical debt. However, it is vital that your engineers are not milquetoasts. Beware of the programmer who does not ask questions or who will use any text editor willingly. Good programmers have strong opinions, but they also appreciate lively debates.

Envy
Envy can be very dangerous in software development. Envy for other products often leads to feature creep. If someone mentions feature parity, you should ask, “But do we need it?” The ultimate killer feature is simplicity, but simple to use is hard to design. Also, it is easy to lose focus when you are constantly watching what other companies are doing. Imagine building towers out of Legos. Would you rather build one tower at a time or many towers in parallel? The parallel approach only works if the towers are identical. Otherwise, you spend too much time context switching. Agility is not the same as half-baked. And doing one thing well is still underappreciated.

Continue Reading

Passionate Gamers Go Beyond Just Being Heard

Mass Effect 3, the long awaited sequel to the hit Sci-Fi action adventure series was released earlier this month, and fans have been eager to get their hands on it so they could finally find out what happens to the game’s protagonist and beloved cast. However, shortly after it was released, gamers began to express their disappointment with Mass Effect 3’s ending.

When passionate fans are unhappy with a game’s story, they will react in a number of predictable ways. They’ll complain about it to anyone who will listen, vow never to enjoy anything from said creator ever again, or resort to writing their own fan fiction on any number of websites that publish such things.

In addition to these efforts, many fans of the game are going the extra mile to demand satisfaction from Bioware and Electronic Arts, the game’s developer and publisher respectively.  An online petition regarding the finale of the game has already garnered almost 12,000 signatures. The “Take Back Mass Effect 3″ campaign as it has become known, has 25,000 likes on Facebook, 3,000 Twitter followers and 40,000 backers in a Bioware forum poll. However not all the efforts are so level-headed, one fan was reportedly so disgruntled that he filed a false advertising complaint with the Federal Trade Commission.

A piece of good news that has come from all this is that Child’s Play charity has unexpectedly gained a lot of support from the movement. The Retake Mass Effect Child’s Play page has raised over $75,000 for the charity. The campaign organizers state:

“We would like to dispel the perception that we are angry or entitled. We simply wish to express our hope that there could be a different direction for a series we have all grown to love and bring positive attention to our petition for an alternate ending to the fantastic Mass Effect series.”

With most gaming news lately being about fans getting involved in funding and creating the games they love, this is sort of a natural progression of the crowd’s effect on beloved franchises once they are released into the wild.  Bioware is currently “working hard to maintain the right balance” between developer control and fan input on this issue, the company is definitely walking a very thin tightrope to be sure. Hopefully this issue develops into something positive the software and creative industries can learn from rather than spawn an age where designers and developers second guess every decision they make during the production of the apps and games we all use.

The Relationship Between Testers and Programmers

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?

Continue Reading

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?
Continue Reading

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?

Continue Reading

Does “Quality” Come From Testing?

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:

Continue Reading

What’s the Difference Between Designers and Developers?

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

Mobile App World, London: October 19-20, 2010

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! :)

Why Software Testers Need Interpersonal Skills

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.

Continue Reading

When Software Breaks (the law)

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)

Continue Reading