Quardev

Here at Quardev we feel pretty lucky to have such a talented and thoughtful crew and lucky to have such a vast network of telented and engaged friends and associates. The articles in this edition of the QQ are from our ranks and from our associates and we hope you will find something meaningful that you can use in your day.

This issue of the Quardev Quarterly will be the last in this format. Future Quardev newsletters will be monthly and shorter, easier to absorb we hope! We have lots to share and we hope you enjoy reading.

Enjoy the newsletter with our compliments and please contact us with questions, comments, or article ideas.

-The Quardev Crew!

Download the Quardev Quarterly - Q4 2008 PDF

Focusing on the Message: Voice and the Target Audience

By Fred Hagan, Technical Writer, Quardev, Inc.

Hey! Who do you think you're talking to?

Doesn't that question often determine not only what you'll say, but how you'll say it?

Imagine telling a co-worker all about a challenging project you've worked on. Now imagine telling the same thing to a prospective employer at a job interview. Now tell it to a room full of Boy Scouts on Career Day. Now tell it to (most important of all) your customer. The same information probably sounds pretty different in each of those audience contexts, right?

Most good writing depends on techniques that work best when they're barely noticed by the reader. A case in point is the use of "voice," which is determined as much by the nature of the audience as by the type of information being conveyed. Now, I'm not talking about the use of "active voice" vs. "passive voice" that you probably heard ad nauseam from your high school English teacher. I'm referring to something more akin to persona - our perception of who is "speaking" the text. For each of the different audiences mentioned above, which "you" is doing the talking?

Consciously or not, whether we're speaking or writing, we normally choose a voice that's appropriate to the audience as well as to the kind of information we're presenting. Who is the primary audience for your product's user manual, for your company's annual report, for the white paper on your company's break-through process or technology, for the content of your company's web site? Are they business decision makers? Technical staff? Non-technical subject matter experts?

Or maybe your audience is a mix of readers from all of those categories. White papers, for example, tend to address more than one kind of audience. Until fairly recently, white papers primarily targeted technical readers. These days, however, the audience for white papers has shifted significantly to include decision makers and businesspeople as well as engineers and technical people. That's probably why white papers have become so widely used in targeted marketing campaigns in the IT industry. They're very effective for the "soft-sell-through-reader-education" approach, and as a bonus, they help to position companies as thought leaders in their fields.

With an audience made up of high-level businesspeople as well as technical staff, it's important not only that the writing is very clear, but also that the voice of the writer is perceived as credible and trustworthy. The moment the reader stops "buying" what the writer says, there's no reason for them to read even one more word. And they probably won't. Is that because they don't think the new super cool widget development system described in your white paper has any value? No, your widget maker is probably great and would probably provide huge benefits to your customer's company. But if the manager of the widget department doesn't read far enough to find that out, then it doesn't matter how cool your product is.

It's the writing, not the subject matter, that most often loses readers. Is the voice too stilted and formal? Is it too loose and chatty? Is it too technical or esoteric for the business readers? Too high-level or fluffy for the technical readers? Does it shift jarringly between those extremes? Whatever the reason, the net result is the same. The writing lost them somewhere along the way, and that fish just slipped off the hook.

The careful use of voice plays a major part in keeping the audience engaged. It helps them believe what you say. They'll come away from your piece not only with the clear information in its message, but also with a generally favorable impression of your company. That's the power of the right voice for your target audience. And that's what keeps them coming back.

Color Aided Test Design

Ben Brodsky, LexisNexis

In 1988, Edsger Dijkstra said "program testing may convincingly demonstrate the presence of bugs, but can never demonstrate their absence." For even the smallest and limited piece of software, testing possibilities can be exponential. It can be argued that there are less particles of matter in the known universe than there are test combinations. As much as we may wish to try, it's impossible to test everything.

But even the tests we choose to run may be so numerous that they look daunting when presented in a spreadsheet. Could there be a way for a big spreadsheet to seem less massive? Could there be a method that gives us that warm and fuzzy feeling in our bellies that tells us we did our due diligence?

Maybe color could help.

