One of the things Paul Grizzaffi said as a lead in to his Automation Challenges Roundtable was "this will *NOT* be covering how to use Selenium!" With that, I was sold for where to spend my last session.
What's nice about this session is that it's not a presentation per se, it's a group hug, in the best and nicest way I can say that. Since this is a open mic flow, we'll take it as a question at a time approach:
How Do I Communicate the Value of Our Automation?
I'm fortunate in that I work for a company that has a robust and long serving automation platform. IT's not very modern, and its not always pretty, but it works well and has for a long time. Most of the tests pass most of the time, and truth be told, there have been a few times where I wondered if our tests were really valuable... until we actually caught regressions that saved our butts. To that end, having the automation in place was tremendously valuable, so I'm not sure what I would suggest beyond making sure that you report your results regularly, highlight where the tests helped with finding issues, and encouraging continued work on automating new features as they come.
Different Personalities in the Automation Pipeline
It helps to have people with different experiences and viewpoints, but that opens up some additional challenges. People develop in unique ways, and different people work in ways that may or may not be optimal for others. Short of isolating everyone and having them work alone (i.e. what's the point?), encourage each member to communicate how they like to work. We may not be able to resolve everything, but helping each other understand our best approaches will certainly make it smoother.
Requirements, BDD and Code in One
The desire to have business requirements, BDD language and code in one place is doable, but it's tricky. Test Rail is an approach that can front end the business language, yet still minimize the duplication. Bigger question is "how can we get the group to work together with a minimum of duplication?" The unfortunate truth is that the more specific we make something, the less flexible it becomes. Seems a good potential product :).
Helping Teams Not Go Rogue
Everyone has their favorite framework or methodology. What happens when there are several tools in use and different technological requirements? One suggestion was that everyone knew how to run the tests, regardless of the tools required. Spreading the knowledge helps encourage looking for synergies. We may not always be able to pick a unifier, but over time, learning from each group can help either draw projects together or at least determine which areas must be separate for technical reasons.
---
...and with that, we bid adieu to STP-CON. Thank you all for a terrific week, and thanks for bringing the conference to me this time :).
No comments:
Post a Comment