I’ve been neglecting my 5 questions with… folder recently. Here is the catch-up; with commentary. Of course.

Amol Kher

  • Models are what developers will hate to love or love to hate – Or both?

Ethan John

  • I had no idea that [testing] was something I could do for a living. – This is such an important problem for the testing community. One which I have no idea how to fix.

Michael Corning

  • The first thing a tester needs to know about testing is that you cannot test what you do not understand – Oh I so don’t agree. Maybe if you tacked on a ‘or does not want to understand’ I could go along with the statement. As it is now it is equivalent to saying that all programmers need to know Assembly. Heck, a lot of programmers nowadays don’t even know C and the ‘joy’ that is pointers and manual memory management.
  • In my mind, the tester is an auditor. The function of the auditor is to attest. In financial auditing, the auditor attests with his or her signature that the financial results fairly represent the financial results of business operations. From this attestation, other decision makers make their decisions. Both the auditor and the tester provide information to the eco-system. – Attestation implies a certain level of guarantee. Again, to cite the diagram in the BBST Foundations material, there are so many factors that attesting to the quality is a trap — at best. An opinion, sure. But attestation? Nope.
  • I do my best to use the machine to generate test cases for me. – All hail the machine. This to me is the point you want to evolve your automation towards

Keith Braithwaite

  • Write tests to capture requirements. Count tests written to measure scope. Count tests passing to measure delivery. Use tests to drive design. Use tests to communicate between teams, with customers. Use tests to meet regulatory loads and show compliance without mountains of paper. Oh, and to find defects too. But that last one is just the cherry on the cake. – Count tests to get a useless number; I can write a million tests that provide useless information but still shows 7 figures in the count. Use tests to confuse the customer; maybe he deals with different people in different organizations, but the people on conference calls I have been on would go glassy-eyed in under a minute if presented with tests. Which isn’t bad as they don’t need to know how to read the tests. This applies too to requirements. I’m in this situation now, and it is not enjoyable in the least. Capture the requirements in a document, or series of documents and make sure they evolve with the application. Or better still, put them in a wiki.

  • Gil Broza

    • Think-once-then-automate