The CrossBrowserTesting team is back from Berlin, but we can’t say we don’t miss the beer and pretzels — fortunately, we still have pictures and memories from another great Selenium Conference.
Once again, we enjoyed sponsoring and love talking to our customers, as well as people who don’t know us as well. We hope you learned a thing or two about us, but of course, the best part about going to these testing conferences is what everyone else teaches us, so here’s a roundup of our takeaways from Selenium Conference Berlin.
1. Selenium is like David Hasselhoff
Simon Stewart, the creator of WebDriver, started his keynote by talking about no other than David Hasselhoff, ultimately to make a point that good things get better with time. You can probably infer from Simon’s anecdote that he was making an analogy to everyone’s favorite open source project, Selenium. A lot of building it has just been figuring out what’s working along the way, similarly to Hasselhoff’s career. We look forward to it being accepted as a standard by the W3C…eventually.
As far as the current state and future of Selenium, they’re exploring more ways to utilize IDE with more browsers, the Steering Committee has now expanded, and Selenium Grid is at a point where we’re able to leverage it to extract value. All in all, Selenium has a great community and a bright future — proven by Selenium Conference, which never fails to impress us year over year.
2. Stand up for liberal arts
Ashley Hunsberger took the stage to talk about the non-technical side of testing — liberal arts and humanities. When we think of software testing and developing, we often focus on the hard skills that are required without recognizing the soft skills that give us an edge, help define our process, and sharpen our communication.
As current Blackboard Product Quality Architect (and recent addition to the Selenium Steering Committee), Ashley owes a lot of her success to her liberal arts education and advocates that it’s our job to save them. Grammar, logic, and rhetoric may not be the first thing you think of when someone says “software testing” but they’re all required to be a great tester.
When communities devalue liberal arts and continuously raise the price of an education, defunding means putting these studies in jeopardy. Ashley challenges you to consider the skills often acquired from a liberal arts degree like empathy, adaptability, and critical thinking, and apply them to technology fields because “our data is only as good as the people interpreting it.”
3. Test automation is like hockey
There are three things you need to be successful in test automation — just like hockey — according to Katrina Clokie. Those three things are access, skills, and motivation: you need to have access to the source code, the skills to be able to write code, and you need to be enthusiastic about your role. But, when you divide those factors, it creates a barrier to that success.
These factors often manifest into roles including as a teacher, problem solver, coach, inventor, observer, and advocate. Of course, expecting your entire team to encompass all of those factors is a little unrealistic. Instead, you need to leverage the people on your team and understand which ones they possess to impact successful practices in test automation.
When you consider the best ways for different roles to contribute to test automation based on strengths and weaknesses, you can begin to close the divide. However, when you’re missing the roles that are necessary, that’s when you need to start thinking about changing roles or bringing in new people.
4. How not to be flaky
Some things, like puff pastries or your friends, are flaky by design, but your tests shouldn’t be flaky. When your builds are looking like a traffic light with how often they go back and forth from green to red, it means it’s time to look into what’s making them so flaky. Richard Bradshaw proposes to stop blaming Selenium, your tools, and DevOps; stop hiding flaky tests, and start fixing them yourself.
By looking at the intent of what you’re trying to automate, exploring why it’s behaving the way it is, and learning about your tools, you can begin to solve flakiness. Referring to SACRED as a mnemonic device, Richard considers six things to understand how to best design automated tests including State, Algorithm, Codified Oracles, Reporting, Execution, and Deterministic.
Looking closer at some of these, we realize there’s a lot of reasons our tests are flaky that circle back to us — lazy manual testing practices, misusing frameworks, poor knowledge of tools, incomplete data, minimal logging, and bad assertions, to name a few. Asking yourself questions about your automated tests and tackling flaky builds by going back and approaching one issue at a time is the only way you’ll start seeing stability.
These are just a few of the testing lessons we learned at Berlin. To watch all of the amazing speakers at Selenium Conference Berlin, you can go to the YouTube channel for the full lineup and watch the presentations beginning to end.
We look forward to the quickly growing climate of test automation with our favorite open source tool and hope to see you next year in Chicago.
Want to learn how you can get started with Selenium? Join us in Boston on October 24 for our Ministry of Testing Meetup.