You are on page 1of 44

December 2006

$9.95

www.StickyMinds.com

LETS DO THE NUMBERS

The annual salary survey


results are in!
SEMPER FI

Lead like a US Marine

The Print Companion to

Changing
The Hand
Youre Dealt
Better Designs Through
Problem Redefinition

December 2006
Volume 8, Issue 11

Cover Story
CHANGING THE HAND YOURE DEALT
BETTER DESIGNS THROUGH PROBLEM REDEFINITION 18
A parable and a program fragment show how small changes to the problem can simplify the solution. by Payson Hall

Features

MARINE CORPS MAXIMS


PRINCIPLES FOR BUILDING STRONG TEST TEAMS 22
The value the Marine Corps places on teamwork can improve your team as well.
by Sean Buck

IS THERE AN ASSESSMENT IN THE HOUSE?


DIAGNOSING TEST PROCESS AILMENTS IN HOUSE 26
When youre not feeling well, you go for a check-up. Give your ailing test processes
the same treatment. by Ruud Teunissen

Columns &
Departments

TECHNICALLY SPEAKING 9
Believing Is Seeing by Lee Copeland
What you dont know can hurt you, and what you do know can too.

CODE CRAFT 10
The Ajax Balancing Act by Tod Golding
The path to Ajax has its pitfalls, but using it carefully can put you ahead of the game.

In Every Issue
Mark Your Calendar 4
Whats Happening
@ StickyMinds.com 7
Product Announcements 37
Ad Index 40

TEST CONNECTION 14
Rock, Paper, Scissors by Michael Bolton
The requirements process isnt linear. Learn how its elements influence each other.

MANAGEMENT CHRONICLES 16
In Search of Commitment Clarity by Michele Sliger
Overcommitting yourself means overcommitting your team.

THE LAST WORD 39


Happy Are the Software Engineers by Miska Hiltunen
Cultivate quality by empowering your engineers.

Better Software magazineThe print


companion to StickyMinds.com brings
you the hands-on, knowledge-building
information you need to run smarter
projects and deliver better products that
win in the marketplace and positively
affect the bottom line. Subscribe today
to get eleven issues per year including
the annual Tools Guide.
Visit www.BetterSoftware.com
or call 800-450-7854.

CAREER DEVELOPMENT 32

[Featured Department]

The Scoop on Employment Trends in 2006 by Heather Shanholtzer


Better Software magazine and StickyMinds.com offer up readers responses to our
annual salary survey.

Better Software magazine and StickyMinds.com We invite you to visit StickyMinds.com, the online
companion to Better Software magazine. StickyMinds.com covers the same pertinent topics as the
magazine, putting the power of information at the click of your mouse. Weekly columns, headline-making
bugs, hundreds of technical papers, an online Tools Guide, discussion boards, and so much more
make this your site for 24/7 brainfood to help you build better software.

www.StickyMinds.com

DECEMBER 2006

BETTER SOFTWARE

M A R K YO U R C A L E N DA R
Publisher
Wayne Middleton

February 13-15, 2007

Director of Publishing
Holly N. Bourquin

Software Testing Certification

Editorial

Atlanta, GA

Editor
Heather Shanholtzer

www.sqe.com/getcertified

Managing Technical Editor


Lee Copeland

February 27-March 1, 2007

Technical Editors
Mike Cohn, Brian Marick

Software Testing Certification


Dallas, TX

Managing Editor, StickyMinds.com


Francesca Matteu

www.sqe.com/getcertified

Managing Editor, Multimedia


Joseph McAllister
Production Assistant
Cheryl M. Burke

March 19-22, 2007


Introduction to Visual Studio 2005 Team System

Design

San Francisco, CA

Creative Director
David Parrish

www.sqe.com/trainingivs

Art Director
Sarah Rice
Advertising

March 20-22, 2007

VP of Sales and Business Development


Alison Wade

Software Testing Certification


Bethesda, MD

Director of Sales
Heather Buckman

www.sqe.com/getcertified

Senior Advertising Sales Manager


Shae Young
Advertising Sales Manager
Ellen Mahoney

May 14-18, 2007


STAREAST Software Testing Analysis & Review

Advertising Production Coordinator


Julie Morgenstern

The Rosen Centre Hotel

Circulation and Marketing

Orlando, FL

Senior Marketing Manager


Sommer Farrin

www.sqe.com/stareast

Circulation Coordinator
Justin Bridegan

June 18-21, 2007

A PUBLICATION OF SOFTWARE QUALITY ENGINEERING

Better Software Conference & EXPO


The Venetian
CONTACT US
Editors: editors@bettersoftware.com
Subscriber Services: info@bettersoftware.com
Phone: (904) 278-0524, (888) 268-8770
Fax: (904) 278-4380
Address:
Better Software, Software Quality Engineering, Inc.
330 Corporate Way, Suite 300
Orange Park, FL 32073

Las Vegas, NV
www.sqe.com/bettersoftwareconf

BETTER SOFTWARE

DECEMBER 2006

www.StickyMinds.com

brain food
for building
better
software

Whats Happening

EDITORS PICK

Tickle Me Silly, but Safely


More than ten years ago, Tickle Me Elmo hit the toy stores at around $29 per furry giggling machine. Parents fought for it in stores, and the kids loved it. Now the pint-sized monster is back.
Welcome TMX, the extreme Tickle Me Elmo that not only giggles but slaps his knee, laughs
so hard that he falls over, and even pounds on the ground in a crazed fit of laughter. The
newest model in the line of Tickle Me Elmos has already sold out in stores, and thats a
good thingfor online retailers. TMX can be found on eBay. Whether youre willing to pay
more than double its retail price is another story.
TMX and other hard-to-find store items arent the only reasons people shop online. Theres
the matter of comfort: Purchases are made from the privacy of your home. More importantly,
consumers can easily compare competitors prices without having to travel from store to
F R A N C E S C A M AT T E U
store. Comparisons are made as quickly as the Internet provider can transfer the information
from a server to the home.
For these reasons and more, the number of online shoppers is increasing as more network connections become
available to the masses. Obviously, this growth in online retail shopping also means more sensitive information is
traveling through cyberspace. And no other trend has needed security more than this.
StickyMinds.com columnist Ryan English shares valuable information about Web site security in Incorporating Web
Application Security Testing into Your Quality Assurance Process. Staying within the testing school of thought preached
throughout StickyMinds.comtest early and oftenhe modifies the software development process to fit the development lifecycle of a Web application. In this column, Ryan covers how to ensure security is baked into your Web
application by getting your quality assurance team involved early in the process. Other suggestions include choosing
tools that help replicate non-authenticated, authenticated, and administrative users and testing early and frequently.
Web applications are pieces of software that exist in an environment for the whole world to see and use. If one function of
your site or application doesnt work, it only takes seconds for the customer to move on to your competitor. Make sure
your Web site is ready for a flurry of online customers searching for the latest must-have item or information by reading
Ryan Englishs article today. www.stickyminds.com/editorspick8-11
Francesca Matteu, managing editor of StickyMinds.com, brings a background of public relations to her position. Francescas previous experience includes Web
site development and design and print publication management.

Pointer
Conference Material
Smaller-Scale Web Sites Need Performance Testing Too!
Even a smaller-scale Web site requires careful planning and execution of performance tests. Making the critical decisions
in a timely manner and identifying the performance goals are still prerequisites to a successful test. However, smaller
sites dont necessarily have the resources required to do large-scale testing, so compromises have to be made. This
requires good test planning. In this presentation first delivered at the Software Test Automation Fall 2003 Conference,
Dale Perry explains how to test a small site that is looking to grow, as well as the successes and pitfalls of achieving
reasonable goals. www.stickyminds.com/powerpass8-11
www.StickyMinds.com

DECEMBER 2006

BETTER SOFTWARE

Technically Speaking

Believing Is Seeing
by Lee Copeland
In 1949, Jerome Bruner and Leo Postman
of Harvard University published the results
of an experiment in belief and perception
that would become a classic. Subjects
were shown a series of five different
playing cards in random order for fractions of a second. The exposure times
used in the experiment started at 10 ms,
then increased as follows: 30 ms, 50 ms,
70 ms, 100 ms, 150 ms, 200 ms, 250
ms, 300 ms, 400 ms, 450 ms, 500 ms,
600 ms, 700 ms, 800 ms, 900 ms, and
finally 1,000 ms. Each card was presented
three times at the varying exposure
times until correct recognition occurred.
If at 1,000 ms recognition did not occur,
the next card was presented. Correct
recognition was defined as the subjects
giving two successive responses of the
cards actual color and shape.
The interesting part of the experiment
was that some of the playing
cards had been altered:
Some hearts and diamonds
had been changed so that
the symbols were black (instead of the usual red), and
some spades and clubs had
been changed to red (instead of black).
The subjects recognized 100 percent
of the normal cards within 350 ms, but
only 90 percent of the incongruous
cards were recognized when displayed
even for 1,000 ms (a full second). When
the cards were identified correctly, it
typically took the subjects four times
longer to identify the bogus cards.
The reason is simple. The subjects
unconsciously denied what their visual
systems presented to them. Because they
knew that all spades and clubs are black
and all hearts and diamonds are red,
they couldnt accept the reality of what
they observed.
When presented with a black three
of hearts, one subject gave twenty-four
successive responses that the card was a
black three of spades. For sixteen
successive responses, another subject
identified the card as a red three of

hearts. Some subjects reported


