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…

PHP is one of the web’s most widely used and successful programming languages.  It’s easy to learn, easy to use, and extremely powerful.  Tools like Drupal and WordPress power millions of sites on Internet, and both were built using PHP.

But mighty Facebook stands above nearly everyone as the king of PHP.  With over 400 billion pageviews per month (yes, that’s billion with a ‘b’), Facebook serves up more webpages with PHP than just about anyone else.  Facebook’s engineers credit PHP with some of their success because PHP’s simplicity makes it easy to recruit new engineers, quickly train them, and get them started with the site’s code.

But PHP’s ease and simplicity comes with a very real downside for Facebook.  Like most scripted languages, PHP is substantially slower than compiled languages like C and C++.  Smaller sites running on fast servers may never notice PHP’s performance inadequacies, but Facebook faced the real possibility of spending millions of dollars for additional servers just to support PHP’s overhead.

Read more…

We’re excited to kick-off the new year with Yvette Francino as the latest contributor to our Guest Blogger series. Before joining the uTest community, Yvette  spent the bulk of her career as a developer for companies like IBM, and most recently, as an IT manager at Sun Microsystems. An aspiring novelist, she also publishes “New World Software Quality Assurance”, a blog covering all sorts of testing-related subjects.

In this post, Yvette offers advice for testers who hope to engage in ‘civilized’ dialogue with their developer counterparts. A touchy subject, to be sure!

Software testing is one of the few professions where an unfortunate task is to tell someone else what is wrong with their product!  This, of course, can make the recipient of such news – the developers – a bit defensive. Imagine hearing that your baby is defective! It’s therefore important to employ a bit of diplomacy when delivering such news.  Being a tester is comparable to being a doctor. Let’s listen in on couple of hypothetical conversations. Young Susie (i.e. the software) has been examined to see if she’s ready to enter Kindergarten (i.e. the market).

Conversation with Dr. Tactless

“I have found quite a few problems with Susie,” Dr. Tactless reports to Susie’s parents, looking quite satisfied with his report. “I found 20 problems on her hands and feet. Each toe on each foot has a rash on it. And each of her five fingers on her two hands also has a rash.  What have you been feeding this child? When a child has 20 problems, we can’t let her go to school.  Not only that, but her head is weak. She certainly will die if you let her go to school now.”

“Die? NOOO!”

“When I pushed her down, she knocked her head on the floor, and then she wasn’t able to think. Had I pushed her any harder, she certainly would have died.”

“Why did you push her down?” the parents ask in horror.

“I had to simulate what the kids at school will do.  She is really ugly – uglier than any kid I’ve ever seen. She’s going to be pushed down a lot. She’s going to need major surgery to put a protective layer on her head before I can sign off that she’s ready to go to school. ”

Read more…

Have you heard of Grand Central Dispatch?  If you’re a Mac addict, then you might know that it’s Apple’s new easy-to-use tool for parallelizing code.  If you’re not a Mac addict, then the first thing you should know is that GCD is one of the most exciting innovations in software development in years.  The second thing is that Apple just released it as a cross-platform open source project, meaning it’s coming soon to a platform near you.

Read more…

Barbara Liskov, professor of computer science at MIT, was recently awarded the Association for Computing Machinery’s A.M. Turing Award.  The Turing Award is much like the Nobel Prize for computing research, and in this case it was awarded for her “contributions to practical and theoretical foundations of programming language and system design, especially related to data abstraction, fault tolerance, and distributed computing.”

Professor Liskov was the first woman in the United States to receive a PhD in computer science, and she went on to develop new ideas in using abstraction in programming.  For software testers, however, she has also developed new techniques for improving fault tolerance in distributed computing systems.  From Dr. Dobb’s:

Her most recent research focuses on techniques that enable a system to continue operating properly in the event of the failure of some of its components. Her work on practical Byzantine fault tolerance demonstrated that there were more efficient ways of dealing with arbitrary (Byzantine) failures than had been previously known. Her insights have helped build robust, fault-tolerant distributed systems that are resistant to errors and hacking. This research is likely to change the way distributed system designers think about providing reliable service on today’s modern, vulnerable Internet.

Her ideas will no doubt influence how distributed, grid, and cloud computing systems are both developed and tested.  Congratulations to Professor Liskov for winning such an amazing prize!