Strategy
Best practices in software development dictate that before a project begins, a strategy be in place to guide the process. A well-defined and actionable strategy serves as a roadmap for what the software needs to do to adhere to the requirements and provide a satisfying user experience. Implementing a strategy specific to testing helps to ensure that your methods and processes include both objective and subjective evaluation and are planned in a way that best utilizes available resources. Granted, all the software that your company tests will not necessarily be 100% automated but creating a strategy can help you achieve maximum results by identifying what will be tested, by whom, and through which means.
The organization of resources is the first step in creating a solid strategy. This will help the team stay within scope, on schedule, and on budget which is important not only for your organization but also for your relationship with the client. Appointing a team leader and then identifying who will be on the team should be, on a basic level, determined by each member’s skill set, availability, and experience. Assembling a team of individuals who have worked on similar projects and better yet, have worked on successful projects together pays big dividends. Once the team has been created, they should review the requirements and schedule to identify and resolve issues before the project starts. As well, it’s important to perform a risk assessment to identify where cost and/or time overruns might occur and what type of mitigation strategy should be implemented.
Once that team has been assembled, it’s time to review the testing scope and schedule and determine which tests will be automated and which will be manual. Tasks that are tedious and repetitive should be at the top of your automation list, while those that are complex and/or require a more subjective review, like user experience tests, should be assigned to manual testers. At this point, a testing framework should be created and a process for each testing phase can be documented. With this information in hand, the collective knowledge of the team should drive the implementation of the strategy.
The importance of a testing strategy is confirmed in the Tricentis survey, where the most mature DevOps organizations placed it in the top three activities where testers spend most of their time. Conversely, in less mature organizations in terms of DevOps implementation, test strategy doesn’t even rank in the top five most time-consuming activities for the testers.1
As more organizations move toward an agile methodology, they find that automated testing and subsequent feedback can be accomplished more quickly and more often which means that creating and adhering to a rock-solid strategy is important. Application teams or business units should be thinking quality-first from the beginning of the project and determining what that will look like through numerous iterations of functionality that are outlined in the requirements document, as well as any new functionality that is added during development.
Governance
Managing quality has changed massively over the past years. The number of QA teams is decreasing over time as the quality is being overseen within the application teams directly. Even though these teams operate independently without having to justify their work, there is still a strong need to ensure consistent quality across the whole application portfolio. That’s why proper governance that also covers guidelines and best practices has increased in importance. Execution of quality gates to carry out regular checks of adherence to given standards and guidelines is an additional instrument for assuring quality. It brings benefits especially in highly regulated industries like pharma and banking.
The foundation of your testing program should include a governance document—a set of guidelines by which your team operates its automated testing operations. Though each project will be different in scope, the processes by which you execute testing and the standards to which you adhere should stay relatively the same.
The governance document is one that is dynamic and evolving based on new technologies and lessons learned. While certain elements remain static as part of best practices, changing methodologies, and/or testing improvements can yield rationales that save time and money. Developing a test library for frameworks and cases, for example, can lead to increased efficiencies on future projects which may become a best practice. Team members can bring new insights that positively impact parts of the testing practice or even the process as a whole. Looking at your governance document as a living document is important to discovering new and increased ways of improving your testing process.
Demonstrating consistency in your testing program through a governance document saves time since new processes don’t have to be created with each project, enables new team members to get up to speed quickly, ensures everyone is on the same page, and sets an expectation for excellence. Foremost, a good, automated testing governance plan commits to include testing as part of the software development process and not a separate, detached process.
Maintenance
Automated testing brings a lot of benefits to software development, but there also exists the issue of maintenance: What do you do with the tests? Studies show that test automation engineers spend almost half of their time maintaining the inventory of automated tests, which is clearly not a good use of their time, but there are some solutions. Though many automated tests can be done at varying levels throughout the software development life cycle, it doesn’t mean your team needs to use all of them. Teams that are new to automated testing or teams that are having a difficult time managing their inventories should, during strategy planning sessions, choose only a few tests like those for highly vulnerable areas or for more complex areas, for example. And remember, automated testing isn’t an all-in-one prospect; teams can integrate slowly and continue with manual testing until they have a handle on maintaining test inventories.
Well-maintained test scripts can have some additional and probably less expected benefits. They can serve as a detailed documentation of the application. A clear and easily readable test script will help the new automation engineers understand how the application is supposed to work which will make their onboarding easier and faster.
A big part of maintaining test scripts is simply seeing what you have. Performing a thorough audit of test scripts will help you decide what can stay and what needs to go. Much like cleaning a closet, it’s not much fun but it’s such a good feeling when it’s done. Creating test suite libraries is a good way to get organized and it serves as a quick go-to resource that, with static naming conventions can be easy to find regardless of who is accessing them. Another good maintenance tip is to develop a plan for retiring obsolete scripts and test suites. That way, when you do an audit, you’ll have a plan for determining whether to keep them. Like adding automated tests to your development process, maintenance doesn’t have to be done all at once, but keeping up with it will save you time in the long run.
Choosing the right tools and tests is important but their effectiveness will be diminished if you don’t execute test automation best practices. A comprehensive testing program contains three of the most essential best practices including a strategy to guide your processes, a governance document for outlining your policies, and a maintenance plan for identifying which tests and test scripts you will keep and why. Much like a car, if crucial parts are missing, it won’t run as intended, and it certainly won’t get you where you need to be. Carefully following testing best practices will only make your efforts more efficient in the long run.
Automators can advise you on best practices for your automated software testing program. Contact us: https://www.automators.com/contact
Reference