the color of the card as something other than red or black.
Only a few subjects finally
recognized that some of the
cards were, in fact, anomalous.
Bruner and Postman wrote,
Our major conclusion is . . .
perceptual organization is powerfully determined by expectations
built upon past commerce with the
environment. When such expectations
are violated by the environment, the
perceivers behavior can be described as
resistance to the recognition of the
unexpected or incongruous. (See the
StickyNotes for a link to the Bruner and
Postman paper.)
Gary Jaron summarized their findings
as follows: Beliefs have the power to
affect the minds ability to accurately
interpret incoming sense data. The
stronger the beliefs, the stronger the
convictions, the more resistant those
beliefs will be to being challenged by
incoming sense data of any kind. Those
strongly held beliefs will fight off any
incoming sense data that appears to,
and attempts to, contradict those prior
beliefs.
What does this mean to those of us
who are trying to create better software?
Our experience is a two-edged sword. It
is the basis of the skills we bring to bear
in solving problems. Whether in leading,
defining, designing, implementing, testing,
or supporting, those skills are a vital asset.
However, the Bruner-Postman experiment
shows that our experience can, in fact,
blind us to reality. Our subconscious
mind preprocesses sensory data, interpreting and categorizing it before our
conscious mind receives it. We must
constantly be aware that this is happening
and be open to data that conflicts with
what we already know. This is why it
is so easy to miss those requirements
defects, misunderstand design decisions,
write improper code, and miss defects
during testing.
www.StickyMinds.com

You should continually evaluate your


experience by asking: How will my
experience help me with my work? How
might my experience deceive me? Be
open to the obvious rather than trying to
match perceptions with expectations.
And remember, believing is seeing. {end}
Lee Copeland has more than thirty years
experience in the field of software development and testing. He is the author of
A Practitioners Guide to Software Test
Design. Lee is the managing technical editor
for Better Software magazine and a regular
columnist for StickyMinds.com. Contact
Lee at lcopeland@sqe.com.

Sticky
Notes
For more on the following topic, go to
www.StickyMinds.com/bettersoftware.


Bruner and Postman paper

Expert Opinions at Your Fingertips


PowerPass members can access the
STQE/Better Software magazine archive on
StickyMinds.com to read every
Technically Speaking ever published!
Get words of wisdom dating back to 1999
from such notables as Brian Marick,
Lee Copeland, Mike Cohn, Esther Derby,
Elisabeth Hendrickson, James Whittaker,
and Brian Lawrence. Visit
www.stickyminds.com/magarchive.

DECEMBER 2006

BETTER SOFTWARE

Code Craft

The Ajax Balancing Act


by Tod Golding

browsing faster. I wanted to bring my


whole fat-client desktop programming
model to my Web-based solution. And
for that, shipping snippets of HTML
across the wire simply wasnt going to
cut it.
Unfortunately, once I moved outside
snippets, the Ajax landscape got much
more complicated. The range of possible
Ajax solutions, technologies, frameworks,
and patterns was quite daunting. And
while there were plenty of people advocating different approaches, I didnt really
get the sense that the industry was
converging on a standard set of solutions.
If anything, in this phase of expansion,
it seemed like more new solutions were
surfacing every day.
Naturally, I found this aspect of Ajax
rather challenging. Even though I enjoyed
sinking my teeth into all the Ajax
technologies, I was growing increasingly
concerned about my ability to find a
cohesive approach that would make me
confident I was building my solution the
right way. In many respects, all the
competing concepts left me feeling like I
was very much on my own to figure out

10

www.StickyMinds.com

BETTER SOFTWARE

DECEMBER 2006

GETTY IMAGES

A little more than a year ago, I found


myself consumed by Ajax. I was building
my own Web-based application and
looking for an approach that would
solve all the user-experience limitations
traditionally associated with Web-based
applications. Ajax seemed to beon the
surface at leastthe answer I was seeking.
I had rather lofty goals. I wanted to
build an application with all the bells
and whistles youd find on any modern
desktop application. I had this vision of
building a highly interactive system,
where every click received an immediate
response and server interaction was
extremely transparent. Ultimately, if I
did my job right, I wanted someone to
wonder how I could have built this
application without using any plug-ins.
With this as the backdrop for my
foray in Ajax, I set out to understand
what elements of the Ajax model could
be used to bring my vision to life. As I
started to assemble the details, I turned to
the Ajax community in search of answers.
There had to be some well-established
consensus about the right way to
leverage Ajax to build a solution that
met all of my requirements.
When I turned to the Web for sample
applications, I found that one segment
of the Ajax world seemed to be focused
on using what I would label the snippet model. In this model, I found developers who were leveraging Ajax to
request snippets of HTML from the
server and using JavaScript to assemble
these snippets in the DOM.
The efficiency of this approach and
the ability to completely bypass the
Webs traditional request/response model
paid huge dividends. Whenever you visit
a site that leverages this approach, its
usually very apparent. By introducing
these mild Ajax tweaks, developers are
able to bring all new levels of responsiveness and usability to their sites.
Still, the simplicity of this snippet-based
approach didnt really fit my model. My
goal wasnt limited to making content

if I was building a robust new application


or a house of cards.
If you look at the roots of Ajax, it
sort of makes sense that I ended up in
this dilemma. After all, Ajax really isnt
a product or a specification. Its more like
a concept that is surrounded by a host of
competitors that have their own take on
how to maximize the value of being able
to make asynchronous calls to the server.
With all these competing Ajax models
staring you in the face, it becomes your
job to figure out how to weave together
the right combination of technologies to
meet the goals of your specific solution.
And, along the way, youll find that Ajax
may force you to re-explore some architectural topics that you may have
thought were part of your past.
For example, one key decision youll
face is deciding what type of data
youll want to cross the wire. While
XMLHttpRequest implies youre passing
XML, theres nothing that forces the
data in your message to be XML. It can be
any data format that can be represented as
a stream of text. Knowing this, vendors
have introduced a handful of different

Code Craft

Like any technology, Ajax has its pitfalls


and dark corners. You may end up enriching
your client only to find youre hammering
the server with too many requests.
schemes for moving data to and from
the server.
Youll also find yourself revisiting
questions about state management. The
richness of your Ajax experience can
change dramatically based on how and
where you decided to manage state. Are
you going to manage all the state in
browser, or are you going to take a
more server-centric approach?
Of course, your answers to some of
these questions will often generate even
more questions. Before long youll wonder,
Isnt there any standard approach to
this? Theres nothing worse than the
sinking feeling that youre living on the
bleeding edge as you piece together your
best interpretation of the currently
available technologies. And to add to
your discomfort, vendors are continually
introducing new frameworks, each
promising to be the ultimate solution.
So, does all of this complexity and
lack of convergence somehow mean
that we shouldnt be using Ajax? Is it
too soon or too new or too dangerous?
The answer to that question, from my
perspective, is a resounding no!
While the Ajax programming model
is still taking shape, the value that Ajax
and other rich Internet application technologies (Flex, WPF/E, OpenLaszlo,
etc.) bring to our solutions is huge. Ajax
already has proven its value to the market
and end-users, and wed all be making a
big mistake if we didnt try to find ways
to leverage it to make our products better.
At the same time, its important to
realize what youre biting off when you
decide to take on Ajax. If youre looking
to tackle the full Ajax experience and
build your whole client-side experience
around it, youre going to face some
challenges as you try to stitch together a
cohesive distillation of the pros and cons
of the various technologies and frameworks available to you.
12

BETTER SOFTWARE

DECEMBER 2006

www.StickyMinds.com

Like any technology, Ajax has its pitfalls and dark corners. You may end up
enriching your client only to find youre
hammering the server with too many
requests. Or you could expose yourself to
a whole new realm of security concerns.
The road to Ajax is littered with potholes
of this nature.
The main challenge, as I see it, is to
find a compromise that enhances the
user experience without fundamentally
compromising the fragility and robustness
of your solution. If you can find the
combination of tools that strikes that balance, youll be ahead of the game. And
for now, we just have to get comfortable
with navigating the continually shifting
waters of the world of Ajax. {end}
Tod Golding is the founder of Blue Puma
Software, a technical consulting company
that provides software training, mentoring,
and development services. He has twenty
years of experience as a software developer,
lead architect, and development manager
for organizations engaged in the delivery
of large-scale commercial and internal
solutions. With an extensive background
leveraging .NET, J2EE, and Windows
DNA technologies, Tod has become
equally skilled with C#, Java, and C++.
He has worked and consulted at a variety
of companies, including Microsoft and
Borland. Tod is the author of Professional
.NET 2.0 Generics and a contributing
author of the XML Programming Bible.

What problems are you facing


when building Ajax-based
solutions? What are some of the
patterns and tools youre leveraging to
build your applications?


Follow the link on the StickyMinds.com


homepage to join the conversation.

Test Connection

Rock, Paper, Scissors


by Michael Bolton
The specification was clear: Use simple
rounding for transactions where the
calculated exchange rate results in a
difference of exactly one-half cent. Yet
for certain values$410.2050, for
instancethe software rounded the result
down to $410.20, instead of up to
$410.21 as I would have expected. I
wrote myself a note. At lunch, I chatted
with Chris, a tester of financial systems.
Rounding down on a half-cent? Look up
significance arithmetic on Wikipedia.com
to get started, he said and grinned.
After lunch, I looked up significance
arithmetic and found the round-toeven rule, also known as bankers
rounding. Banks use it because rounding
up tends to favor one party over another.
The code was probably right, and the
spec was probably wrong. At the next
mornings Scrum, I explained my observation, asked if anyone had heard of
bankers rounding, and received blank
looks. I think the foreign exchange
module uses itcould someone check
that out? Eric, the development lead,
agreed to look. He didnt see anything
unusual in the codeit used a normal
rounding function. Later that day, he
spoke to Dale, a developer in another
group who had worked on the original
module. Oh yes, she said. Visual
Basics round() function uses bankers
rounding. Thats intentional. Look it up
in Microsofts knowledgebase. At the
following days Scrum, our customer
representative agreed to check with our
three largest customers. The day after that,
he confirmed that the software was right.
We updated the functional specifications.
In all my consulting work, Ive never
heard someone say, Were completely
happy with our requirements documents,
and we would do nothing to change
them. I do hear that documents are
incomplete, outdated, self-contradictory,
or just plain wrong. In many of the testing
organizations I visit, people ask for help
in improving their test design, saying that
theyve been relying on requirements
14

