Skip to content

Some Classic Testing Mistakes

August 7, 2012

The role of testing

  • Thinking the testing team is responsible for assuring quality.
  • Thinking that the purpose of testing is to find bugs.
  • Not finding the important bugs.
  • Not reporting usability problems.
  • No focus on an estimate of quality (and on the quality of that estimate).
  • Reporting bug data without putting it into context.
  • Starting testing too late (bug detection, not bug reduction)

Planning the complete testing effort

  • A testing effort biased toward functional testing.
  • Underemphasizing configuration testing.
  • Putting stress and load testing off to the last minute.
  • Not testing the documentation
  • Not testing installation procedures.
  • An overreliance on beta testing.
  • Finishing one testing task before moving on to the next.
  • Failing to correctly identify risky areas.
  • Sticking stubbornly to the test plan.

Personnel issues

  • Using testing as a transitional job for new programmers.
  • Recruiting testers from the ranks of failed programmers.
  • Testers are not domain experts.
  • Not seeking candidates from the customer service staff or technical writing staff.
  • Insisting that testers be able to program.
  • A testing team that lacks diversity.
  • A physical separation between developers and testers.
  • Believing that programmers can’t test their own code.
  • Programmers are neither trained nor motivated to test.

The tester at work

  • Paying more attention to running tests than to designing them.
  • Unreviewed test designs.
  • Being too specific about test inputs and procedures.
  • Not noticing and exploring “irrelevant” oddities.
  • Checking that the product does what it’s supposed to do, but not that it doesn’t do what it isn’t supposed to do.
  • Test suites that are understandable only by their owners.
  • Testing only through the user-visible interface.
  • Poor bug reporting.
  • Adding only regression tests when bugs are found.
  • Failing to take notes for the next testing effort.

Test automation

  • Attempting to automate all tests.
  • Expecting to rerun manual tests.
  • Using GUI capture/replay tools to reduce test creation cost.
  • Expecting regression tests to find a high proportion of new bugs.

Code coverage

  • Embracing code coverage with the devotion that only simple numbers can inspire.
  • Removing tests from a regression test suite just because they don’t add coverage.
  • Using coverage as a performance goal for testers.
  • Abandoning coverage entirely.

Source by Brian Marick

From → Nice to read, Theory

  1. Hey just wanted to give you a quick heads up. The text in your post seem to be running off the screen in Opera.

    I’m not sure if this is a formatting issue or something to do with browser compatibility but I thought I’d post to let you know.
    The design look great though! Hope you get the problem
    resolved soon. Cheers

    • It can be so as I only use FF and sometimes Safari. I’ll try to ask support to solve the problem.

  2. Way cool! Some very valid points! I appreciate you penning this article plus
    the rest of the website is extremely good.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: