Test Automation Day 2018

I got a free ticket to Test Automation Day in 2018, just after I'd moved to Rotterdam. I was overwhelmed by the confluence of events: Angie Jones keynoting, Ard Kramer running the show, and meeting Amy Phillips in real life. (Neither of us were sure it was the first time we'd met because we'd been following each other on Twitter for so long!)

My most shocking note from Angie's keynote is "clicker, no notes," because of course Angie had her talk down pat. In a talk that anticipated the current, urgent conversation in AI and machine learning, Angie recognized that we can't agree on what human ethics should look like. Figure out who you're advocating for, and tie the bugs back to that business value. You're not going to be able to define all the business requirements up front; expect the unexpected.

Amy Phillips spoke about how tests in a DevOps environemnt allow you to get fast feedback. Like Agile, this style of working is not about minimizing the pain and struggle in developing software, but rather about bringing that pain forward. DevOps allows us to become aware of problems sooner, so we can act on them sooner. Running more tests is not necessarily better. Do not accept flaky tests. Free yourself from an overreliance on end-to-end tests and tests that cover non-critical paths to get your build time down. Rather than running tests on every commit, improve your monitoring.

I've got some quotes from other talks and the panel that day:

  • "A tester is someone who believes things can be different." ~ Jerry Weinberg
  • "The team was not mature enough to determine priorities."
  • "Maintain the relationships you want to build."
  • "Are you just doing it because you can?" (regarding UI automation)

I can't tell everybody how welcome and in the right place I felt by being able to jump in this day on short notice.

Start With Belief

Imagine a scenario where you find a software bug. You go to another colleague. They perform the exact same reproduction steps you did. But the bug doesn't happen on their machine. What now?

Works on my machine

Your colleague may not believe you found a bug, or they may not be sure if you did. They may blame you for doing something you shouldn't have. They may insist that most users have a machine more like theirs than yours, and it doesn't matter if it doesn't work on your machine. They may think it's too much trouble to track down what's happening on your machine, and leave the burden to you to figure it out. They could have a fixed mindset, and think that you, your machine, the software you're running never change. (Read more about fixed vs. growth mindsets in this brilliant Brain Pickings article.)

Does not work on every machine

Instead, they could have started with belief. They could commend you for uncovering something they themselves could not. They could be curious about how your machine and software are different from what they have running, and look into how many other users this is affecting. They could pair with you to come up with ideas about how to stop the issue from happening. If they have more access to the underlying systems, they could look into the code and configuration settings. They could have a growth mindset, and think that your machine, the software you're running, and most of all you, can change.

Start with belief

Now, imagine a different scenario. Imagine someone describes being mistreated by the police. They were doing something that is fully within their rights, and the cops said they weren't allowed to.

I believe you.

Start with belief. Do not think that because you've had different interactions with the police, that the police must not treat people in the way you're hearing. Do not think that your individual circumstances, particularly the color of your skin, means that you'll be fine. (Think more about how racism is fascism applied to a particular category.) Take the time to shut up, listen, and discover how you can help. Believe that things can change. It starts with belief.

Joe Brusky/flickr