BETTER SOFTWARE

DECEMBER 2006

documents, functional specifications, or


use cases as the sole sources of their testing
ideas. At least, thats what they say. In
fact, I observe that they use other
sources of information, too, but not
necessarily consciously.
Skilled testers strive to recognize these
other sources and use them effectively for
test design, because the requirements arent
the same as the requirement documents.
James Bach says that requirements are
a conversation between what we want
and what we can have. He says we
develop our understanding of requirements by considering reference,
inference, and conference. The process
isnt linear; we use references, draw
inferences, and join conferences in no
particular order. At any time, just as in a
game of Rock, Paper, Scissors, an inference
can challenge a reference, which can be
confirmed by a conference and then
overruled by another reference.

Reference
References are things that we can point
todocuments, mock-ups, prototypes,
or models. They may contain tables,
pictures, diagrams, maps, and so on.
References can refer to other references
(This product shall use the protocols
www.StickyMinds.com

identified in RFC 123666) or to other


artifacts (Version 16 of this product
shall perform in a manner substantially
similar to Version 15, except where
specified here).
References may be helpful, but
theyre never perfect. Theyre heuristic
devicesfallible methods for solving a
problemthat represent an attempt by
some person to capture in some medium
some ideas that someone had about
what someones requirements are or
were. Requirements have changed on
every project Ive worked on, while
requirements documents changed later,
if ever.
References are always incomplete to
some degree. A complete reference to a
product would have to describe the
systemeverything germane to the use
of the program in its business context.
Some testers and managers demand a lot
of reference material, perhaps believing
that the testers are inexperienced or
unable to use observation and judgment.
This is insulting to the testers if the belief is
wrong and a serious risk if the belief is right.
Experience, training, and mentorship can
help to address the problem, but thicker
specifications wont go far to make up
for poor testing skills.

Test Connection

Inference

Conference

Skilled testers build on references by


using inferences to refine requirements, aid
test design, choose oracles, and identify
risks. Inferences come from experience,
systems thinking, heuristic models, and
critical reasoning. From experience, we
infer that clicking on a close button will
close a window. Our general models
help us to infer that there will be numerous
users with different goals and temperaments and that there is risk in failing to
fulfill the goals. When we read the
references critically, we can infer that an
author might have left out something
important to a constituency other than
his own or that he might have been
mistaken or misinterpreted. Paradoxically,
inexperience can be helpful; nave inferences can lead to interesting test ideas
since many of the products users may be
nave about it too.
Diagrams present great opportunities
to build inferences about risk. When we
see a diagram, we can certainly pay
attention to what it tells us, but we
should infer that its author is intentionally
leaving out far more information than
the diagram shows. Point at any diagram
and ask, What if the data coming in
here were bad? What would happen if
this connection werent available? What
error checking happens in this process?
What would happen if this component
were replaced by a compatible update?
How many of these transactions can this
unit handle over a given time? What if
we overloaded it?
When we test, we compare the program,
our references, and our inferences. As
we operate, observe, and evaluate the
program, we generate more inferences
that arent discussed in the reference
or that identify possible errors in the
reference. Perhaps since the reference was
produced, some specified requirement is
now insufficient to satisfy the customer. We
may observe that the programs behavior
disagrees with an inference, but then
check the reference and decide to reject the
inference. Maybe the programs behavior
disagrees with the reference. Thats a
bug, assuming that our references and
our inferences agreebut maybe they
dont. So how do we decide whether
theres a bug or not?

We work out the decision in conferences.


Conference is the process of exchanging
and refining understanding about the
system between two or more parties. We
discuss inferences, references, and observations, generally with some person in
authoritya program manager, customer
representative, development manager, or
business manager (some organizations
may combine these roles). Conference is
a conversationa chat face to face, on the
phone, in an instant-messaging system, or
in an email. Like inference, the flow of
conference is typically exploratory; we
learn outside of a predefined formal
structure. Agile processes take extra
advantage of conference by minimizing
written documentation in favor of
working software negotiated with an
onsite customer. That reduces the need
for reference, exploits inferences, and
makes feedback time short.
Unlike a game of Rock, Paper, Scissors,
though, one option ultimately prevails:
conference with the person who matters
most. A reference is simply a stand-in
for some person, and an inference is some
persons conclusion. We may disagree on
what constitutes a bug and whether it
should be fixed, but the game is decided
by the project owners. Thats why
theyre paid the big bucks. {end}
Michael Bolton lives in Toronto and
teaches heuristics and exploratory testing in Canada, the United States, and
other countries as part of James Bachs
Rapid Software Testing course. He is
also program chair for the Toronto
Association of System and Software
Quality. Michael is a regular contributor
to Better Software magazine. Contact
Michael at mb@developsense.com.

How have you used reference,


conference, and inference
to increase your understanding
of requirements?


Follow the link on the StickyMinds.com


homepage to join the conversation.

www.StickyMinds.com

DECEMBER 2006

BETTER SOFTWARE

15

Management Chronicles

In Search of Commitment Clarity


OK, can we all commit to this iteration
plan? Let me see your votes. Hold those
hands high, please, Alan said. Jeff, are
you sure you can commit? Thats quite a
workload youve agreed to take on.
Alan was new to the team, but he was
an old hand at software development
and could tell when someone was overcommitting. As an agile project manager,
however, he knew it wasnt his place to
dictate workloads.
Yes, Im sure, Jeff replied.
Alan looked around the room at the
other team members to see if anyone
would voice a concern that perhaps Jeff
had taken on too much, possibly putting
the team at risk. His eyes met carefully
neutral stares. Alan decided to move
forward and made a mental note to
watch Jeffs progress closely during the
iteration. All right then, congratulations
everyone, he said. Weve just committed
to the iteration!
As the iteration progressed it became
more obvious that Jeff was working long
hours in order to keep his commitments.
About halfway through the iteration,
Alan invited him for coffee to discuss
his concerns.
Hey, Jeff, I know youre busy.
Thank you for taking the time to talk
with me. I wanted to check in with you
to see how youre doing. Ive noticed that
youre working some pretty long hours.
Jeff looked annoyed. Well, yeah,
theres a lot of work I have to finish.
What did you expect?
I expected you to say no to too
much work. Why didnt you? I know
youre excited by the technical challenges,
but you know the work isnt going away
and can be scheduled for future iterations.
Why the push to do so much in one iteration? Alan was genuinely concerned
and wanted to understand what was
driving Jeff to take on so much.
Well never get the product out the
door if I dont push! Jeff said. At least
Linda is happy with my work ethic. She
told me yesterday how much she appreci16

BETTER SOFTWARE

DECEMBER 2006

GETTY IMAGES

by Michele Sliger

ated my efforts! Linda was the product


manager on the team. Besides, werent
you the one teaching us last month to say
Yes, and . . . instead of Yes, but . . .?
And now youre telling me I should say
no, possibly putting our delivery at risk
and making Linda and all our customers
unhappy? Make up your mind, Alan
do you want me to say yes or no? Jeff
scowled, then focused on his cup and
stirred his coffee furiously.
It sounds like youre really frustrated
with me. Im sorry if Ive sent mixed
messages. Id like to try to clarify my
meaning, Alan said and waited for Jeff
to nod before continuing. Saying Yes,
and . . . instead of Yes, but . . . when
dialoging is designed for problem solving.
Its a way to embrace new ideas and
explore them, rather than dismissing
them immediately for all those but
reasons. It keeps the conversations and
brainstorming activities flowing, whereas
Yes, but . . . responses tend to shut
things down. Ive watched team members
practice this in their design discussions,
and it looks like its working really well.
Have you noticed a difference?
Jeff paused and thought before
answering. Yes, everyone does seem
more involved in the discussions now.
Even Vijay is speaking up, and he hardly
www.StickyMinds.com

ever says a word.


Yes, I noticed that too. Im glad
youre all working so well together,
Alan said and smiled. Saying no is
about protecting yourself from overcommitting, and its very important. I
dont want you to say Yes and . . .
when it comes to your personal capacity.
What would that sound like? Can you
work one hundred hours this week?
Yes, and . . . Ill be dead by Friday.
Alan laughed, but Jeff managed only
a weak smile. I would much prefer that
you respond to these requests with No, I
cannot work one hundred hours this week.
I can work thirty hours, Alan said.
But what about our delivery date?
Jeff asked, starting to get upset again.
Well never get in all the features that
Linda wants if I dont work longer hours.
Well never get in all the features
that Linda wants no matter what we
do! Alan laughed again and then grew
serious. I dont want us to miss our
delivery date either. And we can still
make the date, albeit with fewer features.
Linda knows about the importance of
prioritizing her backlog, and she understands that we cant do it all. Did you
ever think that it might be unfair to Linda
and the rest of the team to overcommit
yourself like this?

Management Chronicles

STORY LINES
Consequences of overcommitting
include resentment, burnout, poor
product quality, low morale, high
turnover, and missed delivery dates.
Overcommitting doesnt just put you
in a bind, it puts the rest of the team in
a bind as well. Be fair to your team and
to your stakeholders, and make every
effort to make realistic commitments.
Use the review at the end of the iteration to assess whether or not the
team overcommitted, and be sure to
scale back your commitments for the next
iteration to better reflect reality. This will
allow the team to establish a consistent
pattern of meeting commitments while
working at a sustainable pace.
Revisit the release plan at the end
of each iteration to make sure that any
change in the teams velocity is accounted
for in the overall release plan. Its better
to know sooner rather than later if you
cant complete all the features originally
agreed to.

Unfair? How? Jeff asked.


