TestBash SF 2018 Recap: Day 1

California’s first landing of the well-known TestBash conference happened in San Francisco’s Marina District at the Cowell Theater last week from November 8-9th. TestBash, a product from the Ministry of Testing, is known for its single-track talk format where each presenter addresses the entire audience. Talks range anywhere from 30-45 minutes which means that attendees get a large quantity (and usually quality) of presentations by the end.

Breakfast, coffee, teas, sodas were all provided and lunch was pretty good for being delivered in a box (or if you got a special meal it looked like salads were also available). WiFi was spotty but for those who weren’t from the US, there were a limited set of portable hotspots for helping out. Nearly half of 500+ attendees to TestBash were new to San Francisco and at least three quarters of the audience were new to TestBash (including myself).

I was lucky enough to attend and for those who have flirted with the idea of going to TestBash here’s a recap of what happened.

Day 1 Presentations

The days are full but the time is well spent. As with many conferences, there are before and after conference events that I’ll leave someone else to cover. Here are the presentations from Day 1:

Elisabeth Hendrickson on “Influence > Authority and other Principles of Leadership”

@testobsessed
Elisabeth is well known in the testing and quality communities for her many contributions, including the Test Heuristics Cheat Sheet and her amazing book Explore It. She doesn’t do many speaking engagements anymore, but came to TestBash to support the two main organizers of the conference (Angie Jones & Ash Coleman). Her presentation was a series of stories about leading by example regardless of your position or title. Everyone has agency, the capability to make your own choices as an individual, and with that agency you have influence. Often the way you create and build influence is by doing little things and letting them build up over time. Another way to build influence comes from providing positive feedback, which is a more powerful force for change than criticism. To provide feedback you don’t have to be nice, but you should be kind. There’s a difference: Nice is passive aggressive, smiling, and saying backstabby things while kind is being honest when it’s hard. (For more on this subject look to the book Radical Candor).

Jasmin Smith on “Going Undercover in the Mob: A Tester’s Mob Programming Story”

@jasmintestscode
This was a really valuable experience report on joining a Mob as a tester with a not so strong technical background and dealing with her eventual feelings of imposter syndrome. After a few working meetings Jasmin began to question what value she was providing to the team and then withdrew. After noticing she missed several sessions one of the programmers from the mob asked her why she left. They had a conversation about the value she did provide such as asking great questions, building out mental models of how the whole system worked, asking product related questions when the product manager couldn’t make it and it turns out she was sorely missed. She went back and now her only regret is that she withdrew in the first place.

Adrian P. Dunston on “Tester at the Table and Tester in My Head”

@bitcapulet
Adrian had this great visual and storytelling narrative about how the testers he’s worked with have influenced him in such positive ways that at times he can hear their voices in his head asking him questions and making him work better. He laid out steps for others to do this as well, which would lead to improved overall quality of our applications. The 4 steps Testers could take were:

• Repeat Yourself. Have catch phrases around the lessons you wish to impart
• Make a Deal. If your Developers and Testers help each other, your Developers will help protect the Testers and Testers will help make the Developers look good.
• Argue, Correctly. You’ll have to deliver bad news that no one will want to hear. Make sure you can frame the issue well and in those circumstances where no one listens, allow them to make the mistake. Then show them how to not repeat it in the future.
• Promote Yourself. The hardest step but really the easiest is to just repeat yourself to promote yourself.

Rick Clymer on “Climbing to the Top of the Mobile Testing Pyramid”

@clymerrm
Rick was introduced to the idea of The Mobile Testing Pyramid through a post on the Elemental Selenium list written by Kwo Ding. When it came time for his company to develop a new mobile application, they used the mobile testing pyramid as a model to guide their development and testing in an effort to reduce the cost of testing and improve quality. The Mobile Testing Pyramid (inspired by Mike Cohen’s Test Automation Pyramid) consists of 3 levels:

• Browsers. For non-native apps, browsers (and browser tools) are where you do the vast majority of your testing. The goal is to stay off the other levels until you are reasonably comfortable with the way things work here.
• Simulators / emulators. The cheap and easy way to get the look and feel of a real device with the added benefits of local builds and easier debugging.
• Real devices. As close as you’ll get to testing in the wild and working with the software in the way your customers will.

Paul Grizzaffi on “Extra! Extra! Automation Declared Software!”

@pgrizzaffi
Paul put a stake in the ground and declared automation software is real software and needs to be treated as such. (Of course!) Since automation software is real software, it should be fit for purpose, be subject to coding standards, come with relevant work items (such as programming tasks, code reviews, etc.), be designed to have minimal maintenance, come with an appropriate level of documentation. Automation specifically gives us results and those results should be actionable, understandable, and available. Storing automation results and then making them actionable is very good advice.

Richard Bradshaw and Dan Ashby on “The Power of Models”

@FriendlyTester & @DanAshby04
A fun and collaborative story on the use of visual models to help communicate difficult concepts. Models are an interpretation of what we think; we codify them in different ways, but we all build them. Most of us don’t draw our models, but if we did, we could share them, get feedback, and improve. Once such model shared by Richard is the above Visual Task Analysis that shows the way an end to end test hits different seams or layers in the application. When it comes to communication, some people are good with text, others are better with conversations, while still others are more visual learners. Most of us are comfortable with text and verbal communication, but why not take the next step and draw out our mental models to help those visual learners?

There were a lot of presentations for the first day but I left with a few key takeaways. First, I should draw or diagram out more of my mental models and socialize them for feedback both internal to my company and external to the greater testing community. I’m missing out on educating and learning by not doing this. Two, I need to find a way to store and make actionable my automation results. Three, I’m super interested in trying a mobbing session. Lastly, I’ve taken to heart Elizabeth Hendrickson’s advice: Positive feedback is a more powerful force for change than criticism.

Stay tuned for Day 2.