|
Rick Craig is a
well known name in testing circles because of his book "Systematic
Software Testing" as well as the quality of his tutorials and
presentation.
In this
interview he shares his ideas and advice
with the testers.
If you want
to ask him more questions or you want to send any feedback on this
interview, please send it to webmaster @ whatistesting.com.
|
|
Q1. Rick, please tell us something about
yourself, your background, your interests and things that you like to
do in your free time.
|
I was born and raised in the Midwest and
then moved to Annapolis, Maryland to attend the U.S. Naval Academy and
then subsequently begin a career in the Marine Corps. I spent 12
years on active duty and then was recalled to active duty during the
first Gulf War. I am now a Colonel in the Reserves.
Even though I am an
artillery officer, I had the opportunity to attend the Marine Corps
Computer Science School first as a student and then as an
instructor. I got my first testing job around 1980. In 1982
I got the opportunity to work with a couple of contractors who were
probably as close to testing experts as there were in those days.
For 3 years they mentored me in testing, writing and presentation
skills.
Then about that time
Bill Perry invited me to do a key note at the First (Second?)
International Testing Conference. Bill was a strong influence on
my testing career at that point. I started working with Bill
Hetzel and Dave Gelperin in the mid 80’s and they hired me to work for
them fulltime in 1989 and I’m still with SQE.
I have a daughter,
Crissy who is a Junior at the University of South Florida. I am
the co-owner of a popular restaurant called Maddogs and Englishmen,
which over the last 15 years has become an icon in Tampa Bay.
(www.maddogs.com)
|
|
Q2. How did "Systematic Software Testing" happen? How much
time did it take?
|
For years, the students in my seminars
urged me to a write a book as a companion volume to my Test Management
Course, but the problem was always finding the time…….. That
problem was eased by asking my old friend Stefan Jaskiel, a technical
writer to help me with the book. Even though almost all of the
words in the book are mine, I doubt that I would ever have finished it
without Stefan’s help and motivation.
The book took 2 months
of dedicated work, plus a lot of work on airplanes over the course of a
year. The book is also available in Chinese and will be out in Japanese
this month.
|
Q3. Are
there any incidents that might help future authors and that you would
like to share?
|
Here are some tips that helped me write
this first book:
1.Just do it!
2.Pick a time every day
and work on the book even if it doesn’t seem like you’re making
progress.
3.Get good
reviewers. Listen to their input but at the end of the day, it’s
your choice.
4.If you’re having
trouble getting started, pick a coauthor.
5.Don’t try to make
your book cover every topic under the sun………..
|
Q4. Are
you working on any other book currently?
|
No, not right now. My travel and
lecturing occupies most of my time.
|
|
Q5. What, in your experience, are the issues most testers
face?
|
I think one of the major issues facing
testers today (and every day in the past) is determining the value of
the testing effort and determining when the task is done. I think
that in some environments it is also difficult for testers to gain
respect from developers and users.
|
Q6.
Do you think there is a similarity in these issues across geographical
locations or are
the issues different?
|
I see very little difference across
geographical regions (including other countries)
|
Q7.
What, in your experience, are the areas of improvement for most testers
and how can they improve?
|
Bill Hetzel and I did some research in
the early 90’s and the one thing that I learned that stood out for me
was that the best teams were the best because they did the basic things
well. That is not to say they didn’t employ complex,
sophisticated techniques—they did. But it was the basic stuff
done well that ensured their success. I think today’s testers
need to get better at estimating schedules and risk and learn some of
the basic test design techniques that have been available for years.
|
Q8.
Where do you stand between pure exploratory testing and pure scripted
testing? Has your understanding changed over time? In what way?
|
Well, my book is called Systematic
Software Testing which would lead you to believe that I am in the
scripted camp. And indeed, I am in favor of creating test cases
that demonstrate the users can perform those tasks that are necessary
for them to be successful in their jobs. It really doesn’t matter
how many bugs we find (and hopefully fix)if the users cannot do their
jobs. On the other hand, finding and removing bugs can ultimately help
the user perform their jobs in a more productive manner. I don’t
think anyone questions the effectiveness of techniques like exploratory
testing in identifying bugs. I would contend that good testers
have done “exploratory-like” testing for years. That is to say that the
result of one test leads the tester into the next test….. Experts
like James and Cem have given exploratory techniques credibility and
made it possible for mainstream testers to benefit from them.
|
Q9.
How effective do you think buddy testing is? How cost-effective do you
think it is?
|
Buddy testing, which is essentially
working in teams and having the buddy create test scenarios before the
code is written are very effective. Buddy testing, in effect,
implements preventive testing at the unit level. Other techniques, like
paired programming are also effective and enjoy much wider recognition.
Over the last 20 years
or so, I’ve urged my clients and students to use buddy testing. I must
admit that most organizations never receive enough buy-in to make it
work. Literally, each programmer must learn twice as much code,
which of course takes more time upfront. Those organizations that
do try it though, are generally successful and in some cases greatly
reduce the number of defects passing on to the test group and
ultimately the users.
|
Q10.
What is your take on certification of testers?
|
I think that certification is not
necessarily a very good indicator of the skill or ability of a tester
to do a good job. By the very nature of the training and
certification testing, the focus is on terminology and “book
learning”. Still without sounding too much like a consultant……I
put myself firmly in the pro-certification camp. How so? If
a company chooses to make certification a goal or challenge for their
testers, it can be a motivator and offer a sense of accomplishment for
the individual testers. Also, it can help a test manager
standardize on the terminology used within the company and that alone
is very valuable.
|
Q11. Is there any particular
certification that you recommend?
|
I’m pretty excited about the ISTQB that
is just now rolling out in the States. It has some leverage in
Europe and is created by a team of experts and practitioners.
|
| Q12. What are your thoughts in a
single standard testing terminology? Why do you think one does not
exist? |
Well, testing was born of the need to
validate software systems. The first testers tended to be
developers and in some cases, users. Each group and each industry
chose the words that made sense to them. When writing Systematic
Software Testing, I spent quite a bit of time researching various terms
and trying to come up with what was the most common usage. I
can’t say that my efforts were always successful. I’m also not
very optimistic that a common terminology will be obtained in the near
future, although some progress is being made. I think, the
internet, conferences, books, training programs, certification, etc. is
gradually lessening this problem.
|
| If
you were your own
interviewer what question(s) would you like to ask yourself?
|
It
is: |
Q1. What is the one (ok two or three)
skill that you look for most in a tester?
|
Good Communications skills.
Creativity. Attention to detail…
|