By overcommitting, youre setting
up yourself and the team. Tasks you
personally commit to but cant find time
for become tasks the rest of the team has
to pick up. Now everyone is overworked
and tired and unable to think clearly.
Mistakes get made, and the team worries
about fixing those mistakes. Eventually
youll have to slow down, whether its
because the team will revolt or because
there are so many bugs that need fixing.
Meanwhile Linda has unrealistic expectations of what we can accomplish,
which she passes along to our customers.
That puts her in an awkward situation
when she realizes that we have a problem.
Dont you think it would be better for
her to know now what we can truly
commit to and deliver?
Youre saying that by personally
overcommitting, Im in effect overcommitting the team, and it will eventually
come back on Linda, Jeff reflected.
Not just on Linda. Its a problem
for all of us. Being realistic about how
much work you can take on will benefit
everyone. To paraphrase Ken Schwaber,
a dead team member is a useless team

member. This time Alan and Jeff both


laughed. Jeff, why dont you mull this
over for a few days and let me know
how I can help.
I can already tell you how you can
help, Jeff replied. We need to revisit
what we committed to for the release. If
Im going to cut back, then weve got to
tell Linda. And from what youve said,
it sounds like letting her know earlier is
best. You know, it would be nice to have
more time with my family.
Thats great to hear, Jeff. Well discuss
this with the team during our review at
the end of the iteration. Ill visit with
Linda now and let her know that this is
on the agenda, and Ill let the team
know about it in our stand-up later
today. Im glad youre willing to revisit
the release plan.
Yes, and Im hoping that Linda will
understand when I say no to too much
work. Heycan I combine a Yes and . . .
with a no like that? Jeff laughed and
took a last sip of his coffee.
Well, Jeff, yes and no.
Alan laughed, and Jeff choked on his
coffee. {end}
Michele Sliger has worked in software
development for more than fifteen
years. She currently works as an agile
coach for Rally Software Development,
training software development teams in
agile methodologies. Michele has served
as a project manager at Qwest Communications, a consultant for Fortune 500
companies, and was a founding member of
the engineering teams at two biotech startups. She is a certified Project Management
Professional and Scrum Master. Michele is
also an adjunct faculty member of the
University of Colorado, where she
teaches software project management to
graduate engineering students.

Why is it so hard to say no?


For those who are able
to say no with ease, share with us
how youve managed to
master this art!


Follow the link on the StickyMinds.com


homepage to join the conversation.

www.StickyMinds.com

DECEMBER 2006

BETTER SOFTWARE

17

Changing
The Hand
Youre Dealt

Better Designs Through


Problem Redefinition

By Payson Hall

18

BETTER SOFTWARE

DECEMBER 2006

www.StickyMinds.com

For many of us, design is the most enjoyable part of software


development. Oh sure, debugging can be fun and it is wonderful
when everything comes together at the end, but if youre like me,
you prefer to spend a little more time up front during design to
minimize the complexity of debugging and maximize the likelihood
that it will all come together.
Design is the all-too-brief period during an applications
evolution when we consider what we want to create and speculate
about how we want to do it but are not yet fully committed to
any particular approach to the problem. A shortcoming of some
of the best programmers I know is the tendency to minimize this
pre-coding thinking time and begin implementing the first
viable solution that occurs to them. The trouble is that there are
several ways to solve most problems, each exhibiting various
levels of efficiency, ease of implementation, maintainability, and
portability. If a designer stops with the first design that
works, there may be a needless sacrifice of quality. In this
rush it is easy to confuse a functional design with a quality
design. The distinction can be subtle, particularly if both are
implemented professionally, because both will get the job
done. The difference in development and maintenance costs,
however, can be remarkable.
Wait! I imagine you thinking as you read this. The
Best is the enemy of the Good. If we worked until we had
the perfect design, we would never accomplish anything!
Wise words, but frequently applied prematurely to software
design. As a profession, software development seems to be in
little danger of overemphasizing design or seeking perfection.
This article focuses on an aspect of the problem definition
portion of the design process using two examplesa parable
and a program fragmentthat illustrate how seemingly small
changes to the problem definition or representation can have
a simplifying effect on the solution.

Redefining the Problem


From the perspective of the system developer, complexity is
the enemy of the development process. There is a limit to the
amount of complexity that any of us can deal with effectively,
and when our capacity is exceeded, system quality is a frequent
casualty. One goal of the skilled designer is to minimize solution
complexity in order to maximize the quality of the resulting
system (by quality I mean a system that can be developed
efficiently; meets its requirements; and is reliable, portable,
and maintainable).
Good designers use a number of techniques to seek simplicity.
One method that may seem counterintuitive is redefining the
problem to be solvedsometimes even adding complexity
to the original problem definitionin order to reduce the
complexity of the solution.

A Puzzling Parable
I was first exposed to the problem redefinition strategy in
a math puzzle. A shepherd died and was survived by three
sons and twenty-three sheep. In his will, the shepherd left half
of the sheep to the eldest child, one-third to the middle child,
and one-eighth to the youngest child. Since the sheep were to
be used for their wool, the sons werent thrilled with the notion
of cutting up sheep to account for fractions. As they stood by
the road arguing about how the division should occur, a wise
woman came along, leading a sheep of her own to market.
When the problem was explained to her, she considered it for
a moment, and then praised the boys for not being too quick
to butcher the sheep, which she said was not really necessary.
They looked at her curiously, and she said, Let me lend you
this lamb as a tribute to my friendship with your father. She
then led her lamb into the herd. Now the division should be
simpler. The eldest child smiled as he took away half
(twelve) of the sheep to begin his herd. The middle child
breathed a sigh of relief as he took one-third (eight) of the
sheep from the pen and led them home to his farm. The
youngest child watched as the old woman led her lamb from
the pen and continued down the road toward the market,
leaving him with one-eighth (three) of the herd.
Too often during the design process we find ourselves
worrying about the complex implementation of messy details
(like dividing live sheep), without first seeking ways to minimize
complexity by redefining the problem. Subtle changes to the
problem being solved can have surprising benefits in terms
of simplification.

A Solitary Programming Example


Solitaire is the name given to a family of card games that are
played by a single player. I enjoy solitaire, and I have always
wondered which strategies of play are the most effective. I once
designed and built a simulation program to play a solitaire game
called Klondike, probably the most widely played variant of
solitaire (see the sidebar for game rules and visit the StickyNotes
to see the simulation program). I wanted to observe the effects
of different strategies over a large number of games. During my
initial thinking about the design, I was dismayed by the number
of special cases that seemed to exist when I tried to describe in
algorithmic terms how to play the game. The initial placement

www.StickyMinds.com

DECEMBER 2006

BETTER SOFTWARE

19

I asked myself, Is there a way to avoid the special test for


aces? (step 1 in the algorithm previously described). I observed
that the reason aces were a special case is that they comprised the foundation of the suit row and, unlike all

other cards in the deck, had no ordinal predecessors.

This meant that they could not be placed according to

step 2. Until the aces were placed, no deuces would pass


X.0 If the face-up pile is exhausted
X.1
If there are face-down cards
the test in step 2 either. If only there were a zero of
turn one face up
hearts, I thought. Then aces would no longer be a
X.2
Else (no face-down cards)
/*Special Case*/
special case. Eureka! I imagined placing zeros of
a king can go here
hearts, diamonds, clubs, and spades on the table as

placeholders for the suit row at the start of each game.

Now step 1 was no longer necessary, and aces could be

placed according to the rules already defined in step 2.


The problem definition was changed slightly (solitaire
is
not
normally
played with a fifty-six card deck that includes
The possibility that the table might be left bare requires yet
zeros of hearts, diamonds, clubs, and spades), but the underanother special case in the card playing logic (the second
lying problem (i.e., accurately simulate a game of Klondike)
special case below):
was not changed, and the solution was simpler. All I
had to do was add four cards to my fifty-two card
1
If value of card_to_play = ace
/*Special Case*/
deck, which would be nailed to the table during
move to suit row for score
initialization and not affect play in any substantive
2
Elseif value of card_to_play = (top card in its suit row) + 1
move to suit row for score
way. Once the special case of the aces was solved, the
3
Else
kings were just a step away.
Do for each face-up pile (until placed)
The king boundary problem also arose because
3.1
If value of card_to_play = king /*Special Case*/
kings do not have predecessors (actually ordinal
andif (face-up pile exhausted)
successors; remember that you count down from high to
start a new face-up pile with the king
low when playing cards on the board). Kings could only
3.2
If color of card_to_play is red
be moved to the board when the face-up and face-down
andif (value of top face-up card) = card + 1
piles were exhausted, exposing the bare table below.
andif (color of top face-up card) = black
Having already overcome the conceptual hurdle of
move card_to_play to face-up pile
inventing cards and adding them to the deck, I imagined
3.3
If color of card_to_play is black
a card larger than a king (an emperor?) that I could
andif (value of top face-up card) = card + 1
andif (color of top face-up card) = red
place on the table to attract kings when the face-up and
move card_to_play to face-up pile
face-down piles had been exhausted (currently handled
End do
by step 3.1). This would allow me to eliminate step 3.1
4
If not played by an earlier step
altogether, since, if kings were playable, they would be
card_to_play is not playable (place in discard pile)
played during step 3.2 or 3.3. The trouble was that
steps 3.2 and 3.3 required that the emperors be both
black and red if any king were to go on any bare table space.
I didnt like it. It was too messy, and it violated one of the great
I realized that I was being too literal about representing the
truths of system design: Nature abhors the special case.
deck of cardsassuming that it could only contain two
colors, red and black. If I allowed a third color (green), then I
could make my emperors that color and combine steps 3.2
Changing the Problem to Eliminate
and 3.3 into a single step:
the Special Cases
of aces is a special case, as is some of the logic required to handle
depleting one of the seven face-up piles on the board:

I set out to see if I could factor out the special cases to


