Software Testing Blog

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

It’s a shame the doctor didn’t have a protective layer on his head to protect him from Susie’s parents.

Once they recovered from their anger, they took Susie to get a second opinion.

Conversation with Dr. Diplomacy

“What a great kid your Susie is. She’s a whiz with numbers.”

Susie’s parents beam.  “But is she ready for school, doctor?”

“Well, she passed most of the tests, but there are a couple of things I’m concerned about. We need to figure out what’s causing this rash on her fingers and toes before letting her go to school. This looks like an allergy, so with some additional tests we should be able to narrow down the culprit. Usually, with a simple change in diet, we can get it all cleared up.”

“And her head? Is it true she needs major surgery?”

“We can weigh the pros and cons of surgery, but there is a less intrusive alternative. She can wear a helmet whenever she’s riding her bike or engaging in activities that might put her at risk for a head injury.”

“Thank you SO much Dr. Diplomacy! We trust you and will send all of our friends to you.”

~~

It’s not always going to be so easy to solve each problem. And there are times when a product is not ready to be released. The tester does need to stand firm about his findings. However, here are some lessons in communication that will be beneficial in ensuring effective communication between the tester and the developer:

1. Don’t report the same bug multiple times.

Know the code and application well enough to be able to determine if different scenarios are uncovering the same bug.  If you suspect that one fix will address multiple symptoms, report the symptoms as a single bug, rather than multiple bugs.

2. Don’t inflate the seriousness of the problem.

It’s common for a tester to be proud of finding a serious bug. However, until the specifics are known it’s better to simply state the facts and not jump to conclusions that haven’t been proven.  Avoid dramatics.

3. Find some positive things to report.

Though it’s important to report on the bugs and issues, the developers have worked hard at creating a product. Take some time to let them know of the tests that passed and appreciate the positive findings.

4. Brainstorm alternatives.

Don’t assume there is only one fix. Look for work-arounds and solutions that might allow for a product to be released, while still minimizing the risk of product failure.

5. Refrain from offering negative opinions that can’t be validated.

Stick to reports that will give factual information and be traceable back to the requirements.  Don’t report that an application has an “ugly” user interface.  Test against what the customer requirements were, even if those differ from your own opinions. If you have concerns, use sensitivity when discussing them.

6. Take pride in the application.

Ideally, you and the developer are partners; working together to ensure the product is delivered on time and with high quality.  Think of the application as your baby, too!