Formulating a Structured Automation Test Tool Implementation Strategy
Jonathan Doyle
Managing Director at techTesters | 17 Years experience ensuring competent delivery of testing services and resource across Europe
TechTesters have numerous clients who have been involved with the implementation of automation test tools. Although the actual tools differ in functionality and configuration, the implementation strategy has always tended to be very similar. In light of this, we thought the implementation strategy would be a useful topic to write an article on and hopefully generate some useful discussion.
Below we have outlined some of the key thought processes and topics that should be considered when preparing to implement a new automation test tool. No doubt there will be many differing opinions and ideas, so feel free to comment on previous successes, failures and your proven best practises.
Strategy
Well, this really is the first step. If you create a meaningful strategy it will allow you to have focus and subsequently compile a detailed plan. By following a strategy and plan you will have far more chance of reaching a successful outcome. techTesters recommend you consider the sections below for inclusion in your strategy to give you some foundation for moving forward.
Why Do You Need a New Test Tool?
Before you can seriously progress, you really need to be 100% confident in your reasoning as you will be expected to influence others along the journey. So answer the following questions to yourself and then document your answers. These questions and answers are something you should keep referring back to as you progress to ensure you haven’t drifted from your original intentions.
- What is the problem I am trying to solve?
- What are my objectives?
- What is the definition of success?
Does The Test Tool Selected Meet My Criteria?
Choosing the right automation test tool is vital, so listing the various criteria it needs to meet and ensuring it is the right technical fit for the applications it will run against is paramount. You may find that there are some very similar test tools on the market and your Proof of Concept (PoC) could be to evaluate more than one.
Things to consider are:
- Coding Language
- Ease of setting up the framework
- Concurrent Users
- Licensing
- Cost
- Platforms Supported
- Reporting
- Configurations
- Complexity
Costs and Return on Investment
Once you have established the reasons for needing a new automation test tool, and have one or even a few in mind, it is time to drill down into the costing and the return on investment. You will need to seek funding for the tool so justification is going to be required.
- How much is it going to cost to purchase the tool and licensing?
- How much time is going to be saved by the Test Engineers in 3 months, 6 months, 1 year, 3 years?
- Turn that time saved into financials, what is the cost saving?
- How challenging will it be to find resource with the relevant skills?
- If resource skills are in demand will the benefit of free open source tools outweigh cost of specialist SMEs to implement and execute?
Stakeholder Backing
Once you have some costing and benefits, it is a good time to start putting your thoughts to the stakeholders who you hope will give you some backing. A more formal pitch will likely be required later but getting their buy-in from the start builds confidence, and making them feel part of the initiative early-on could pay dividends.
How to Begin Evaluating
In many situations, it has become best practise to implement a new automation test tool on a new or low priority project. It needs a bit of thought to get approach right. Some things to consider are:
- Can I purchase a free or low cost trial licence for a small number of users?
- Will I start using the new test tool on an existing project part way through sprints, or a new project?
- Should I consider running the new test tool in parallel to existing QA functions so we don’t impact project timelines?
- Which Test Engineers would I select to work with the new test tool?
- Who would implement the tool and build the framework?
- Do I need to bring in outside help from a Test Consultancy such as techTesters?
Using the New Test Tool
Once the automation test tool has been implemented and is operational, it needs to be put through its paces to ensure it really does do everything it claims to (and on your platforms), and meets all your current and future requirements.
- Create a list of all the criteria it must meet and tick each item off as they get proven.
- Look ahead to what it may be needed for in the future and see if it supports potential ways of working.
- Look at it from a usability perspective, not just if it is technically sound.
- Consider the skill-sets required to use the tool and administer it. Do you have these people in-house and of the right calibre?
- Involve as many of the QA Team and Developers as possible so they can all experience the benefits, they feel involved and can spread positivity.
Consolidate, Pitch and Demo
Once you have reached this stage, you should have been able to make a thorough assessment to determine if the automation test tool is going to meet your requirements and is worth continuing with. On the basis that it does, it’s a good time to formally pitch it to the stakeholders and other key players.
- Set up a meeting and demonstration.
- Prepare a presentation describing the journey above and what stage you are currently at.
- Highlight enthusiastically some of the key benefits of the test tool.
- Highlight some of the key cost savings.
- Provide an engaging demonstration and pitch it at the right technical level for the audience.
- Be enthusiastic and seek buy-in from the stakeholders.
- Look for them to in principle back you to continue the trial, with the expected outcome of making a purchase and rolling out to the whole of QA.
- Consider future presentations and demo’s as the trial progresses and as more benefits are realised.
Rollout
On the basis that your presentations and demo’s have been successful, and you have authority to rollout, it is time to consider implementing the automation test tool more widely across the tech teams so the Test Engineers can get start using it and can begin to reap the benefits.
- Consider the right time to implement per project or initiative.
- Consider the priorities of projects in progress and make sure not to unduly impact them.
- Ensure Scrum Masters and stakeholders are aligned with your plans and they are ready to be involved.
- Have someone senior back you and promote the work you are doing so people take it seriously.
- Be assertive with your rollout plans; it’s easy for people to keep pushing back and wanting to be the last ones involved.
- Consider who will be the test tool administrator to ensure team-wide usage alignment, configuration maintenance, test script repositories, upgrades etc.
In summary, from the above, you will see that there’s plenty to think about. We clearly won’t have covered everything here, but can definitively say that by planning ahead, having a sound strategy and thinking through the steps logically, you will have every chance of succeeding in an area where in the past there has been a history of wasted time, failure and money!
If you would like to discuss any future project requirements please feel free to call me on 0333 011 3020 or email [email protected] with any queries.
Quality Engineering Consultant
4 年By "Test automation tool" I think you mean a "Test automation service". I will focus on these things 1. Is the test automation service really needed? 2. Use domain models that closely reflects the actual domain. Also treat automation service as a production service. Hence all the cadence for a production service applies to test automation service as well. 3. Ensure it is easy to run those automated tests. One may use containers, lambda etc 4. Have a dashboard for test results. 5. Wherever appropriate use cloud services as much as possible, so that we can benefit from solved problems than reinventing the wheel. 6. Use same tech stack that the service uses, so that developers can contribute easily and help us. Thanks.