Question

I read a post on Matt Heusser's blog where "Zero Software Defects" was quoted from a discussion. You can go a google testing myths, but I wondered what the "current" ones were.

What have people seen or heard about recently?

Answer 1

• Testing will find all the defects
• Testing can be done by anybody
• Automated testing is better
• Automated testing can be done of the side of your desk
• Testing is responsible for quality
• ...

Answer 2

Roland has good answers.
I will not repeat his answers, but will add some more options I can think of now (maybe I'll add more later :)).
In the parentheses I explain why these are believed to be myths at this point in history (who knows? maybe in the future we'll have some breakthrough in one of them? :)):

Certifications:

• Testing Certification can attest for skills (they can't, they only attest for a specific glossary)
• Testing Certification can attest for commitment/seriousness of a job candidate (you'll be definitely missing committed candidates if you screen them out based on the certs...)
• Testing Certifications are against exploratory testing (they are not, at least not officially. Many even include a chapter on exploratory (even if badly explained))

Exploration vs Scripts:

• You can define exploratory or scripted testing by looking at how long or detailed is the test case/charter (you can't, I have some comments about it here and here)
• You can tell if someone does scripted or exploratory testing by whether he uses the word 'case' or 'charter' (ibid :))

Metrics:

• Once you can gather the correct data for your metrics, you will be able to properly interpret the graphs (you can try, and only hope for being interpreting them well)

Process:

• Testing will improve the quality of the product (it all depends on how is the testing done, and what actions are taken on its findings)
• A responsible company fixes al the known bugs (this is a variation of the "Perfect Software" myth. A responsible company fixes the bugs that risk enough value to users that matter)
• If it worked for one company at one time, it will certainly work again for a different company at a different time (this is a variation of the "Best Practices Exist" myth. A solution that was tailored for one context will hardly fit another context comfortably)

Answer 3

I have some more:

• You should not need to test after the (automated) unit test.
• You can test quality (performance) into a crappy product.
• Testers always lie about the time they need for testing. (last time we cut them down to half the time and they still managed to finish their testing.
• Only testers care about quality.
• Testing should have the last word before a product is shipped.
• Delays at the end of the project because of found defects is the testers' fault.
• Requirements testing is enough
• Scripted test cases are needed for good testing
• Exploratory testing is better
• Exploratory testing can only be done on small project with small problems.