Automation testing seems like a no-brainer when you consider all the apparent perks it promises — like doing what humans do at a fraction of the time and cost. Even smaller companies will jump at the chance to realize significant savings on both these fronts. However, change comes with its own set of costs. And the only way to mitigate the effects of these costs is through the hard master of experience. Of course, you can simplify and de-stress the experience by implementing our best practices. We've seen these snafus come up time and again through nearly a decade of assisting software companies on large-scale projects. Our 10 steps are a direct response to these way-too-frequent pain points. In our experience, automation testing brings a score of benefits, including: \tContinuous testing and the running of tests remotely, which perfectly match a continuous delivery model \tFewer human resources: A singular individual, such as one automation engineer, required to write scripts that automate tests \tBeing able to write reusable scripts \tTargeting bugs early on in development so you can spend less time and working hours fixing them down the road \tMore reliable results than manual testing \tTesting across more devices and environments, simultaneously \tEasier for automation testers to ensure continuity, as one individual can take over the other’s work through clear reports It’s the height of frustration to miss out on these benefits simply because you’re not setting your team, testers, and scripts up for success. Follow and implement these 10 steps to faster, smarter, and more cost-effective testing standards to realize these benefits. 1. Harness the “Zone of Genius” Before you get into any of the technical aspects of test script writing and maintenance, you need to set up your “people” architecture. Getting the right individuals working on the right features will set you up for success. \tManual testers need significant time learning and onboarding before they can become automation testers. \tGood structure and programming guidelines eliminate the need for all automation team members to be programmers. \tAssign a senior-level programmer from the dev side of the project to create this guidance and structure. This is the right individual to train the QA team in script generation. By supporting everyone in their own specific “zones” of genius, you’ll be able to ensure there’s no overlap, or, conversely, a fracture of focus. 2. Build High-Quality and Maintainable Scripts Automation testing means you can save time and trouble down the road. It also means you create value for your end-user by developing high-quality and maintainable scripts that can scale across projects with a few simple tweaks. However, you need to invest time and resources upfront to create these scripts such that they are maintainable. Quality automation test script writing is like a development project that requires its own coding guidelines. Especially with multiple team members, you’ll want coding standards. Additionally, a test automation effort requires its own dedicated testers or else allocate specific days where programmers are focused on writing nothing but quality scripts. 3. Adopt a Perpetual “Work-In-Progress” Mentality Agile development principles privilege shipping fast, delivering continuously, and iterating in an ongoing manner. You should be taking the same approach to your test scripts. Like products themselves, automated test scripts need to be maintained continuously. \tAutomation testers should anticipate and create adaptable scripts with an architecture that follows programming guidelines early on in the process. \tStructure and guidelines should include parameterization and abstraction, as well as conventions for variables, constants, modules, functions, and file names. \tDevelopers should be notifying automation testers about changes to the interface or logic of the product. \tAlways keep your test script’s scope as small and narrow as possible. It’s easier to have a master script call on a set of smaller scripts. \tScripts should churn out a specific error message so you can easily trace back where and why it failed. 4. Simple is Beautiful When scripts become as large and complex as the source code, testing and maintaining become complicated. You may be tempted to write a single test script that checks for multiple functions. Not only is this difficult to modify, it’s even more of a challenge to troubleshoot — and that defeats the purpose of test scripts entirely. Instead: \tBreak down test scripts into the smallest possible “packets” so that each is easy to understand and limited to one specific function. Complicated features should be broken down into sub-features. \tTests should be independent. Pass/fail results can only be verified if scripts can run without dependence on other scripts. \tHowever, scripts can be dependent on the setup of the program, so design a set of scripts for a default application environment and settings. \tMake each feature’s test simple by separating them into modules with logical and technical aspects. 5. Environments Matter As Much As Scripts This is common sense masquerading as a “best practice.” Scripts frequently behave differently based on the test environment. Here’s what you need to do to maintain uniformity of testing: \tWhen testing in teams, make sure that all environments match each other, including hardware and software. For best results, use a clean machine where the only functional aspects are the OS, automation software, and application that’s being tested \tWhen writing, make the script portable so you can execute across environments and machines \tCreate a list of pre-requirements for a successful script run 6. Manage Expectations Early and Often Automation testers occupy a tricky, middle-of-the-road position. They’re not part of the dev team, so they’re not focused singularly on producing source code. They’re also not entirely part of the management team, though they do need to communicate, in plain terms, what they need for test automation success. This strategic position means that it’s up to you, the tester, to educate management on the realities and limitations of automation tools. \tStart by finding an open-source version or trial version of the tool you’re using to learn more without extra cost \tEducate everyone involved about the limitations of automation — it can’t replace manual testing entirely, but it does significantly reduce time, so testers can focus on digging deeper into issues \tStart writing scripts and experimenting with functions as early as possible \tCommunicate the purpose of record-and-play as reference points \tStart conservatively with a specific percentage of automation coverage keeping in mind that not all manual test cases can be automated 7. Master the Application’s Logic First Test scripts only work if your testers have a thorough understanding of the application’s logic, features, and functions. Misaligned scripts will cover the wrong functionality or focus on unimportant features. That leads to a misallocation in time and even the concerted efforts of testers. Quality always wins over quantity for automated test scripts, so: \tLearn the in-depth nuances of the software’s operations and business logic — this is integral for developing test cases \tCreate a set of screenshots that reinforces learning \tNext, test scripts for viability, confirming that they pass or fail based on tightly-controlled input with clear acceptance criteria \tApply a hierarchical approach of testing prioritizing critical, medium, and low-priority features for automation 8. Develop a Strategy for Tests, Well, Strategically You need a structured approach to testing automation. Without strategically moving through test automation, you risk wasting time and resources focusing on features that fail to make a significant impact on the end-user. Here’s a proven strategy for testing that consistently works for our clients’ projects: \tIdentify and categorize parts of the application that will be “critical,” “medium,” and “low” priority candidates for automation. Priorities are based on utility to the end-user and ease of implementation. Obviously, low utility and difficulty to implement go towards the bottom of the list. \tDevelop test cases that cover operation, which tests for how the application works, and verification, which are the checkpoints to be verified by the automation process \tArticulate test cases before the script-writing/recording process \tCreate an aligned or complementary automation framework to guide your strategy taking into account your automation goals, the number of changes foreseen in your application under test, and your team’s automation expertise. 9. Employ the “Divide and Conquer” Workflow for Test Cases Divide and conquer is a smart strategy that follows the very first “best practice” of getting the right people to work on the right things. When you divide and conquer QA testing, each tester works with a well-defined test scope. Think of this as a tester’s overall project, which can be broken down into smaller test “packets.” As these small test packets or test cases and scripts are re-integrated, they can easily be integrated back into the common structure. Proceeding in this stepwise manner ensures there are no overlaps, poor script quality, or errors in the script that subsequently affect the larger structure. For a successful test case review, ensure: \tTo review the test cases together, so everyone knows which features or functional modules they’re testing. \tThat the team is clear on structure, naming conventions, and abstraction levels \tTo conduct a test script review, catching errors in the script as a team, in an ongoing manner. Just as developers would do code reviews, test automation engineers should do test script reviews to learn together, create camaraderie, and most important; facilitate the writing high quality maintainable scripts. 10. Even Test Scripts Demand Version Control You wouldn’t create source code without version control standards — and you shouldn’t skip version control for test scripts. Testers can attest to the fact that test scripts are integral to successful software delivery as the source code itself. \tUse naming conventions, file history documents, and set standards for comments. \tCreate a management system to control versions of test scripts. This will come in handy when you have larger projects with multiple team members writing test scripts for functionality and varying versions. Native version control can help you keep track of every new element you add and any test scripts your team will create. Your QA process works best when it’s closely related to the current version of the source code. With version control for test scripts in place, you’ll be able to: \tGain knowledge and insight about the expected behavior for a specific piece of code \tReview and accept tests by implementing a code-review process \tBuild a historical log of test scripts, test cases, and changes over time To learn more about software test automation basic guidelines, click here to download our whitepaper.