We talk a lot about the value and benefits of test automation, but we don’t always discuss those nitty-gritty, practical tips and tricks that can really help you when you’re in the trenches. So, bearing that in mind, here are some tips we’ve learned along the way to help you out on your next project.
|
For someone who’s seriously considering test automation, value props and flowery prose can only go so far. |
Over the years, I’ve written a lot about test automation. Whether its “Freeing Your SMEs”, “Discussing Developers”, or “Breaking Thorough the Regression Bottleneck in Agile”, I’ve covered a lot of ground. But there is one thing I haven’t really touched on: how to get started.
That stops today.
For someone who’s seriously considering test automation, value props and flowery prose can only go so far. As any thorough customer knows, if you want to know how something really works, you need to hear from the folks that are using it. Unfortunately, though, solutions like HP QTP, Oracle OATS, and Selenium aren’t on Amazon; so finding customer reviews (that aren’t dripping with third-party bias) is not a trivial exercise.
In response, I reached out to some of our automation experts on staff, folks who know more than I could ever hope to on the subject, and soaked up as much information as I possibly could. Those findings, in turn, were distilled down to some very valuable “tips and tricks” of the test automation trade. Think of them as a veritable cheat sheet to a smooth, successful, test automation engagement.
Have a Project Champion:
When you first get started, the most important thing to do is make sure that you have an individual who can help knock down obstacles that may pop up over the course of the engagement. More than anything, this person needs to be completely bought-in. Automation is an investment, and while the company might be merely testing the waters, the project champion needs to wholly understand the values of test case automation, and be ready to vouch for those afterwards to secure continued investment.
Skepticism is good when it’s holding the purse strings; but on the front lines, it can be devastating.
Know What to, and What Not to, Automate:
The real value of automation comes from full-scale realization of its utility. After all, automated test scripts don’t just work more efficiently and save employee time; they enable much more comprehensive test coverage. Therefore, it’s best to go after this “sweet spot” of automation first. Things like static and repetitive tests, data-driven testing (a realm which can fully leverage the full benefits of automation), load and performance testing, regression testing, and smoke testing are all viable candidates. Conversely, tests that rely on subjectivity aren’t suited automation; they’re much better left in your SMEs’ capable hands.
You’ll never be able to automate everything—but by drastically cutting your SMEs’ testing responsibilities, you’re still empowering them to focus their attention on other profit-bearing projects.
If Your Test Cases Aren’t Up-to-Date, Your SMEs Are the Gatekeepers:
Test automation may benefit no one more than the SME, who is typically tasked with executing the bulk of these time-consuming, monotonous test cases, but they also have more skin in the game than anyone else. If your test cases aren’t written down (or aren’t current), your SMEs will need to help the automation engineer understand exactly what the script they’re writing needs to do. It comes as no surprise then that your SMEs will typically need to devote at least some time to the automation effort—their prodigious knowledge makes their presence vital.
Just as it is with anything else, time is money. Bearing that in mind, be sure that your SMEs are ready for their script-writing sessions and effective at transferring their knowledge. After all, you don’t want to waste their valuable time—or the automation engineer’s.
Make Sure You Have Access Beforehand:
I know this one sounds obvious, but it’s something that’s frequently overlooked before project kickoffs. Before everything gets moving, figure out everything that will be utilized by the test scripts you’re targeting for automation, as said scripts should be written in a controlled instance that represents your current or future production environment. Aside from the obligatory tool licenses, you need to make sure you also have access to all relevant databases and applications that interface with your test environment, as well as anything else that will be accessed when test cases are run in a production capacity.
There’s an old adage that comes to mind here: “Prior perfect planning prevents p*ss poor performance”. I can think of few examples that better illustrate this than test automation.
In short, there’s a lot of good that can come from test automation (the ROI can be particularly stupendous), but all of that good can potentially be for naught if you don’t implement it successfully. Granted, any third party worth their salt should be a more-than-capable guide (feel free to drop us a line if you have any questions), but it’s always best to know beforehand.
Besides, there’s always value in hearing from those who came before you. After all, they learned these lessons the hard way so that you don’t have to!
Cheers,
Mike Hodge
Lighthouse Technologies, Inc.
Software Testing | Quality Assurance Consulting | Oracle EBS Consulting