simplify my task. I realized that kings and aces were special
cases because they were boundary conditions. It is common to
have special cases at the boundaries of a problem; the question
is Can the boundary be moved
or removed?
The special case
of the aces was
the first to be
simplified.
20

BETTER SOFTWARE

DECEMBER 2006

www.StickyMinds.com

If (value of top face-up card) = card_to_play + 1


andif (color of top face-up card) card_to_play
move card_to_play to face-up pile

All I needed to do was add a green emperor face down at


the bottom of each face-down stack during initialization, and
the rules became simpler still.
I assigned all of the emperors a suit of circles. Emperors
were now the boundary condition, but they could never be

Klondike Rules
In Klondike, a regular deck of fifty-two cards is used. To start the game,
seven face-down piles of cards are dealt in a row to form the board. The first
pile of the board contains one card, the second has two cards, the third has
three, and so on. The top card of each board pile is turned face up and placed
on top of the remaining cards in that pile. The rest of the deck comprises
the stock.
The goal of the game is to maximize the number of points scored during play
by making a series of legal moves (described below) between piles of cards.
Whenever an ace is revealed during play, it is placed in a separate pile in a
suit row above the board. On the aces you may build an ascending sequence
of cards of similar suit (e.g., on the ace of spades you may place the two of
spades, followed by the three). The cards placed on the aces may be moved
individually from the top of the face-up piles of the board or from the discard
pile. A point is scored for each card played on the suit piles. To win the game
and achieve a perfect score, all four aces must be placed in the suit row and
the ascending sequence must be built completely to the king of each suit (a
total of fifty-two points). Once a card has been placed on a suit pile, it may not
be moved for the rest of the game.
To play the game, the cards are dealt onto the board and the player makes
legal moves of cards between the piles. On the face-up piles of the board you
may place a card of alternate color that occurs next in descending sequence
(e.g., if the top face-up card of a pile is a black nine [clubs or spades] then a
red eight [hearts or diamonds] can be placed on that pile). Cards placed on top
of the face-up pile may be the card or cards comprising another face-up pile or
a card from the discard pile. When one face-up pile is moved to another, all of
the face up cards in the original pile must be moved as a group. The highest
value card (the bottom) of the face-up group being moved must be legally
playable on top of the receiving pile. When the face-up cards are removed from
a pile, it may reveal a pile of face-down cards (if the face-down pile has not
been exhausted), and a face-down card may be turned face up on that pile to
replenish the face-up pile. When a pile is completely exhausted, the vacant
place on the table is eligible to receive any king that is on the board or is
revealed later during play. If a king is not immediately available, play continues,
leaving the vacant place on the table unused until the game ends or a king
becomes available.
Cards from the stock are turned face up one at a time and placed on a
separate discard pile. The top card in the discard pile may then be played onto
any of the other piles (either the board or the suit row) at any time. Once the
top card from the discard pile has been played, any legal moves created by the
play may be taken. When a card is played from the discard pile, the top card
remaining in the discard pile may then be played. When the stock has been
exhausted and no legal moves remain, the game is over.

moved (there was no card bigger that would cause them to


relocate on the board, and there was no king of circles
to attract them to the suit row). This meant that the test in
step X.1 was no longer necessary; if the face-up pile was
exhausted, then there had to be a face-down card until you
turned up the emperor, and once you turned up the emperor it
could not be moved to exhaust the stack. This also eliminated
the special case for king processing described in step X.2,
because once the emperor in a face-down pile was exposed it
would attract kings according to the modified rule 3
described previously. All that remained was an administrative
detail: It was necessary to create a zero of circles to avoid
adding complexity into step 2 when testing whether cards in
face-up piles were playable.
The end result of adding these twelve additional cards (five
zeroes and seven emperors) to the deck was a minor change to

the dealing (initialization) routine and a tremendous reduction


in the complexity of play, without altering the real game in
any way.
The simplified rules of play were:
X

1
2
3

When a face-up pile is exhausted


turn a face-down card face up

/* step eliminated */
If value of card_to_play = (top card in its suit pile) + 1
move to its suit pile for score
Else
Do for each face-up pile (until placed)
If (value of top face-up card) = card_to_play + 1
andif (color of top face-up card) card_to_play
move card_to_play to face-up pile
End do
If not played by an earlier step
card_to_play is not playable (place in discard pile)

By changing aspects of the problem I reduced the complexity


of the solution without sacrificing functionality or changing the
underlying system behavior. Eliminating the special cases
increased both the simplicity and quality of the solution.
Identifying and avoiding needless complexity is part of
building quality systems. Changing the definition or internal
representation of a problem may significantly reduce solution
complexity, but the analysis consumes time and resources. Is
the investment worthwhile?
A designer or project manager with limited resources and
an aggressive schedule might reasonably question the benefit
of searching beyond the first good enough solution
identified, but finding a simpler solution can be extremely
valuable. Simpler solutions are usually less expensive and
time consuming to build, less error prone, easier to test, easier
to maintain, and easier to modify. When design simplification
results in efficient, simpler, and smaller programs, real
productivity is improved. {end}
Payson Hall (payson@catalysisgroup.com) is a consulting
systems engineer and project manager from Catalysis Group,
Inc. in Sacramento, CA. Formally trained as a software
engineer, Payson has performed and consulted on a variety of
hardware and software systems integration projects in both
the public and private sectors throughout North America and
Europe during his twenty-six-year professional career. He is a
regular columnist on StickyMinds.com.

Sticky
Notes
For more on the following topic, go to
www.StickyMinds.com/bettersoftware.


Klondike simulation program

www.StickyMinds.com

DECEMBER 2006

BETTER SOFTWARE

21

When it comes to teamwork, the United States Marine Corps (USMC) epitomizes the concept. The
USMC is the most elite fighting force in the worldand with good reason. Teamwork is a key
ingredient to accomplishing a mission, and its something marines do very well. After all, theyve
been doing it for over 230 years. Though many other traits and principles make the USMC more
successful than any other branch of service in the world, teamwork is the glue that holds it all together.
Much of what I learned while serving
as a sergeant in the USMC has helped
me build and manage test teams more
effectively. Whether I am working with
permanent test teams or quickly assembled
SWAT teams to deal with a project
emergency, many of the basic USMC
principles and concepts apply.
In his book Systematic Software
Testing, Rick Craig (a retired USMC
colonel) writes about USMC leadership
principles, and David Freemans book
Corps Business describes how Marine
22

BETTER SOFTWARE

DECEMBER 2006

Corps principles can be applied in the


world of business. Though Freemans
book is not about testing, it helped me
understand the approach that I had subconsciously taken with my test teams. I
recognized many of the principles Craig
and Freeman discuss because I had
learned the same principles in the
USMC and naturally applied them in
my own work.
If some of the principles listed below
seem like common sense (an uncommon
thing in some organizations), there is a
www.StickyMinds.com

good chance that you already practice


them, and you probably have an effective
test team. In my experience, test managers
who apply even some of these principles
have better, more effective test teams
with higher morale than those who do not.
However, it has also been my experience
that many test managers do not apply
these principles and have difficulties
with their teams.

The 70 Percent Rule


For marines as well as testers, the 70

P r i n c i p l e s f o r B u i l d i n g
S t r o n g T e s t T e a m s
By Sean Buck

percent rule is simple yet effective.


There is no magic or scientific reasoning
to the number 70. It is a symbol representing that there is a time when you
have enough information to execute a
good, effective plan without waiting for
100 percent of the informationwhich
you may never receive. The essence of
this rule is to increase speed and avoid
analysis paralysis. It states that a wellthought-out plan executed now is better
than the perfect plan executed too late.
You will never have all of the information
youd like, so work with what you have
now and adjust later if necessary. This
applies to all aspects of testing, from
high-level planning and management to
individual tests.
Has anyone ever said to you, I cant
write my test cases because I dont have
all the requirements yet? Share the 70

percent rule with your team, and start


living by it. Take the initiativeget
things started as the information begins
to arrive. When additional information
becomes available, adapt and overcome.
Note that successful implementation of
the 70 percent rule is dependent on the
key principle of Rewarding Failure,
which Ill discuss later. Fear of failure and
of retribution for failure will paralyze a
team into waiting for all of the informationinformation that will never arrive.

Build a Common Ground


There are many sayings in the Marine
Corps (some not printable here), including
Every marine is a basic rifleman. All
marines first are trained to be infantrymen
and then move on to specialized training.
Whether a supply clerk, radio operator,
computer technician, or cook, any marine
www.StickyMinds.com

can pick up a rifle and lead a squad into


battle if required. This shared experience
helps build a basic camaraderie and
pride among all marines.
How can you apply this to your
organization? Do you have teams where
developers, business systems analysts,
users, and testers all collaborate on testing
your software? Have them train together
in a foundation testing class. It will help
them see the bigger picture of testing.
A common understanding minimizes
misunderstanding, resentment, and that
its not my job attitude.
Do you have a test team with specialized rolestest managers, test designers,
automation experts, performance
testers, security analysts? Send everyone
to the same foundation class. This shared
experience will build a common identity
among your team, increase camaraderie

DECEMBER 2006

BETTER SOFTWARE

23

In the USMC, all great leaders get


input from their teams to get them
involved and foster commitment, but
ultimately the leader is responsible
for the decision.

The USMC is an organization with


diverse missions. Marines are deployed
all over the worldbut not just to fight.
They stabilize chaotic situations, provide
humanitarian assistance, maintain security
during the Super Bowl, and provide joy
to many children with the Toys for Tots
program during the holidays. This is the
essence of training for capability.
Marines are trained to adapt to any
mission, not just certain threats.
Marines are capable of forming a
Marine Air Ground Task Force
(MAGTAF) when needed. These can be
thought of as temporary SWAT teams,
formed to accomplish the mission at
hand, comprising marines from different
organizations who may or may not have
worked together before. This works
because of the capable men and women
that make up the MAGTAF. Imagine
what would happen if a large organization had a pool of capable testers who
could be quickly assembled to respond
to high-priority projects.
How do you train for capability?
First, you must establish the common
skills and experience mentioned earlier.
From there, you build up testers skills.
Often, I have seen testers focus too
much on trying to become subject matter
experts of the applications they are testing.
Though there are benefits to learning
the business rules, there is no need for a

