Wednesday, May 23, 2018

Cambridge Lean Coffee

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

As a developer, how can I make a tester's job easier?

  • Lots of good communication.
  • Tell us about the test coverage you already have.
  • Tell us what it would be useful for you to know.
  • Tell us what you would not like to see in the application.
  • Tell us what is logged, where, why, when.
  • Tell us what the log messages mean.
  • Tell us how you think it's supposed to work.
  • Show us how you think it's supposed to work.
  • Give us feedback on our testing - what's helping, what isn't.
  • Offer to demonstrate what you've done.
  • Say what you think are the risky areas, and why.
  • Say what was hard to get right, and why.
  • Recognise that we're not there to try and beat or show you up.
  • Help us find our unknown unknowns by sharing with us 

How can we help you, as a developer?

  • Give good repro steps in your reports.
  • Help me to understand the ambiguous requirements.
  • Ask your questions, they really do help.
  • Don't accuse.
  • Have specific details of the issues you observed.
  • Understand that developers can feel defensive of their work.
  • Tell me when you see something good, or something that works.

How do you avoid or mitigate biases?

  • Look back and review what you did, critically.
  • Check your assumptions or assertions.
  • Ask a developer.
  • Externalise your assumptions.
  • Peer review.
  • Rubber ducking.
  • Write (but don't send) and email to someone who might know. (Like rubber ducking)
  • Do something else for a bit and come back.
  • Be aware of the kinds of biases there are and then you can check for them.
  • Rule of three helps to generate perspectives.
  • Write down what you did, as this prompts thoughts about it.
  • Compare what you did to something else you could have done.
  • Remember to say "my assumption is" or "but perhaps that's my bias" out loud.

Should all testers know a programming language and, if so, which one?

  • It can help, e.g. to review code changes.
  • It can help with other aspects of testing, e.g. data generation.
  • Which language? Shell, because it's almost always just there. 
  • I like python.
  • Should is a strong verb. Understanding the need would help to answer.
  • Testers shouldn't feel forced to learn a programming language
  • ... but they should understand the risks of not (e.g. in recruitment, or by lacking a powerful tool)
  • It helps with software development jobs generally.
  • So does other technical knowledge, e.g. of HTTP.
  • Reading a language helps in testing.
  • There's an analogy to speaking English in a foreign country - it helps to have a bit of the local language.
  • Enables more empathy with the developer - probably less of the "we'll just fix that" mentality.
  • When recruiting, I don't care about the language.
  • It's best when there's support and a community to help learn programming.

What testing tool would you like to be able to wave a magic wand and just invent?

  • A universal standard for test case management and reporting software.
  • A tool to create a visual map of product architecture which can be overlaid with code changes, all aspects of testing, recent issues.
  • ... and also predict new issues!
  • Something that can reliably map specification items to test cases, and show what needs to be changed when the spec changes.
  • A reliable, stable GUI testing tool.
  • Something that puts a team straight into the sweet spot of great communication, talking directly, working with each other.
  • A Babel fish that means that the listener understands exactly what was meant by the speaker.

Do you bring questions to Lean Coffee or make them up when you're here?

  • Both.
  • I think about them in the shower.
  • I try to come with one then make some up.
  • I take notes during the month, then try to remember them on the way.
  • I think on the way in.
  • Would some kind of a board, perhaps Trello, be useful to store them between meet ups?
  • Perhaps it'd lead to discussion in Trello?
  • Perhaps people would come prepared with arguments for the issues they'd seen on Trello.
  • Topics might be stale by the time the meetup comes around.
  • Spontaneous is good!
  • Person-to-person is good!
  • Paper and pencil mean you think differently

No comments:

Post a Comment