Like many good theories, color-aided test design started out informally, over lunch. As I sat down with my test manager Jon Bach, our discussion wound its way to the classic testing question: how does anyone know they have obtained good test coverage of something? Jon had brought with him a Monopoly game board. He didn't want to play the game, but rather explore the idea of using its value system to map out test coverage. For example, properties such as Park Place and Boardwalk were dark blue, and anyone who has ever played Monopoly knows that having dark blue properties is a good thing because they are the most valuable pieces on the board. Could test design have the same designation? Could there be a benefit in using color to represent different types of tests? For example, dark blue (Park Place) would mean something different then green (Pennsylvania Avenue) tests? I had never thought of approaching testing design from this kind of vantage point, and was instantly drawn to how it might work. We quickly determined that placing value on a test over another wasn't wise, or necessary. However, color could indicate test categorization. When we hit upon this notion, we knew we had something special.

The military has been using this for many years in the form of uniform color-coding. On the deck of an aircraft carrier, for example, the noise of the different aircraft is so loud that it's impossible to hear any verbal communication. Enter the use of color. Different colored uniforms are worn by different crewmembers which gives the advantage of instant identification. If you see someone wearing a purple uniform, you can be sure that they are Aviation Fuel Handlers. If they are in yellow, they are Flight Deck Officers or Plane Directors. White signifies Safety Observers, Squadron Trouble Shooters, Landing Signal Officers (LSO), and Medics. The power here is derived in the speed of recognition. In an instant, you can identify their roll and responsibility on board. Speed is a powerful tool.

We react to colors constantly in our daily lives. We see a red or yellow traffic sign and through years of conditioning, we understand what's being expressed. The big lettering on the stop sign itself is important, but we recognize color much faster than words. After the Monopoly board lunch talk, I started to notice color-coding in all different aspects of life. I was watching Star Wars and noticed a scene where a characters' silhouette and a light saber was all that could be seen. Without knowing what character it was, I knew if it was a protagonist or antagonist based solely on the color of the light saber.

After lunch, Jon put me in touch with Robert Sabourin, a colleague of his who he thought would be interested in this line of thought. After exchanging a few introductory emails, we agreed to put our minds together via an online video conference. As luck would have it, Sabourin was one (or ten) steps ahead of us in that he had been thinking of ways to corral test groups and classify them by color for some time.

The classification structure Sabourin came up with, admittedly, does not cover every classification possible; however it's the perfect mold to start with:

Capabilities: Green: (often, the beginning tests) Does the application do what it's supposed to do?

Failure Modes:Red: ("What-if" question) Challenge the expected outcome.

Inputs/outcomes:Pink: (Boundary tests) Push the limits on all input fields with string lengths (min/max).

White box testing White: Reviewing design code and data schemas. Exercising the decisions and paths through the program.

Quality Factors: Yellow: Performance, scalability, usability.

Usage Scenarios: Blue: Extremely high value tests: Ask not what the application does for the user, but what the user does for the application. View these from the perspective of the specific users. Can the user do their job with the application?

Creative Testing: Gold: Soap opera testing. Do what the user would normally do, but much more dramatically. What if the user goes through things in the wrong order?

When I first put this theory into practice and set out to create a test plan from the vantage point of these classifications, I quickly saw that my tests had more focus and value than before. I was immediately struck by how efficient my preparation felt. Having the focus to concentrate on one classification at a time seemed to free my mind to be much more creative.

I had 14 green, 6 red, 4 pink and 2 yellow tests. When I took this test plan to my dev team to discuss coverage, the payoff was instant. Within a matter of seconds, they knew what they were looking at and quickly pointed out that some of the red (failure) tests were not necessary. Fantastic! I cut them out of the test plan and saved some time to be later devoted to further testing in different areas. It seemed natural to use this color-coded test map as a centerpiece of discussion with my development team. They had the best idea about what's most important and what might affect the business. For example, they did not want any tests done on Admin accounts, and that I should only test on Non-Admin accounts. This allowed me to cut an entire test suite; one that would have been a complete waste of time. It also allowed me to work on others in places I knew would be better received.

The test plan originally would have taken near three hours. Now refocused, it was down to just one. This saved the company time, money and provided smarter tests that covered a higher level of value. It was a home run. Color Coding Theory works for the military, its utilized in the movies, and I'm convinced it has value in test planning as well. After all, the theory was formed over lunch.