tester to become as expert as the business


professionals. Rather, we must focus on
developing the testers ability to test.
Test techniques can be applied to any
system, and testers can rely on the subject
matter experts when they have questions
about the business.
I have experienced this firsthand in a
large organization that develops well
over one hundred internal applications
with an IT staff of approximately 1,500.
I have placed my testing team in many
different environments and applied the
same basic principles to testing on
different applications. We learned a bit
about the business through the testing
process, but we did not require any prior
knowledge about the business in order
to add value and provide effective
testing services.
In addition to learning formal testing
techniques, I recommend increasing
testers exploratory skills. Many testers
inherently do this kind of testing. We
call it trying to break the system. I
highly recommend learning more about
James Bachs approach to exploratory
testing (see the StickyNotes for a link to
his Web site). What I like best about
James approach to testing is his focus
on improving testing skills and utilizing
the best tool of allthe human brain
to test more efficiently and effectively.
With increased skills, testers are
trained for capability. They can be
placed on any projectno matter what
the programming language, architecture,
business logic, etc.and immediately
contribute. This is very different from
training your testers on a specific application and having them become experts
or super-users on that application. They
would not be trained for capability, and
their specialization could make it difficult
for them to move constructively from
project to project.

24

www.StickyMinds.com

and morale, and improve skills.


Feeling creative? Start cross-training
your department. Try giving your testers
basic classes in programming and
systems analysis, and send non-testers
to testing classes. This will further
reduce misunderstandings as team
members gain an appreciation of the
other roles and responsibilities.

Train for Capability


(MAGTAF Concept)

BETTER SOFTWARE

DECEMBER 2006

Decentralize Decision Making


Once you have established the
common ground among your test team
and have trained them for capability,
you need to trust and empower them.
Micromanagement is not only annoying
but also harmful in testing because it
stifles creativity. Give your testers the
end objective and allow them to make
the right decisions to accomplish their
mission. Marines call this managing by
end state.
As a sergeant, I was often responsible
for many different details (projects). For
any given mission, I would tell my
marines the objective and end state;
then I would rely on them to use their
training, decision-making skills, capability,
and creativity to get the job done. It is
amazing how much respect you receive
from your team members when you
treat them with respect and trust them to
make the right decisions to accomplish
the work. People love challenges. Being
presented a problem without a solution
is much more challenging than being
presented a problem with the exact
steps needed to solve it. Additionally, by
observing your team members and
how they choose a solution, you may
learn useful information about their
current capabilities and where they need
to improve.
This concept makes marines extremely effective. Troops do not passively hide
from the enemy while waiting for the
general to radio the orders. The marines
under fire are the people closest to the
problem. They can assess the real-time
information of the situation and make the
best decision to achieve the end objective.
I use this concept in test automation. I
first establish a baseline of background
information about the project and the
problem we are trying to solve. I tell my
senior automation engineer that I need an

automation framework that the development team can easily manage and that is
robust enough to handle maintenance
issues, then I explain any constraints. (In
one particular instance we were limited
to the automation tool we had in house
and the timeframe in which we needed to
complete the project.) I let him propose
the solution. If that solution meets the end
objective and addresses all constraints,
then we move forward. As questions or
problems arise, I am happy to help, but I
always ask for the teams solution before
I present my ideas.
This concept works only when you
have two key ingredients. First and foremost, you have capable people you can
trust. Capability ensures a better chance
of making a good decision. Second, you
have a clearly stated end objective. Even
capable testers can make wrong decisions
if they are unsure of the desired outcome
of the assignment.

Reward Failure
It hurts me when I see people disciplined for failure. They may have done
their best, but managements focus is on
the negative aspects of the failure and
discipline follows. In the USMC, we
were often pushed to failure. We were
purposely given impossible assignments
we would fail. The purpose for this was
to push us to the very edge of our
capabilitiesto discover our limits.
People involved in weightlifting or
strength training understand the concept
clearly. One exercises with a weight until
the muscle is completely exhausted. The
muscle can lift no more, and muscle
fibers are actually torn in the process. A
time of healing is required for the fibers
to repair. But, the next time the muscle
is worked, the muscle is stronger, and the
point of failure is further than it was
the last time.
The brain can be exercised in much
the same wayto the point of failure. If
you know a marine (or if you are one
yourself), you know that a marine is up to
any challenge. This is because a marine is
not afraid of failure. Failure is not the
end of the world. To marines, failure
means that they gave their all and
learned something about themselves in
the process.

If you want to maximize the talents


of your team, then you need to reward
failure. Your team members need to
know that you recognize their hard
work and that you know they are pushing
themselves. Without that support, you
may encourage your team to do the safe
thing because they fear failure.
Rewarding failure is not the same as
rewarding someone for failing to show
up to work on time. That is a different
kind of failure and needs correction.
The failure that needs support and
recognition is the failure that nurtures
growth. Assign your teams to projects
outside their comfort zones. Assign the
creation of a master test plan or an
automation assignment to those who
have never done that before. Reward
them for doing a good job of pushing
their limits. Use failure to identify new
skills to be mastered. Send the message
that they are free to go out of their comfort
zone and try things without fear of
reprimand for failure. Then show them
how to overcome the failure, so they
can learn from that experience.

Leadership by Example
I saved the most important principle
for last. Leadership by example is something I truly believe in. As the leader,
you establish the success of the team by
living, breathing, and doing everything
you want the team to do. Not only will
your teammates emulate your behavior
the behavior you wantbut you will
also gain their respect. If you are the
first one there in the morning and
the last one to leave at night, your team
knows you are serious about what you do.
If you lead by setting the example, it
is easier to counsel those with behaviors
that need correction. How can you tell
someone to stop showing up late when
you yourself are late? How motivated
will team members be if you make them
work overtime, but you leave early?
Your team notices how you act and will
learn from your actions. Though the
example focuses on punctuality, this
concept applies to all behaviors and
attributes of the job. This is especially
true in the area of knowledge. How can
you mentor and bring up your testers
skills if you yourself are not continuously
www.StickyMinds.com

trying to improve your own skills?


An important part of this principle
and basic leadershipis to make sure
you are communicating clearly and being
a leader. Those who work for you look
for you to be a leader and to act like
one. When it is time to make decisions,
gather input but do not hesitate. Make
the decision. Indecisiveness will make your
team uneasy, because an important part
of being a leader is being decisive and
calling the shots. Some managers feel
it is better to have a democracy and let
everyone vote, but this is not always the
best approach. In the USMC, all great
leaders get input from their teams to get
them involved and foster commitment,
but ultimately the leader is responsible
for the decision.

Conclusion
As our culture focuses more on individual superstars, Ive noticed that
organizations are losing focus on the
team concept. Much of a teams success
depends on having a leader who can
take a group of individuals and mold
them into a high-performance team. Take
charge of your team. Increase your
success by building a common ground,
training for capability, managing by end
state, rewarding failure, and, most
importantly, setting the example with
your own actions. {end}
Sean Buck is the team manager of
the SDLC team in the process methodology and training department at the
Capital Group Companies Inc.
(www.capgroup.com). The SDLC team
helps improve the internal systems
development processes by coaching,
mentoring, and consulting. Sean is a
former member of the United States
Marine Corps and has been leading
teams for more than a decade using
USMC principles. Email Sean at
swb@capgroup.com.

Sticky
Notes
For more on the following topic, go to
www.StickyMinds.com/bettersoftware.


James Bachs Web site

DECEMBER 2006

BETTER SOFTWARE

25

26

BETTER SOFTWARE

DECEMBER 2006

www.StickyMinds.com

I s T h e re a n
Assessment
in the House?
Diagnosing Test Process
Ailments In House
By Ruud Teunissen

You cant put your finger on it, but


youre just not feeling well. Its
time to go to the doctor for a
checkup. First, the staff records
your height, weight, blood pressure, heart rate, and respiration
rate. Later, the doctor analyzes
the data gathered by the staff and
compares it to standard norms.
The doctor interviews you about
your symptoms and prescribes
some form of treatment.
Many of us have experienced
this same scenario with our testing
processits just not working as
well as wed like, but we cant
quite determine why. So, what
should we do? Maybe its time for a
checkup. We call these checkups
test process assessments, and
they are a formal examination of
an organizations testing process.

www.StickyMinds.com

DECEMBER 2006

BETTER SOFTWARE

27

The Test Process


Assessment
Organizations perform test process
assessments for a number of reasons:
Because the current testing process is
undefined, chaotic, and dependent
on a few heroes to accomplish
the work
To compare themselves against
effective industry practices (also
known as benchmarking)
To understand their testing capabilities after a reorganization, merger,
or management change
In response to concerns about increased testing times, rising expenses,
complaints from customers and users,
or a major product disaster
As part of a higher-level software
process improvement initiative such
as CMM
To take a proactive rather than reactive position regarding process change
To meet the requirements of an
external regulatory body
Its important to understand the
trigger for the assessment because it
often indicates the importance given to
the assessment and its future impact on
the organizationand you.
The first step in performing an assessment is to select an approach to follow.
One approach is to research, evaluate,
and document effective testing practices
before you begin. Another is to use an
established model such as Test Process
Improvement (TPI) or Testing Maturity
Model (TMM) as the reference point for
your assessment (see the StickyNotes
for more information).
If you choose to use a model, assess
your organizations practices against the
model. You may discover that you are
using very mature processes in some areas
but very immature processes in others.
Dont worry, this is usually the case.
And thats why you are performing an
assessmentyou want to understand
the strengths and weaknesses of your
28

