TestBash NYC 2015: A Push in the Right Direction

In 2015 when TestBash came to the United States for the first time, it was to New York. I was living in the city, but I was stuck at a job that wouldn't pay for a ticket. "Ask Rosie if you can volunteer," my mentor/sponsor/benefactor Martin Hynie suggested. Rosie, who I knew only as the lady who'd mailed me Ministry of Testing stickers from England for...no reason at all, obviously let me in.

People ask "can we do it?" instead of asking "should we do it?"

~Keith Klain

I got to crash the speakers dinner. I got to go to Selena Delesie's workshop about leadership and change. At the end of the day, she praised my active participation and thanked me for being in her workshop. I was already confident in my testing skills, but she helped me see myself as a potential leader. In a follow-up coaching session I had with Selena about negotiating a higher salary, she asked me why I wanted more money. I'd recently moved into an apartment by myself, and couldn't think of what I would do with more money. It's something I think about with every job change, every growth in title and responsibility. Realizing I didn't want or need more money was a crucial step on the path to life-changing relocation.

The common denominator in all your dysfunctional relationships is you.

~Keith Klain

During a break between talks the following day, I snuck on stage wearing "the" Ministry of Testing tutu. During another, I wrote a bunch of notes to give a 99-second talk about leaving a closing comment on a story (which I completely forgot about, before later writing on this topic for the Dojo). While waiting on stage behind dozens of people waiting to give their 99-second talks, I improvised one about moonwalking instead.

The 99-second talk I didn't give

I met Helena Jeret-Mäe, Maaret Pyhäjärvi, Dan Ashby, who along with the conference friendships I was just beginning to foster, gave me a vision of what my career could be, and where it could go at a time when I knew I needed something different. Helena saw my talk at Let's Test the following spring, and gave me valuable critical feedback that helped shaped future talks. Maaret introduced me to strong-style pairing, which changed the way I worked with my colleagues to this day. Dan had me on his podcast, reinforcing for me the success of my talk at the following year's TestBash USA.

Write down when you receive a compliment. Maybe it's true.

~Helena Jeret-Mäe

Why am I revisiting my notes from this conference six years later? I might be feeling a bit nostalgic for the seeing-people-in-person events a year into pandemic-induced isolation. I'm also in the middle of reading "Becoming a Technical Leader" by Jerry Weinberg. One of the questions asks you to read an autobiography of someone you admire. It turns out none of the people I shared TestBash NYC with have published autobiographies...yet.

When You Can't Help Much, Help A Little

Check that you have time

At my current job, everyone in the R&D department gets a budget of two days per month to spend "crafting," or researching, building, testing, etc. what interests them. Most often people use this time to bring work they're passionate about up from the bottom of the backlog to be worked on now.

I was in the middle of adding a security scanning tool to our CI pipeline when I happened upon something interesting to test: a new web application. An old application that had been widely-used around the company, and as it turns out, with our customers too, had gone down. It allowed you to share a piece of text with a link. The text was only visible once. It wouldn't be viewable subsequent times you followed the link, so the application was good for sending passwords around securely.

The person who'd built the application had left the company. In inquiring about who/how we might maintain it now, one of the customer support leads mentioned in a public Slack channel that he'd built a replacement. "Great!" I thought. "This is the one day I have an hour to test it." I was waiting for code review feedback on my pipeline scan, so it was perfect timing.

Check that the feedback will be heard

It's a waste of time and energy (with the latter being in shorter supply these days) to test something if nobody's going to do anything with the results of your testing. More on that in this post. So I checked with the customer support person first. After taking a quick look at the new application and confirming that it seemed to work, but could use some tweaks, I asked the customer support person in a direct message if he was ready for usability and accessibility feedback.

Me: Hi there, I have a bit of usability and accessibility feedback about the secrets app. Is it at a stage where this feedback would be useful?

Him: Yes, definitely 🙂

Me: Great, I'll send you a Paper doc this afternoon.

Collect the feedback in the same way it will be presented, and present feedback in a way that the audience is comfortable with

As much as I love making mindmaps, I decided that might not be the best format in this case. I doubted the customer support lead would bother to download a mind mapping application, company security restrictions prevented me from sharing a web-based one, and I'd probably want to walk him through a mind map I produced. But that felt like too much trouble for something small, plus I didn't want another Zoom call on a day otherwise free from them.

Instead, I used my company's go-to document tool of choice: Dropbox Paper. I might not enjoy it as much, but I knew it was a way he was used to receiving and collaborating asynchronously. I confirmed that format with him to be sure, and then I got to testing.

Share your oracles (reasons why you have feedback)

Once I opened a one-time link the application created, there was a page with an animated GIF, the piece of text that was shared, and a button to Copy Value. My immediate testing notes were something like:

  • Remove GIF/make it stop rotating
  • Move button to the top
  • Make font bigger

This customer support lead might have just taken than feedback and made the changes. But since I don't have an existing relationship where I provide feedback about his work, and developing applications is not his normal line of work, I provided more details:

  • Animated GIFs (that can't be turned off) can trigger people with epilepsy or motion disorders (vertigo for example). Here's the W3C guideline on this.
  • Move the Copy Value button above the text you're sharing so it's visible even if the text is ~5000 characters long.
  • Increase the font size from the current 14px to 16px for vision-impaired peoeple. The ADA and typography geeks recommend 16, Apple has 17 as their font size.

Now the customer support lead understands why I'm asking for these changes. He can make different decisions than exactly what I've suggested while still addressing the problem I'm reporting. Plus he'll know more for next time he's building something.

Acknowledge the limits of the situation

Somewhat to my surprise, the customer support lead started implementing my feedback right away! He took what I said into account, including removing the animated GIF entirely. He appreciated my feedback and wanted me to look at the application again the next day. Unfortunately, the next day was back to a regular work day filled with priorities, pressure, meetings, etc. I told him I wasn't going to have time to test it again. He went ahead and launched a functioning product.

Move on

While testing the product, another colleague noticed that the application had a larger architecture and setup than strictly what was needed for this particular use-case. Also, the application didn't provide an API for applications instead of humans to be sending around secret links to other humans. I defended the customer support lead: he was doing his best to solve his problem with the tools and skills he had. It wasn't the right time or place to come in at the end of a project that was about to provide value to people (myself included) and announce "this was not the optimal way to build this tool." You don't have to share all the feedback you collect.


The next time you're wondering if you should parachute in to test something new, consider these steps:

  • check that you have time
  • check that the feedback will be heard
  • collect the feedback in the same way it will be presented
  • present feedback in a way that the audience is comfortable with
  • share your oracles (reasons why you have feedback)
  • acknowledge the limits of the situation
  • move on