Further Information

Contacting the Author

Should you have any questions or wish to discuss any of the issues raised in this Pocketbook, or perhaps you would like help in improving testing in your organisation, please feel free to contact Paul Gerrard.

Email: paul@gerrardconsulting.com

Tel: +44(0)7940 547894

Ordering copies of the Tester’s Pocketbook

Hard copies of this Pocketbook can be ordered from the Gerrard Consulting website:

http://gerrardconsulting.com

Custom versions of The Tester’s Pocketbooks

Some companies like a custom version of the pocketbook with their name on the cover. If you would like a customised version of the Pocketbook for your team, we are happy to create one for you. Perhaps you want include company information or policy in the Pocketbook? The material in customised Pocketbooks will remain copyrighted to its respective authors.

Do get in touch if this is of interest.

  1. Very few references to the popular testing books are given in the Pocketbook (not even to my own book). Visit the book’s website testers-pocketbook.com for a ‘further reading list’.↩
  2. From now on, I’ll use the term tester to denote the role of someone who does testing. There are many testers who test full time, but testing is also a part-time role for a designers, developers and users.↩
  3. If you are testing something unusual and the book helps you to formulate a test approach – please let me know.↩
  4. My blog can be found on my website: http://gerrardconsulting.com↩
  5. This usage is consistent with many other famous examples: the Definitions in Euclid’s Elements, Newton’s laws of motion, the US Declaration of Independence present sets of beliefs without proof or corroboration. Most have subsequently been shown to be imperfect, but they continue to work for most practical purposes.↩
  6. In 2001, I coined the term Project Intelligence to represent the information, data, and analysed outcomes (the evidence) from testing. (Project intelligence is analogous to battlefield intelligence in a military campaign).↩
  7. Serves me right.↩
  8. Years ago, I was sat alone in a Euston Railway Station Restaurant. A small man (he turned out to be a professional jockey on his travels) approached me and asked could he join me? We enjoyed a long, diverse conversation. As we parted I asked him why he chose to talk to me rather than one of the other travellers. He said, “Your shoes were clean and your tie is tied properly”. I obviously passed his test.↩
  9. From now on, I will use the term developer to denote the people who build systems.↩
  10. I’m using Projects as the context for testing throughout the book because that is the most common context. However, testing can exist in a maintenance context or as a learning or evaluation exercise (to better understand a packaged-solution) for example. It doesn’t make much difference to the thought processes involved.↩
  11. The merits and demerits of planned, scripted testing compared with ad-hoc, unscripted exploratory testing are the cause of some debate.↩
  12. From dictionary.com. Note that I’m not using the term quality to reflect the relationship between a user or stakeholder and a product. Quality is like beauty – in the eye of the user. I won’t be drawn into discussions of how one measures it. I’ll avoid using the word wherever possible from now on.↩
  13. A requirement is a singular need of what a particular system should do. Sets of requirements may be documented in detail or at a high level, but requirements can never be complete. Implicit requirements reside in the heads of users, stakeholders, developers and testers.↩
  14. But not that good, really. Unfortunately, the testing profession is dogged with terminological problems. The words test and testing can be preceded and prefixed by countless words that qualify them. Re-test, user test, acceptance test can all be both nouns and verbs, for example! Always check the context of the words test and testing to be sure you understand what is meant by them.↩