This week I am talking to Mel Eaden AKA Mel the Tester!
This is gonna be a two parter as we spoke for a while about many many things, so part one today, part two next week, then back with our normal fortnightly schedule the week after that. That’s right, three episodes in three weeks! That’s how much we love you, listeners <3
As well as being a tester, Mel organises the Ministry of Testing’s writing community, which is an awesome place for anyone who wants to write, edit, proof-read or in someway contribute to the Dojo on the Ministry of Testing. If you’re interested, ping Mel on either the Testers.io or Ministry of Testing Slack, or email email@example.com
The basis of this episode was the conflict between testers as story tellers and being concise, and was based on this blogpost from Mel:
My personal goal for November is to answer a question first and then ask if the person wants more of a story or explanation of why I gave the answer I did. This is my personal goal based on feedback. I was made aware of the round about way I approach my answers, thinking I have to give an explanation up front for everything I’m going to say when a person doesn’t have context.
This intrigued me – I often feel like I’m just spaffing on at people, and figuring out what’s too much info and what’s the info they actually need is something I think about a lot, and so I reached out to Mel to be on the show.
We also discuss when soapboxing is needed, testers as journalists and translators, and ‘technical testing’.
- Balance between context and not blinding people with details
- The issue is how do you know if they have enough context?
- Ask them if they need more info
- Could point them towards a document/place/email with more context if possible?
- Cultural habits – people get stuck in conversations they can’t seem to get out of. “If you stand there like you don’t have somewhere else to go, I’ll keep talking.”
- Getting annoyed with the short version of the answer – I keep asking questions because I want to have the conversation and flesh it out completely when someone is explaining something to me. I like details, no matter how long it takes to get them.
- Agree there is some bugs that don’t need demoing
- Hard to know which without domain knowledge sometimes but can learn the lines on the job – see what prompts devs to come over to you to ask
- Stopping the demo train – call a meeting? Demo to everybody at once? Ask what’s missing from the defect? Email chains?
- I have a habit of overthinking decisions and so arming myself with lots of reasons for why, which then turn into a massive response when some asks ‘so what are you doing with x?’ when all they needed was my decision
- Over-thinking the solution
- Big picture thinking vs small picture thinking (Hammer/Nail problem for some people while for me it’s more “Why do I have a hammer?” or “Are there only nails?”)
- Writing and Using examples and stories in writing (My current business card says Quality Storyteller)