Test Notes

I don't make software; I make it better
posts - 78 , comments - 60 , trackbacks - 616

Software Testing Myths

Myth #1

 

Myth:

  • OO testing is unnecessary. OO promotes incremental development and reuse, so we have a more effective way to develop trustworthy classes.

 Reality:

  • Human error is as likely as ever. We have to check class functionality and interactions between classes

Myth #2

 

Myth:

  • Testing is a structured waterfall idea and isn’t consistent with incremental OO development

Reality:

  • Tests can be designed and exercised at many points in the process
  • Paradigm of “design a little, code a little” becomes “design a little, code a little, test a little”
  • Extreme Programming (XP) promotes early testing

Myth #3

 

Myth:

  • Testing is too expensive

Reality:

  • Pay me now or pay me MUCH more later
  • Failures in operational systems can cause severe secondary problems
  • Proper testing is very cheap by comparison, even when done manually
  • Efficient testing of large or complex systems needs some automated support

Myth #4

 

Myth:

  • OO testing is the same as conventional software

Reality:

  • Polymorphism, inheritance, encapsulation present opportunities for error

Myth #5

 

Myth:

  • Conventional testing is useless for objects

Reality:

  • There is a large body of knowledge about testing
  • Basic testing techniques continue to apply with necessary changes
  • If scope of testing is small, ie classes and collaborations
    • Testing techniques are very OO specific
  • As scope of testing gets larger
    • Testing techniques become more traditional

Myth #6

 

Myth:

  • Inheritance means never having to say you are sorry
  • Specializing from a trusted superclass means the inherited part of subclasses will also be correct
  • We don’t need to retest inherited features

Reality:

  • Subclasses create new ways to misuse inherited features
  • Different test cases are needed for each subclass

Myth #7

 

Myth:

  • Reuse means never having to say you are sorry
  • Reusing trusted class means behavior of server object is trustworthy and doesn’t need to be tested

Reality:

  • Nothing prevents a new client class from using the server object incorrectly
  • All client class use of a server needs to be exercised

Myth #8

 

Myth:

  • Black box testing is sufficient
  • Designing test cases using class interface and specification assures the class is fully exercised
  • White box testing violates encapsulation

Reality:

  • Studies show black-box test suites typically only exercise 1/3 to 1/2 of the statements (let alone paths or states)
  • Typically miss abnormal paths, exception and error handling

 

Print | posted on Tuesday, April 13, 2004 11:42 PM | Filed Under [ Software Testing ]

Feedback

Gravatar

# re: Software Testing Myths

Nice post. Maybe more people will unit test now!
4/15/2004 9:53 AM | Darrell
Gravatar

# re: Software Testing Myths

These are, no doubt, well stated. I have another myth. Say it myth 9.
"For small projects(low level) there is no need to develop:
1. Architecture
2. Documentation
3. UML work... "
10/27/2005 1:31 PM | Shahid
Post A Comment
Title:
Name:
Email:
Comment:
Verification:
 

Powered by: