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?
- 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