四处找的文章之Rick Craig

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?（阅读地图－>“Systematic Software Testing,from Rick Craig”） 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 scrīpted 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 scrīpted 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（阅读地图－>“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