Wednesday, January 25, 2017

Cambridge Lean Coffee


This month's Lean Coffee was hosted by Redgate. Here's some brief, aggregated comments and questions  on topics covered by the group I was in.

Why 'test' rather than 'prove'?

  • The questioner had been asked by a developer why he wasn't proving that the software worked.
  • What is meant by proof? (The developer wanted to know that "it worked as expected")
  • What is meant by works?
  • What would constitute proof for the developer in this situation?
  • Do we tend to think of proof in an absolutist, mathematical sense, where axioms, assumptions, deductions and so on are deployed to make a general statement?
  • ... remember that a different set of axioms and assumptions can lead to different conclusions.
  • In this view, is proof 100% confidence?
  • There is formal research in proving correctness of software.
  • In the court system, we might have proof beyond reasonable doubt 
  • ... which seems to admit less than 100% confidence. 
  • Are we happier with that?
  • But still the question is proof of what?
  • We will prioritise testing 
  • ... and so not everything will be covered (if it even could be)
  • ... and so there can't be emprical evidence for those parts.
  • How long is enough when trying to prove that a program never crashes?

What would you be if not a tester? What skills cross over?

  • One of us started as a scientist and then went into teaching. Crossover skills: experimentalism, feedback, reading people, communicating with people, getting the best out of people.
  • One of us is a career tester who nearly went into forensic computing. Crossover skills: exploration, detail, analysis, presentation.
  • One of us was a developer and feels (he thinks) more sympathetic to developers as a result.
  • One of us is not a tester (Boo!) and is in fact a developer (Boo! Hiss! etc)
  • I am a test manager. For me, the testing mindset crosses over entirely. In interactions with people, projects, software, tools, and myself I set up hypothesis, act, observe the results, interpret, reflect.
  • ... is there an ethical question around effectively experimenting "on" others e.g. when trying some approach to coaching?
  • ... I think so, yes, but I try to be open about it - and I experiment with how open, when I say what I'm doing etc.

Pair Testing. Good or Bad?

  • The question starts from Katrina Clokie's pairing experiment.
  • The questioner's company are using pairing within the Test team and find it gives efficiency, better procedures, skill transfer.
  • It's good not to feel bad about asking for help or to work with someone.
  • It helps to create and strengthen bonds with colleagues.
  • It breaks out of the monotony of the day.
  • It forces you to be explain your thinking.
  • It allows you to question things.
  • It can quickly surface issues, and shallow agreements.
  • It can help you to deal with rejection of your ideas.
  • Could you get similar benefits without formal pairing?
  • Yes, to some extent.
  • What do we mean by pairing anyway?
  • ... Be at the same machine, working on something.
  • ... Not simply a demonstration.
  • ... Change who is driving during the session.
  • We have arranged pairing of new hires with everyone else in the test team.
  • ... and we want to keep those communication channels open.
  • We are just embarking on a pairing experiment based on Katrina's.

Reading Recommendations.

  • Edward Tufte, Beautiful Evidence, Envisioning Information: data analysis is about comparison so find ways to make comparisons easier, more productive etc on your data.
  • Michael Lopp, Managing Humans: we all have to deal with other people much of the time.
  • Amir Alexandar, Inifinitesimal: experimental vs theoretical (perhaps related to the idea of proof we discussed earlier).
Edit: Karo Stoltzenburg has blogged about the same session and Sneha Bhat wrote up notes from her group too.

No comments:

Post a Comment