BETTER SOFTWARE

DECEMBER 2006

testing capabilities.
It is also important to define the
scope. Will you assess all projects or
a subset? Will you assess all testing
levels (unit, integration, system, acceptance, performance, security, usability,
etc.) or a subset? Will you assess
the testing only on new development
projects or will you include application
maintenance work? And what about
testing on development work youve
outsourced?
Some organizations stop after the
assessment. They may decide their testing
processes are good enough. Other oganizations realize the need for improvement
but do nothing; after the assessment is
completed, its ho hum and business
as usual resumes. But for some organizations, the assessment is just the beginning
of a substantial program of continuous
process improvement initiatives.
The ultimate impact of the test
process assessment is often directly related
to the level of management support for
it. If executive management initiates the
assessment, the impact is strong, and
more recommendations are typically implemented, even within areas that are
not directly related to the testing
process. If test management initiates the
assessment, the impact usually is limited
to the testing process itself.

Performing an In-House
Assessment
Performing an assessment in house has
substantial benefits. First of all, its less
expensive than hiring outside consultants.
Second, an in-house assessment team
knows your organization, its people, its
processes, and its habits in substantially
more detail than an outsider could
learn during the relatively short assessment period. Your process improvement
suggestions might be more realistic,
better tuned to your situation, and
more achievable.
But in-house assessments have drawbacks as well. First, you are part of the
process that is being assessed and might
be biased. If youre a tester, you may not
be popular with members of other
disciplines, so they wont tell you their
weak spots. After all, soon you may be the
enemy again and might use anything
www.StickyMinds.com

they said against them. The most common drawback is the perception that
your findings and recommendations
no matter how well reasoned and well
presenteddo not have the clout that
an outside assessor brings.
Here are some tips for leading a
successful in-house assessment:
Define why you are performing
the assessment and what you hope
to accomplish. Is the assessment to
compare yourself against the model
or against other organizations in
your field, or will it become the basis
of process improvement activities?
Choose and use a formal test
process assessment model. Make
sure you know it well before you use
it. Use it to make sure your
assessment is objective and
your conclusions are legitimate.
Create several questionnaires from
the model, tuned to the interviewees,
to guide your interviews so you
dont forget major topics of interest.
Familiarize yourself with all parts
of your organization and how it
really tests software. Gather and
analyze documents that describe
the current processes. Look for
discrepancies between the way you
claim to do things (process definition documents) and what you
really do (project documents).
Make sure you choose a representative sample of people to interview. Its easier to interview your
friends, coworkers, and people
nearby, but they may not be the
best sources of information.
Dont just interview testers. Testing
is near the end of the software
development pipeline. Decisions
made in project management and
development significantly impact
testers, so be sure to include people
from these areas in your interviews.
If you must interview several people
together, make sure they are peers.
Otherwise, youre bound to get the

right answerwhat the manager


wants saidinstead of the truth.

the details later, and your notes will


be vital.

Adjust the schedule to accommodate


new sources of information. During
the interviews youll find people
always suggest some document to
read or some colleague to interview
who is not on your list. If possible,
obtain the document or add this
person to your interview schedule.
This is not a sign that you were not
diligent in your interviewee selection;
it just means you are asking the
right questions.

Dont become enamored with certain


people. They may be handsome or
beautiful or powerful or famous
or charismatic, but that doesnt mean
they know what theyre talking about.

Conduct interviews in your


interviewees offices. People feel more
comfortable on their home turf and
may be more open to your questions.

Stop regularly to evaluate what


youve learned and what is still
unknown. Use that knowledge to
guide your next interviews.

Be an effective listener. You may be


more of an expert in an area than
the person you are interviewing,
but dont jump to conclusions.
Dont fill in the blanks or use
your words rather than theirs. Its
crucial not to interpretjust listen,
learn, and record.

Present your findings to all who


contributed to the assessment.

Ask your interviewees what problems exist in the software testing


process and how they think those
problems could be solved. Most
professional counselors believe that
the majority of their clients not
only know what their problems are
but also know the solutions to
those problems. But, for some
reason, they are not able either
to see their problems or to create
effective solutions. In your interviews, take the same approach.
You will discover a wealth of
information.
Keep confidences. You may hear
some interesting things during your
interviews. Dont attach names to
negative comments. Remember, you
are trying to gather information, not
set people up for punishment later.
Take detailed notes even if youre
getting the answers you expected.
You wont be able to remember all

Work with a partner. While you are


asking the questions, he records the
answers. After a while, switch roles.
Ive always found my partner notices
things I miss and asks questions I
tend to forget.

The most common


drawback is the
perception that
your findings and
recommendations
no matter how
well reasoned and
well presented
do not have the
clout that an
outside assessor
brings.

Tell the truth. As testers, the only


lasting power we have is our integrity.
Dont do anything to damage yours.
Once the assessment is finished, the
difficult work beginschoosing the areas
of test process improvement that are
most important to your organization,
developing implementation plans, and
changing your organization. Once you
start proposing changes, youll be
amazed at the resistance youll encounter,
even from those who supported change
during the assessment process.
It is helpful to translate the proposed
test-process improvement activities,
which often are of a technical nature,
into concrete steps with tangible benefits
for those who are outside the testing arena.
The following is a list of benefits that
other organizations have achieved
through assessing their testing processes
and making improvements. You might
aim for these kinds of benefits in
your organization:
Implementing a more efficient and
mature test process achieved a 20
percent reduction in infrastructure
costs by reducing not only the
required number of licenses for
software and tools but also the
number of support requests.
www.StickyMinds.com

DECEMBER 2006

BETTER SOFTWARE

29

Implementing a risk-based testing


approach as well as a set of informal
and formal test design techniques
led to a 50 percent reduction of
incidents in production caused by
inaccurate testing.
Involving testers earlier in the
software development process by implementing a testability review led to
earlier detection of defects in the requirements, thereby preventing those
defects from showing up in the code.
Standardizing the test process
throughout the organization led to a
higher level of reuse of test cases and
test scripts. This resulted in the
successful implementation of test
automation for the first time in four
years and yielded a 40 percent
reduction in test costs.
Creating job descriptions for
test engineer, test team lead, test
manager, and test environment
engineer, including tasks, responsi-

30

BETTER SOFTWARE

DECEMBER 2006

bilities, salary scales, and training


possibilities, led to lower turnover
in the test team. It indicated that
the organization viewed testing as
a profession, just like software
development. In addition, less
effort was spent on training
replacement testers.
Youll find it most effective to implement process changes through a formal
project with a project manager,
resources, schedule, and budget rather
than piling this work onto the shoulders
of already overworked testers. Also
keep in mind that, although you may be
the expert in testing, this does not
necessarily mean that you are an expert
in implementing change. So, be sure to
find and use that expertise.
Its unfortunate, but some people in
your current organization will not want
to work under the new and improved
processes and will resist the changes. I
have even seen cases where employees
actively worked to sabotage the new
processes. Futurist Joel Barker wrote,

www.StickyMinds.com

When the paradigm changes, everyone


is reset to zero. Be prepared to deal
with that situation.
Remember that change is difficult and
takes time. When budgets and schedules
get tight, test process improvement
activities can be the first things to be
jettisoned. Continue to communicate the
future benefits to management, developers,
and testers to keep the momentum going.
And always celebrate your successes, no
matter how small! {end}
Ruud Teunissen is co-author of
Software TestingA Guide to the
TMap Approach and is a frequent
speaker at national and international
conferences and workshops. Ruud
is currently an international test
consultant at Polteq IT Services BV.

Sticky
Notes
For more on the following topic, go to
www.StickyMinds.com/bettersoftware.


More information on TPI and TMM

Career Development

The Scoop on
Employment Trends
in 2006
The Better Software Magazine/StickyMinds.com
Salary Survey
With all of the glitches, security breaches, mergers, lawsuits, product launches
(and delayed launches), its been an eventful year for the software engineering
industry. But our top story is how you fared in the workplace in 2006. Hundreds
of Better Software magazine readers and StickyMinds.com users logged on and
gave us the scoop on the industrys employment outlook. Find out the who, what,
when, where, why, and how of your software engineering peers!
Who?
Hello, Wisconsin! (and South Africa)

Ladies and Gentlemen

Breaking news its not, but software engineers are a worldly


bunch. Most of our readers hail from the United States, but
weve got a presence that spans the globe.

Its safe to say were Even Steven. The industry is almost


equally divided between men and women.

80
70
60
50
40
30
20
10
0

32

BETTER SOFTWARE

DECEMBER 2006

www.StickyMinds.com

Career Development

What?
Job-function Junction
Where do you fit in? Are you a QA manager working in
healthcare or a development director for a commercial
software firm? Maybe youre the entry-level IT guy at the
local power company?

Computer science
is the most popular field
of study at 29%.

50

25

40

20

30

15

20

10

10

When?
Trailblazer or Homesteader?
Do you mosey from job to job in search of greener pastures
or do you stake a claim at a company and stick around until
the cows come home?

Youre not getting older,


youre getting better!
18.5% of respondents
are between 31 and 50
years old.

www.StickyMinds.com

DECEMBER 2006

BETTER SOFTWARE

33

Career Development

Where?

Why?

Keep Your Hands Where I Can See Them

Nose, Meet Grindstone

Maybe you cant resist the aroma of the salami sandwich


from the cube next door or your boss has to have his daily
high five, either way telecommuting and distributed teams are
not bandwagons most of you have jumped on.

What gets you out of bed in the morning and off to the office
with a spring in your step? Are you all about the moolah, or
does a flexible work schedule keep you coming back for more?

35
30
25
20
15
10
5
0
Less Than
$30K

$30K $50K

$51K $70K

