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


Comments (12)
  1. J.P. says:

    I think those four are dead on. There is only one that I might add, but only as a subnote, and that is common sense. That sounds strange, and some might wonder, "isn’t it good to have common sense as a human in general?" Well, my answer is yes, but the reason that I bring this up is that in technology many people tend to get caught up in features, gadgets, and just general "coolness" that the whole concept of "how will people use this" can get lost in the technology. While this does not always matter in academics and research, its a good thing to keep in mind when you are trying to sell great software. (my .02)

    One other thing that I would add to this discussion is that in addition to all of these things, you really need to work with others that understand these strengths. If you work with people who see these as weaknesses or even annoyances, then you may not be as encouraged to do your best.


  2. Anonymous says:

    What I would add from my personal experience is a good understanding of the development process and developers. Many times when releasing hotfixes there is not enough time to do a full testing cycle. The great deal of dev inside is required to understand what the fix is; how does it affect the whole package; what pieces might also be affected and what NOT to look into. Often knowing people and building trust is important. My best testers know what particular change is ‘safe’ simply because they trust the group who made the change. Sometimes they are paranoid because of the same reason.

  3. UAK says:

    Just to add few things here:

    1) The tester should evaluate him/her continuously in terms of technical skills and quality of work being performed.

    (2) The tester should have the ability to look at the application under test from different view points

    (3) Passion and commitment to "perfectionism" should be the essential part of his/her personality

  4. Josh Ledgard says:

    Thanks for the added opinions. 🙂

  5. Software Testing Problems Part 2: Your Talents

Comments are closed.

Skip to main content