Awetest: Test Automation Implementation Best Practices
In the upcoming weeks we will be publishing a comprehensive blog series highlighting our professional experience and findings with the deployment of our test automation framework, Awetest, within a large enterprise implementation. This series will include our methodology for building out automation, code examples, best practices, and the technologies we have developed to address the pains associated with conducting automated regression testing from behind the firewall of a major enterprise. In this blog series we will be highlighting the four main phases we feel good regression automation implementation needs to address: Build, Manage, Execute, and Report.
As the series grows we will be creating an index of the posts in this section for your quick reference.
Section 1 – Overview and Implementation Checklist
Section 2 – The Awetest Approach to Automated Regression Testing
Section 1 – Building Your Test Automation From Scratch – Section 1
Section 2 – Building Automated Test Cases To Stand The Test Of Time – Section 2
Section 3 – Building Your Test Automation to Get the Job Done – Section 3
Overview – Our philosophy of regression based test automation.
Today Software Testing can be implemented in two fashions, manual testing and automated testing. For some smaller applications a good manual test plan makes perfect sense but for mid to large multifaceted applications manual testing is either to expensive or subject to unrealistic time requirements. There are two solutions to tackle the need for more software testing, one is to employ more manual testers or two is to build and implement an automated solution, both of which can be expensive. In many cases, the glaring benefits of implementing the latter are so great that development managers having had little push-back against an automation solution. Curiously, the problem for managers is not whether or not to implement automation technology but how exactly to do it.
Implementing Regression Based Test Automation Checklist (after the jump)
A Poor implementation of regression test automation can result in delivering a sub-standard product and/or a significant increase in the cost of ongoing maintenance:
- Release decisions based on poor data
- More uncaught errors can making it from development to production
- Increased downtime
- Unsatisfied customers
- Brand degradation
- Short shelf life for your automation assets
- Increased maintenance costs
A Good Implementation of regression test automation needs to:
- Be based on thoughtful planning and analysis of actual needs
- Use the right tool for the job
- Help managers, developers, and testers identify defects faster
- Catch all critical errors during development cycles
- Provide actionable results & reporting
- Reduce time and cost of overall testing efforts while increasing coverage
- Provide substantial quality assurance improvements
Unfortunately, Poor Regression Test Automation is:
- Easy to implement
- Hard to discover
- And is difficult to maintain
The Awetest Approach to Automated Regression Testing
Awetest has been architected and built to ensure that all the major stages of the Test Automation process are addressed in a simple, yet comprehensive and scalable fashion. As we have seen, almost all 4 stages are active throughout the SDLS and this document will break down the best practices by each specific phase to formulate a set of guidelines that can be reference during the implementation and across the lifecycle of your Awetest automation efforts.
Build: entails the designing and building of automation scripts and supporting assets and the process of building additional coverage for new and/or existing functionality
Manage: is the ongoing management of the existing test assets to ensure your automation remains in sync with the application being tested
Execution: is the running of the test cases
Report: refers to reporting the results of the testing that was conducted.
Awetest also supports agile-centric technologies and processes. Awetest was architected and built with the underlying notion that test assets can and should be used across the SDLC. Building your automated tests is simple enough for members of the core functional teams (Dev, Business or QA) to build and deploy directly into the Awetest interface. Once setup, all Awetest users have the capability to initiate and report on a given set of tests across a variety of settings (environments, OS-Browser Combinations, etc.).
The illustration below is a good representation of a typical agile delivery engagement and the various functions around the development and QA functions. The goal here is to continually increase the automation coverage (as a %age of the total testing effort) throughout the development process that allows the human resources to focus on more strategic and critical aspects of testing.