Software Testing Problems Part 2: Your Talents
When I transitioned to a Team Lead position at Microsoft I was inundated with more
training and advice than one could usefully absorb. The
one book that stood out amongst the rest was “First,
Break all the Rules”. Sure the title
has a certain appeal to someone in their mid-twenties like me, but there are a lot
of truisms in this book and I would recommend it to anyone whether they are in middle
management or not. Testing, like most
other professions, requires a healthy mix of natural talents and learned skills to
be done right. If you don’t have
people or a team with the right mix of these abilities then you will not ship a quality
product no matter what methodology you use, time you have, or any other resources
available to you. What talents and strengths
are needed to test your software?
Being the Customer: In
my first testing
blog I talked about the importance of a customer connection. Successful
testers have a passion for the software they are testing and would otherwise be consumers
of that software. I don’t work there,
but I’m willing to bet the best testers at Adobe are people that enjoy playing with
digital art. I know some of the best
testers in Visual Studio are people that love developing software and are pretty good
developers themselves. This personal
connection enables you to have a good home base from which to base your customer knowledge.
Healthy Paranoia: Just
because your paranoid doesn’t mean someone isn’t trying to spoof your domain. Good
testers don’t take anything for granted, but have a talent for knowing where to place
their paranoia when constructing their test plans.
Creativity: How long could you spend dreaming
up tests for a salt shaker? This, slightly rephrased as “Test this salt shaker”, was
my lunch interview at Microsoft. You
still probably haven’t thought of all the ways people will use your software, but
it’s best if you can get yourself a good start. My
interviewer got to eat; my food had too much salt in it.
Abstraction: With software becoming increasingly
complex and code component re-use it becomes important to understand the big picture
without getting lost in the details. Most
new testing methodologies like Model Based testing only succeed when the testers are
able to accurately abstract the system at hand.
I’m sure I’ve missed some with the short amount of time I’ve spent on this entry. I’d
love to know if there is a talent I’ve missed that ranks with these four. IMO,
once you get beyond this level you have to start asking more specific questions like
“What kind of software are you developing?” or “What approaches do you want to use
in order to test?”. Even before the second
question you may have to ask “What other skills and talents does my team posses and
what approach makes the best use of these?” These
are all important questions that one must tackle to successfully test, but no matter
what your answers are I bet your team will have trouble if you don’t have a mix of
these basic ingredients.
Again, I’d love to here your opinions.