The best training I've received to be a researcher wasn't at an industry conference or workshop, and it was before I’d even heard the phrase “usability testing.”
Many years ago, I got a campus job as a student at Grinnell College. We were called UCs, or User Consultants. We worked at the Helpdesk, which students and staff alike could call or drop by for help with their computers, and we staffed each computer lab, so there would always be help in easy reach.
The whole program, from the training to the work, was based on one, surprisingly innovative principle: Anyone can learn how to use a computer, if they are given the patience and information they need.
To become a UC, you didn't have to have any prior computer knowledge, because the first semester on the job was training. We worked shifts with UCs who had completed their training; we attended presentations about new topics; and we worked on projects that had a charming name I have forgotten, but it included "doc" for "document."
The projects were Word Documents where we answered questions designed to get us to problem solve. (This was in the days before Google Docs came out, if you can believe it.) Our textbook was the Internet, and we were encouraged to use it to troubleshoot the problems that were described, or in some cases, shown with screenshots or photos.
"I lost the charging cable for my camera. What kind should I buy to replace it?" one problem might state, accompanied with a photo of the camera and corresponding port in question. (And, yep, this was the time when a student was more likely to have a digital camera than a cell phone.)
Something that took several projects for me to finally remember was that we were also encouraged to ask for help. We didn't have to solve problems with just our wits and some Googles (which was definitely not a phrase yet); we could also ask the very people whose work we were training to share, and they were delighted to point us in the right direction.
That's where the other part of anyone can learn showed up: UCs wouldn't solve computer problems for you. They gave you just enough information to empower you to solve it yourself. One of my mentors often said that if we were doing our jobs right, eventually we would make our jobs obsolete.
When someone would ask us a question, we would respectfully stand to the side of their screen, and ask them what they'd tried, and then describe to them where to look next. "See the menu up at the top of your screen, try looking under 'File.'" We'd never take the mouse, and we'd even delay pointing with our hand, if we could manage it. They'd pause, then hesitantly drag their mouse pointer to the corner of the screen, click on the menu option, and say, "Oh, 'Print!' There it is."
Once I started training at the Helpdesk, the troubleshooting got even tricker. We'd do it entirely over the phone.
After the person told us why they were calling, we'd say, "Tell me what you see on your screen," and rely on them to give us the information we needed to give them the information they needed. If we had access to the kind of screen controlling software that so many help desks use today, I don't remember needing to use it.
All of this time spent troubleshooting software alongside the people who needed the help gave me the patience and words I've needed to conduct usability tests as a researcher. I know that even the easiest software can give someone trouble, and I know that even the hardest software can be learned. The most difficult part of all of it, though, is becoming the person who is willing to make that space for the person who is doing the learning.