James Bach是软件测试领域当之无愧的大牛，探索性测试的很多理论都是从他那里得知的。国内的China Testing（MiniClub）组织也请他到国内演讲过，国内的同行受他的影响也颇深。我也是其中一个受益者，他的文章时常能给我启发。

以下出自他的博客，是他对测试新手的建议。

• Read my blog (www.satisfice.com/blog).
• Read the materials on my website (www.satisfice.com).
• Consider reading either of of my books: Lessons Learned in Software Testing, or Secrets of a Buccaneer-Scholar.
• Read the materials and blog at www.developsense.com
• Get on Twitter and watch the conversations among the Context-Driven community. Participate in those discussions.
• Join software-testing@yahoogroups.com. It’s a quiet, moderated email forum for Context-Driven testers.
• I offer free coaching, too, but you have to read this blog post first.
• Practice testing things that aren’t secret, and then post your test results online so that others can see them.
• Consider taking the RTI Online class.
• Consider taking the BBST class.
• Participate in sessions conducted by www.weekendtesting.com.
• Consider attending the Let’s Test conference or the CAST conference.
• If you want to get good at using tools while testing, try learning Python. Personally, I use Perl, but I hear Python is good.

• Introduction to General Systems Thinking, by Gerald M. Weinberg
• Quality Software Management, Vol. 1: Systems Thinking, by Gerald M. Weinberg
• Tacit and Explicit Knowledge, by Harry Collins
• The Black Swan, by Nassim Taleb
• Testing Computer Software, by Cem Kaner, remains a good classic testing book.

• Don’t get certified. There are no respectable commercial testing certifications. If you are forced to get certified for some reason, do not take it seriously. It’s not an achievement, it’s just a conveyor belt that extracts your money and gives you nothing you couldn’t get for the price of a Google search.
• True certification remains this: the respect of respectable people.

• Automated? Manual? There is no such thing as manual or automated testing. It’s all just testing. Testing is often supported by tools that attempt to simulate user interaction with the system. This is what people call “test automation” even though it is only automating a crude approximation of one aspect of testing. If you have the ambition to be a one-man test team, it is extremely valuable to learn how to make your own tools.
• Exploratory? Scripted? There is no such thing as an exploratory or scripted tester. All good testing is exploratory to some degree and scripted to some degree.
• Tester. This is a testing generalist who can contribute to any test team. Sometimes called a QA analyst, QA engineer, or test engineer. I prefer the simplicity of “tester.”
• Omega Tester. The omega tester (which I sometimes call a test jumper, after the analogy of a paratrooper) is one who can do anything. An omega tester is equipped to be the only tester in a project team, if necessary. Omega testers can lead testing, or work with a team of other testers. I am an omega tester. I aspire to be a good one.
• Performance Tester. The performance tester understands the mathematics and dynamics of the performance of large-scale systems. They use tools that create high loads and measure the performance envelope of systems as they scale up. Performance testers often don’t think of themselves as testers.
• Usability Tester. The usability tester is a bit mythical. I have met only two dedicated usability testers in my entire career, but I have seen more of them from a distance. A usability tester specializes in studying how users feel about using and learning a product.
• Security Tester. Security testers also often don’t think of themselves as testers. Security is an exciting, specialized form of testing that requires the mastery of a great many facts about a great many technologies.
• Testing Toolsmith. A testing toolsmith is a programmer dedicated to writing and maintaining tools that help testers. This is what a lot of people would call an “automated tester” but you better not use that term around me.
• “SDET” Software Development Engineer in Test. This means a full on programmer who does testing using his programming skills.