First Lean Coffee of the year, and the first Lean Coffee and second overall Meetup via our shiny new dedicated Ministry of Testing Cambridge Meetup Group. If you’re in the Cambridge area and interested in testing, sign up!
We’ve met at Redgate – with many thanks to Chris George for organising and Jose Lima and Gareth Bragg for hosting. Great attendance, we’ve ended up with three groups, of which I had the pleasure to facilitate one, which is always good fun. We tackled the following topics:
Why “test” rather than “prove”?
A developer had wondered about this. We’ve discussed a bit around definitions like validation vs. verification, looked at axioms and assumptions, static analysis and coverage. We were also wondering about the kind of totality a proof entails and how applicable this is in the ever changing context and complexity we are usually faced with when testing.
To me most interesting though was wondering if this focus change would actually be helpful in testing. And I’m leaning towards not – as testers we are focusing on falsifying assumptions, are keeping our questioning and adaptive mind, wanting to learn more about the thing we’re looking at. Trying to prove something feels too finite, too closed off, and might stand in the way of the open mindset I’m trying to have when testing.
What would you be if not a tester? Overlaps?
That was one of my questions, actually. Interestingly, I was more thinking about alternate, “dream” jobs in the here and now, but we talked more about transitions from previous jobs. Some of the skill overlaps that were mentioned from non-tester jobs: running experiments as a scientist, regularly questioning my approach as a (test) manager, attention to detail as a developer, communication and presentation skills from being a teacher, looking at evidence in an exploratory way from forensic information technology. I can add my bits and pieces along the line: empathy and the ability to switch your point of view from my background in humanities and literature.
Pair testing. Good or Bad?
As I’m just starting a pairing experiment at work (heavily borrowing from Katrina Clokie), it was really interesting to hear how other testers approach this, from the more formal organised approaches to get this up and running to an atmosphere were regular pairing already has become a habit. We looked at testing being different from general meetings by being more intimate (as usually a one to one situation), with more interaction. In pairing we focus primarily on a task, while knowledge transfer is more of a beneficial side effect. We also touched on the hands-on character of a pairing activity with room to switch the “driver”. And we looked at some benefits from engaging in this: how regular pairing can bring the test team together and benefits the overall morale, how you can further transferable skills, how it trains you to question as well as explain what your doing and why, how it’s a way to establish communication channels in the team. So Good or Bad? Good, we like it.
Another one of my questions, raised as I was looking for actual suggestions to bring to the book lunch club thing that we have in our testers group at work. Many thanks for the suggestions, we’ve now actually picked one of them up, Michael Lopps’ “Managing Humans“. I’m really looking forward to it.
Topics we didn’t got round to discuss:
* How to organise bloated existing test cases / regression?
* Any methods for organising work?
* A new thing you’ve learned last year?
* Testing Applications used “in house”
* My Dad doesn’t know what testing is. How can I define it for him?
* Test Driven Development, when testing is avoidable?
* What are your most commonly used test techniques?
* When was your expectation totally violated?
* AI is a growing trend in software. How can it be used in testing?