$71K $90K

More Than
$90K

100
80
60
40
20
0
Respondents could select more than one answer

60
50

More than half of


respondents hold a
bachelors degree, while
less than 1% have
earned a PhD.

34

BETTER SOFTWARE

DECEMBER 2006

www.StickyMinds.com

40
30
20
10
0
Respondents could select more than one answer

Career Development

How?
Feeling Outnumbered?
It might not be as bad as you think. Our survey shows youve
got a lot of support.

50
40
30
20
10
0

40
35
30
25
20
15
10
5

www.StickyMinds.com

DECEMBER 2006

BETTER SOFTWARE

35

Product Announcements
Borland Lifecycle Quality
Management solution
CUPERTINO, CABorland Software
Corporation has unveiled the Borland
Lifecycle Quality Management (LQM)
solution, an integrated ALM product
suite that links business requirements,
code, testing priorities, and activities in
an automated and traceable way.
Borlands LQM solution specifically
helps to align and support the following
processes:
Requirements definition and management
Test management and execution
Architecture and design analysis
Development test and defect prevention
Automated functional testing
Performance and scalability testing
Defect tracking and version control
For additional information, visit
www.borland.com/us/solutions/lifecycle_
quality_management.

Seapine TestTrack TCM and


Surround SCM 5

Worksoft Certify 7.1


PHOENIX, AZWorksoft Certify 7.1
is the next-generation of Worksofts
enterprise-class automated softwaretesting solution.
Worksoft Certify 7.1 reduces the time
and cost of software-test automation by
60 percent or more as compared to
scripting tools and delivers additional
functionality, including:
Management reporting
Enhanced test data security
Automated test scheduling
Third-party integration
For more detailed information, visit
www.worksoft.com.

AccuRev 4.5
LEXINGTON, MAAccuRev 4.5 is
designed to be at the core of a multivendor
application lifecycle management
(ALM) process through its enhanced
AccuBridge SDK, combining process
and issue-based SCM with leading IDEs
and third-party lifecycle tools.

New cross-stream links, cross-platform


symbolic links, and workflow additions
to change packages allow development
teams to organize monolithic software
architectures into independently versioned
components and conduct componentbased development in parallel with ease
of administration.
For additional information, visit
www.accurev.com/accurev.html.

PSS Robot
MINNEAPOLIS, MNProductive
Software Systems Inc. (PSS) has developed
a tool to help analyze the impact of
change before it is made. With Robot,
finding, analyzing, and seeing the context
of how source code is used allows you to
judge the impact of change, with search
results given in full view and the option
to immediately edit code with your
favorite editor.
PSS offers a free 30-day demo on
Robot and its capabilities. For more
information, call (866) 417-8300 or visit
www.prodsoft.com.

BOSTON, MASeapine Software


has introduced TestTrack TCM, a
cross-platform client/server solution,
and Surround SCM 5. Test Track TCM
manages facets of the testing process,
including test case creation, scheduling,
execution, measurement, and reporting.
Surround SCM 5 combines user-definable
workflows, custom meta-data, and
in-application programmable triggers to
automate change processes and enforce
change policies.
Surround SCM 5s custom meta-data
lets developers track any type of
additional information with each file. For
example, developers can track who
owns a file. In-application programmable triggers add functionality to Surround
SCM without external applications.
Also in Surround SCM 5 are hyperlink
access to files, CVS-style check outs, single
sign-on support, and tighter integration
with issue-management solution
TestTrack Pro.
For more detailed information, visit
www.seapine.com.

www.StickyMinds.com

DECEMBER 2006

BETTER SOFTWARE

37

The Last Word

Happy Are the Software Engineers


by Miska Hiltunen
I have found happiness, and I found it in
software quality.
A major reorganization made our
department one of many responsible for
integrating software modules coded
elsewhere. Suddenly software quality
was out of our hands. We were helpless
slaves to somebody elses bad code.
So I designed a new way of reviewing
code called Tick-the-Code Inspection (see
the StickyNotes for more information).
Instead of trying to mentally debug the
code, you look at it with clearly defined
rules and mark everything you see
breaching a rule. The limited set of rules
ranges from the simple (avoid hardcoded
numbers) to the challenging (avoid
duplicated code). Instead of concentrating
on the functionality of the code, you focus
on the structure of the code guided by
the rules. The marked violations are not
always defects, but left in the code they
make it easier for defects to slip in and find
a permanent hiding place. Removing the
violations makes the code simpler, more
understandable, and easier to maintain.
This method allows you to check
vast amounts of code properly. Once for
example, we managed to avoid severe
problems when we noticed an important
module in our code inspection was utterly
unusable. It was a miracle the module
worked at all, and the only thing clear
about it was that any change would break
it. The complexity was overwhelming.
Our insight into the module made us the
first project to ask for a rewrite, and
later projects bravely followed. Previously, changing a module without reason
was deemed too risky, but positive
experiences gave us the confidence to
continue using the method and also
to start spreading it to the authors of the
source code. Tick-the-Code Inspections
began to make a difference, and I was
happy to see that the participants
seemed to enjoy the process. It was no
coincidence, though. All the right ingredients were there: The checking process
was clearly defined and there were only

two roles, each with its own


set of tasksthe checkers
searched for rule violations, and
the author removed them after
careful consideration.
The whole procedure was easy
to plan and execute. A thousand
lines of code would take an
hour to checkno matter how
good (or bad) the code was. The
checking was done in isolation,
actively avoiding interruptions.

Science of Happiness
According to the man
obsessed by happiness, author
and scientist Mihaly Csikszentmihalyi, happiness isnt just a
pleasurable state of being. You feel good
when your consciousness is in order.
Disorder and chaos in the mind create
stress. Pleasurable activities, like
watching TV, dont in themselves
create happiness. They just restore the
consciousness to temporary order without
adding to the chaos. In the book Flow:
The Psychology of Optimal Experience,
Csikszentmihalyi argues that for you to
feel truly happy, your consciousness
needs to grow. Studying situations of
psychological growth, Csikszentmihalyi
discovered a state called flow. Flow is
an intense state of concentration, a state
so hungry for attention that no room is
left for casual worries. In a state of flow,
only the task at hand matters. The back
cover of the book condenses flow best:
When in flow, people typically feel
strong, alert, in effortless control,
unselfconscious, and at the peak of their
abilities. Athletes, artists, musicians,
chess masters, and surgeons work best
in flow.
Tick-the-Code Inspection makes it
possible for software engineers to enter
flow while checking code.

do the right thing, and be challenged


and happy. This improves both the
product quality and the quality of the
software engineers themselves.
You can cultivate a ubiquitous quality
mentality through practical methods of
empowering software engineers to improve
their own work. Make software quality
available to all, and harness your software
engineers for quality. It makes good
business sense: Instead of relying on a
few good software-quality engineers,
a company is better off having a lot of
good-quality software engineers.
Happy are the software engineers
working with quality. {end}
Miska Hiltunen calls himself a qualiteer, an
experienced and thoughtful defender of
software quality. Miskas in-house Tickthe-Code Inspection trainings show how
to fight complexity, prevent errors, and be
happy doing it. For more information
visit www.qualiteers.com or email Miska
at Miska.Hiltunen@qualiteers.com.

Sticky
Notes

Quality for All

For more on the following topic, go to


www.StickyMinds.com/bettersoftware.

The quest for quality provides


opportunities to learn, make a difference,

www.StickyMinds.com

More on Tick-the-Code Inspection

DECEMBER 2006

BETTER SOFTWARE

39

Index to Advertisers
ACULIS Software Development Services
AutomatedQA
Bredex
Critical Logic
Empirix

Display Advertising
Shae Young syoung@sqe.com
www.aculis.com

15 & 17

www.automatedqa.com

Inside Back Cover

www.bredexsw.com

12

www.critical-logic.com

31

www.empirix.com

38

www.sqe.com/emtd

30

ibm.com/takebackcontrol/flexible

www.iTKO.com/lisa

35

Mercury Interactive Corporation

www.mercury.com

Inside Front Cover

NVP Software Testing

www.nvp-inc.com

40

Parasoft Corporation

www.parasoft.com

11

www.rallydev.com/bsm

37

Seapine Software

www.seapine.com

Software Planner

www.SoftwarePlanner.com

40

www.sqs.com

Back Cover

Software Testing Certification Training

www.sqe.com/getcertified

Software Quality Engineering Training

www.sqe.com/training.asp

36

www.sqe.com/stareast

13

TechExcel, Inc.

www.techexcel.com

Worksoft

www.worksoft.com

eMastering Test Design


IBM
iTKO, Inc.

Rally

Software Quality Solutions (SQS)

STAREAST 2007

40

BETTER SOFTWARE

DECEMBER 2006

www.StickyMinds.com

All Other Inquiries


info@bettersoftware.com
Better Software (USPS: 019-578, ISSN: 1532-3579) is
published eleven times per year. Subscription rate
is US $75 per year. A US $35 shipping charge is
incurred for all non-US addresses. Payments to
Software Quality Engineering must be made
in US funds drawn from a US bank. For more
information, contact info@bettersoftware.com
or call (800) 450-7854. Back issues may be
purchased for $15 per issue (plus shipping).
Volume discounts available.
Entire contents 2006 by Software Quality
Engineering (330 Corporate Way, Suite 300, Orange
Park, FL 32073), unless otherwise noted on specific
articles. The opinions expressed within the articles
and contents herein do not necessarily express
those of the publisher (Software Quality Engineering).
All rights reserved. No material in this publication
may be reproduced in any form without permission.
Reprints of individual articles available. Call for details.
Periodicals Postage paid in Orange Park, FL,
and other mailing offices. POSTMASTER: Send
address changes to Better Software,
330 Corporate Way, Suite 300, Orange Park, FL 32073,
info@bettersoftware.com.

You might also like