You’re reading the last post in a series that’s intended to get you and your teams started on the path to success with your UI test automation projects:
2. Before You Start
5. Look before You Jump
6. Automation in the Real World
7. Improving Your Success (you are here)
Important note: After its completion, this series will be gathered up, updated/polished and published as an eBook. We’ll also have a follow-on webinar to continue the discussion. Interested?
As you move through (or finish!) your first project, you should be looking to get as much feedback as possible. Constant feedback and learning
First and foremost, go back and ensure you're actually contributing value to solving the problems you decided you needed to address. Have your automated tests help shorten your release cycle? Are you better able to handle your cross-browser/cross-device testing?
Most importantly, do your stakeholders and sponsors feel they're getting better information that helps them make more informed decisions? Remember: your automation work (all work, really) should be tied directly back to concrete business value in some form or another.
Retrospectives take many forms and can be run many different ways. Esther Derby's and Diana Larsen's Agile Retrospectives is a great resource on how to run retrospectives. The Art of Agile Development from James Shore and Shane Warden has a terrific section on retrospectives we've used as a template for many organizations.
Regardless of how you run your retrospectives, you'll be gathering up concrete, actionable topics to address. Many of those may be negative issues; that's fine. Of
Early on I mentioned the importance of involving your support team in identifying addressable problems. Keep them looped in! Make sure you're talking regularly with your support team, to see if there are aspects of your system you need to shore up with other UI automation. (The best thing, frankly, would be to have support in your retrospectives.)
Take advantage of your support team’s role as the frontline contact with disgruntled, upset customers having problems with your system. Not only will you get great information from them to put back into your feedback loops, you'll also help ensure they're feeling validated and understood.
It's not enough to simply identify what you should be doing more or less of; you need to share lessons learned as widely as possible. Getting information out to various teams can be challenging, no matter the organization's size. Look to leverage as many different communications channels as possible.
If your team isn't already, start regular “lunch-and-learn” or "brown bag" sessions during which your team can discuss problems, share resolutions they've learned or simply brainstorm different approaches. These shouldn't be overly formal meetings. Keep them casual, but try to get some rough agenda a day or two ahead—asking participants to put Post-It notes on a board to share their ideas is perfect.
Get your lessons learned, code snippets and solutions to problems in some form of searchable, preferably editable online system. Use a Wiki or an organizational Evernote account, but use something! Don't spend your time building something custom—there are far too many products already available.
These knowledge-base articles should cover topics such as how your UI automation project is set up, what it takes to build/run/maintain tests and how to solve particular challenges in your system. Have some tricky asynchronous actions? Write an article explaining how you resolved that. Did your developers build an API helper to handle custom queuing that locks the UI? Write an article talking about how to use that method.
At this point, you’ve likely made some significant progress toward solving the problems you identified at the start of your effort. Don't sit on those successes; spread the word to the rest of your organization so they'll adopt and adapt the approaches you've used.
Get five or ten minutes on the agenda at organizational and cross-departmental meetings. Or, write some short articles for a company newsletter. Don't dive too far into the weeds; just set the hook. Your true purpose is to get people outside your team coming to visit or talk with you. You want curious co-workers to see the improvements you've made, as well as some of the struggles you've gotten through.
It's important to make sure your stakeholders approve of the time, effort and money you're investing in your UI automation suites. Are they seeing more useful information regarding the state of the system? Are they able to make better decisions about when to release and when to hold back?
If the answer's "yes," your effort has been well placed!
We hope you've found this series helpful and a great use of your time. Our intent hasn't been to lay out "best practices" (THERE ARE NONE!) or specific answers to specific problems. Every team's situation is different environmentally, technically and culturally. Instead, we've tried to lay out broad guidelines that are common across every UI automation project we've worked on:
Teams all over the globe have had tremendous success in UI automation, despite its myriad challenges. Your team certainly can be among those!
Jim is an Executive Consultant at Pillar Technology. He is also the owner of Guidepost Systems. He has been in various corners of the IT world since joining the US Air Force in 1982. He’s spent time in LAN/WAN and server management roles in addition to many years helping teams and customers deliver great systems. Jim has worked with organizations ranging from startups to Fortune 100 companies to improve their delivery processes and ship better value to their customers. When not at work you might find Jim in the kitchen with a glass of wine, playing Xbox, hiking with his family, or banished to the garage while trying to practice his guitar.
Subscribe to be the first to get our expert-written articles and tutorials for developers!