References:

EWD1036: On the Cruelty of really teaching computing science. Professor Edsger Dijkstra; Department of Computer Sciences, University of Texas at Austin. December 2nd 1988

http://www.cs.utexas.edu/users/EWD/transcriptions/EWD10xx/EWD1036.html

http://en.wikipedia.org/wiki/Uniforms_of_the_United_States_Navy

How Much Testing Do We Need?

Jim Bullock, Rare Bird Enterprises, "Conscious Development"

"How does your startup handle testing?" asked the founder of an early stage tech company. With the first pass at their product in hand testing was in the way of Just Getting It Out There(tm). So, he described his frustration and asked: "How much testing do we need?"

That is the right question, but it isn't a testing question. It is a management question about where to put your resources. If testing is taking too long or costing too much for what you get, then don't do it. If what you're getting is valuable or even indispensible, do it, or even do more. The cheapest, fastest test is the one you don't do, that you also don't need. Yet, the test you don't do and do need is one of the most expensive. So, the game is deciding what information is best acquired by testing and is worth the cost for you, here and now.

One answer the founder got was "Don't bother testing. Get it out there." For an early product, learning from users is so valuable this can make sense. Yet, that's actually just a different kind of testing - exercising a system to get information about its behavior in use. Unstructured testing by users makes sense when you'd learn a lot and the cost of shipping mistakes is low. It's great when you have a vague idea of the value your product will have to customers. It's feasible when your customers are willing to play along, and you can capture their feedback. So, this kind of testing fits for many early-stage web sites. Meanwhile, exhaustive testing for "conformance to specification" may not be so valuable, since the specifications themselves are in question. What testing is valuable depends on your system and situation.

One answer the founder got was: "Never do performance testing." I'm no so sure about "never." For a small web-site using a common stack, this makes sense. The cost of slowdowns, outages, or even data loss is low. It's likely that someone is already pushing the stack far harder than you, so the likelihood of scaling problems is low. Even if something does go wrong, scaling performance is understood - it's been done before. Not doing performance tests makes perfect sense for systems like these. Yet, years ago I worked on a very high volume web system supporting a one-shot, four-day publicity event. Performance testing was a big deal because that stack had never been pushed that hard before, and the cost of failure in the field was astronomical. We had their attention for four days. So, performance testing sometimes makes sense - even for some consumer-facing web sites.

Really, the answer to "How much testing do we need?" comes down to:

• What can you afford to be wrong about? What can't you?
• What don't you know about your system that you'd like to? What's it worth to you to find out?

Defining those leads to the different kinds of testing you want and how much of each makes sense for you. Asking those questions also opens up additional reasons to do testing - it isn't just conformance to spec. For example, some of the greatest impact I've gotten from testing came from data-driven SPI using defect data to refine how we do development.

To the original question I replied:

"I think you mean: 'The testing we are doing takes longer and is more expensive than I'd like.' Well, that's true of development, product definition, marketing, sales, support, and so on. We'd like it all to be free. The question is, is it worth what it's costing? The real leverage is in deciding what testing you really need and are glad to pay for. As you think this through, I suspect you'll eliminate some current testing that isn't valuable for you, while adding testing you aren't yet doing. By thinking this through you'll get more value from you testing and in the end a better product."

By asking and answering "How much testing do we need?" that founder will likely be able to eliminate testing that's useless to him, while discovering value he'd like to have from testing that he didn't know he could get. If he involves his testers I think he'll be surprised at how much they can help him, doing testing, and figuring out what testing to do.

Calendar of Events - Quarter 1 2009

January 14, 2009

QASIG - How To Be A Test Pilot presented by Rob Bach

For more information about any of these events please see our Web site: www.Quardev.com/events

Quardev is looking for Great People

We are always looking for great people to join our team.

At Quardev you will work hard, you will enjoy a great working environment and benefits, and you will be building a solid, interesting, and flexible career where you can learn and grow.

If a career with Quardev sounds interesting, or sounds like it may be a fit for someone you know, check out our Careers page or contact us today via Quardev contact page.

We'd love to meet you!