On the 8th January, Jesper Ottosen will spend an exciting hour on The Club tapping away on his keyboard answering any of your questions related to Coaching experts & end-users to participate in testing. Ask your question to get it answered.
Looking forward to answering your questions around motivating experts and end users to participate in testing. Motivation and coaching goes for all team members, but there are some things to consider when the people doing the testing are from outside the team or not even “testers” You could ask me about:
- What experts and end users can help with
- Motivation tips and tricks on how to motivate the experts
- How is it different compared to motivating team members
- The language used to communicate - e.g. testing vocabulary
Get your questions in here before January 8th at 7pm UK Time, and I’ll answer as many as I can in the Power Hour. Also join me at Test Bash Brighton 2020 to hear my talk: “How to Coach Subject Matter Experts to Do Testing”.
The priorities of experts and end users tend to be different from testers and developers. How does this affect the testing that is carried out?
Question on LinkedIn: Shouldn’t there already be at least one SME on the testing team?
Is digital communication with the end-users and experts sufficient or is it essential to interact with them in real life?
I’ve worked in places where end users were our beta testers. They were fully aware that it was a beta product but got frustrated when they found issues.
How do you deal with those frustrations to ensure that those users still want to participate in the testing?
What have you found to be the most effective way to collate information from end users who are also testers?
They can’t necessarily log into Jira to log a bug I’m interested to know what methods you use for streamlining end users logging bugs and collating their feedback.
Good point @lgibbs!
First of all experts and end users often find that their “real” job is the most important activity. Imagine a nurse saying that helping patients is more important than helping the project. Or a network technician resolving production issues. Often I have seen that even if they have been “formally” booked full time to help with the testing, they have to do their real work after helping me.
Secondly they are not testing professionals (and might not even be IT skilled), so proceed cautiously wrt. testing terminology, testing tools.
So what to do: take one step at the time especially wrt test case tools or trackers. Respect their business know-how - and make it easy for them to contribute. Sometimes I don’t even give them access to the test case tools, but do that part for them.
Tricky one. What is the role of the testing team to you? Is it all the “people” with the title “test” or all the people doing testing (as an activity) in a project/team?
I prefer to have people that experts in the system under test in test team of the delivery/project . Sometimes it’s “pro” testing persons that have proxy-product owner skills, sometimes it’s a end user , sometimes its even a technical specialist.
who is the “tester”?
Welcome to the club @sinkcup! Great angle!
Real life interaction is preferable, especially initially when they are learning the activities and tools of the testing activity. The initial phases is all about expectation setting, that’s easier in person. Sometimes this is not possible, so communicate in a more “loose” daily check-in, rather than a strict status call.
I would also like to mention that tell them it’s a journey and work on making them self reliant in the testing activities. Create the first bug for them, but let them submit the remaining.
When they are happily testing and updating test trackers etc, digital communication is … more easy.
Indeed @heather_reid , I have been in that situation too, and gotten heat that partial things where “not even working”. That I was wasting their time etc etc.
So first, I guess, “bugs happen” that they find stuff is what we want. We want them to find the things only their skill set can find, not the trivial stuff. If you can get to decide, arrange the test effort accordingly. Automate most trivial & fact based, perhaps explore yourself first and then put them into play for the tricky bits.
Secondly set expectations, and walk them through it initially. And just before they have testing to do, so they don’t forget. "Dear Nurse, glad to see you for the test session today. Here’s the deal… you do this … and this, and if anything comes up - ask."
There are no silly or stupid questions when you are learning.
btw this one might interest you:
We added automation for 75% of the test, but that made the business unhappy… imagine…
Exactly! So it’s a continuum… sometimes I want them into jira et.al., because they are testing over a longer duration of time. Sometimes it’s more of a “one-off” where they test once or twice. For IT staff I expect them to dig into the tool and learn it. On a current project the testers are factory assembly line workers, so they pass on Jira.
Still though I want them to test and report back on the findings, and sometimes with screenshots (for bugs and compliance). So that’s on me to register test results “on behalf” of them. So that could include dusting of an old excel/word template for a test case… perhaps I should look into other capture tools or train them in exploratory test note-taking tools…
it’s all about expectations and context really
Btw - they are just trying to help, even if they make a fuzz.
There’s a model called “management of primadonna’s” that I will look into in the talk
Darn, I spaced this out and I think the Hour is over, but it can’t hurt to try. I’ve known teams where they were able to get the biz folks to do some testing by having the testing session as part of the “sprint demo” type thing. Demo what was done last sprint, have some workstations/laptops set up to test something that is still underway, or either, mob on that. I have never been able to make that work, people just want to leave after the demo. Have you tried anything like that?
Hi @lisa.crispin, I’ll reply anyways
I like the ideas around mobbing the features instead of the classic “tester-dev” collaboration. Will have to try that my self someday.
When (biz) people that come into test for/with your team, could you reframe the day/session? To be both about demonstration (and demonstration by dev team only) of latest sprint (finished work) - and about hands on testing features (demonstrated and upcoming features)?
interesting that they want to leave right after demo - what drives that behavior? and how can we motivate them to stay?