Jerry Weinberg: Perfect Software

rube_goldbergs_-self-operating_napkin-_cropped-1

It’s probably fair to say that Jerry Weinberg: ‘Perfect Software and other illusions about testing’ is one of a handful core resources when you want to learn about Software Testing. My manager recommended it to me when I first met him, and I read bits and pieces here and there, but somehow never found the time to read it through properly from cover to cover. But as I’ve set myself a challenge to read three books a month this year, and have been finding myself being drawn toward non-fictional works more and more, I saw a chance to finally fit it in.

‘Perfect Software’ is more than worth your time, and feels like one of the books that will teach you something new on every re-read. The following is not a comprehensive list, but a random one of (often paraphrased) quotes that stuck out and thoughts that the book invoked in me, /this/ time round.

[Overall]

  • It’s really refreshing that Weinberg doesn’t seem to find it necessary to make a distinction between manual/automated testing. I find myself cringing more and more when I have to deal with these terms – I’m not sure that they always add value.
  • It’s enlightening that he’s so open to proposing not to do testing, e.g. when it doesn’t fit any need. Whether testing can make a difference in a certain situation is a great question to ask!
  • I’m starting to find value in more often consciously separating test preparation from testing and viewing it as a different activity that can be performed at a different point in time

[Chapter 2 – What Testing Cannot Do]

  • Testing provides information, but the information is not reduced to the actual reporting of the testing. If the tester struggles to install, to understand, to test the product, that is highly valuable information in itself (about the product, the process, the tester, the fitness for test, etc.)
  • There are reasons for /not/ testing, e.g. when you’re not prepared or willing to use the information it would bring
  • Be prepared to cut your testing short, to accept and deal with a “good enough” if that is what the project would benefit from most

[Chapter 5 – Meta-Testing]

  • Consider the quality of information, too
  • Concentrate /and/ focus – one without the other accomplishes little

[Chapter 6 – Information Immunity]

  • Threat response might make us immune, blind to problems, might hinder our appropriate response
  • Defence categories: repression, rationalisation, projection, displacement, overcompensation, compulsiveness
  • Be aware of your own and others defence mechanisms

[Chapter 7 – How to Deal with Defensive Reactions]

  • Think about what motivates/drives your responses (is it quality/value to sbd.?)
  • Pretty much everybody cares about quality
  • Cut yourself some slack, allow yourself to learn

[Chapter 8 – What makes a Good Test?]

  • You can seed bugs to find what (type of bugs) your testing detects
  • test != demonstration
  • evaluate the badness of your tests
  • be aware that finding bugs slows down testing

[Chapter 10 – Testing Is More Than Banging Keys]

  • “To qualify as a test, an action has to seek information that will influence action, whether or not it involves banging on keys.” (p.90)
  • Testing provides information (that might only be valuable if that information is used?)
  • Intent of testing must (?) be to learn something new to gather information (-> that I can act upon?)

[Chapter 11 – Information Intake]

  • Neutralize you test reports -> it’s only data, information. Interpretation and meaning comes later

[Chapter 12 – Making Meaning]

  • Be always open to discuss situations where you might not need (formal/independent) testing
  • Use language to keep /yourself/ aware of potential problems, different meanings, context, potential of change in the future. E.g. numbers /appear/ the same rather than /are/ the same.
  • “Testers are supposed to be finding fissures, not blaming people” (p.111)
  • “If you can’t think of at least three possible interpretations of the test result, you haven’t thought enough.” (p.103)
  • Consider the receiver when submitting a message
  • There are many possible meaning to the same data

[Chapter 13 – Determing Significance]

  • Perform most significant tests first. Then, whenever you decide to stop testing, you will have done the best you could within the time you had.

[Chapter 14 – Making a Response]

  • Towards the end of the project, stop testing, prepare for the end game.
  • A Bugfix is a change like any other, so also a candidate to introduce new bugs (but not necessarily P1’s). Think about fault-feedback-ration.
  • Can you make a difference with what you’re doing?

[Chapter 16 – Testing Without Machinery]

  • If you’re puzzled, translate this feeling (e.g. into testing terms).
  • Do /not/ sit and wait for a developer to give you sthg. to test
  • Where are technical reviews in agile development?
  • Don’t underestimate the value of learning

[Chapter 18 – Oblivious Scams]

  • Document your findings early and regularly
  • People are more important than process or rules
  • Quantity does not mean quality
  • Beware of wanting too much for everything to go well (~ keep your attentive testing mind)

Picture: Rube Goldberg’s “Self-Operating Napkin” (via Wikimedia Commons)

Advertisements

About Karo Stoltzenburg

Software Tester in Cambridge. Views are my own.
This entry was posted in I've read a thing (or two) and tagged , , , , , . Bookmark the permalink.

Leave a Reply

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

WordPress.com Logo

You are commenting using your WordPress.com 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