Top Ten Strategies to Make Test Automation As a Service
Every journey towards automation development is different from employees to employees and from companies to companies.Each one has some voice to venture.Some story to say. Some are good some are bad. Each story is unique.
Extensive testing before any release is not only necessary but also become essential for any company for their client and their clients’s client,vendors,partners. Due to frequent change in IT industry,testcase base grows heavy in size. To run those huge cases,we need a strong manual team . Involvement of huge manual test engineers is nothing but loss human power.As they have to test the same test cases over and over for each release. Industry found out a common solution in the form of Automation testing. It is a sequence or series of actions performed by automation tool. The actions can or can not be dependent on human. During 2001 to 2005, the initial days of automation testing, automation team used to be a part of quality assurance or manual testing team.
A automation team was defined as a set of technology enthusiastic functional test engineers who writes VBA,or some small code base to make their job easy. Gone those days when team mainly used to depend on manual testing and automation was given a lower priority.
With the involvement of software design model like waterfall to v model to now days agile or rapid development ,automation becomes obvious. Agile and rapid development are meant to develop and change in a speedy way.So Automation needs to provide support in the same way.The nature of automation starts from unit testing to full execution, On demand execution to scheduled execution. Testing started rely on robot. Magnitude of testing is full day and night.When adopting such a huge speed, as a company, we need to adopt some strategies.
Here are the top ten strategies to make test automation as a service:
1. When to use Automation:
Test Automation is a success in traditional way of testing in waterfall model, but a successful agile development can not really sustain without a good automated testing.
Go for automation testing if the project is long term and features will be tested again and again.Automation testing is only preferable if and only if the nature of testing is repeatable. Automation takes time to be mature but effective to catch bugs. It will give QA more confidence to look into the non automated area.So use automation in such cases where-
- It saves time
- Increase accuracy
- Reduce cost
- Better ROI
- Better coverage
In agile when requirements may change every now and then, it is better to go for a TDD(Test Driven Development ) approach. This is surely ensure the proper and faster way of test development and execution.
2. Test Tool:
|Image Credit https://www.qasource.com|
Selection of the tool is very important as cost is associated with most of the tool.And Quality is associated with cost. Check for test tool compatibility with your UAT,the environment,browser.If Automation tool is compatible with your combination,half the battle is won. It is possible to test the environment in multiple language along with normal testing.Once we get the correct tool for correct application , we will get more ROI.
Top Ten Strategies to Make Test Automation As a Service
Many a times, the tool sales person /team showcase their tool,in such way, that the tool they are selling can automate everything a customer need. But reality is far from the show. So a expensive tool does not really make a functional team member an automation expert. Even they can not replace an automation expert.
Now the last aspect of tool selection could be o select some tool where your most of the knowledge base are. Simply if your resource is familiar to some technology or test tool or language, prefer the related tool.This will save time of initial learning and give automation a good start.
Test tool selection depends on the following factors:
- Affordability [Cost involves for this tool]
- Flexibility [How flexible the tool company about selling the tool or license]
- Compatibility [Can the tool support the UAT]
- Functionality[How easy the GUI or what feature the tool is offering]
- Usability[how easy to operate the tool]
- Maintainability [How easy to maintain the scripts]
If you are justifying a tool and not a member of management, please involve them from day one. And if you are a manager, please join the discussion to understand about the tool.If any team wants to get benefited with automation testing,management support is must. They must fund for R&D activities,pilot projects,fund for architecture development etc. Mostly it is top -down approach rather than a bottom up activity.
Framework should support a Hassle free way to integrate a newly build module. I suggest a GUI component to do this integration. By this an Automation test engineer or a functional test engineer can make a code and can submit for further use.Framework should not be so complicated that integration of modules will take lot of time and it requires a lot of effective testing time.
Reporting should be the next major aspect of strategy. From the beginning, we need to standardize the reporting. Also we need to upgrade the reporting whenever necessary. Reporting should be customized or can be drilled to the lowest level. Creating various levels of abstraction is a very good approach.I like the jUnit/TestNG report for selenium. The consumers may be different for different level of reporting. Functional engineers may be drilling down till last level,Managers may be interested about how many scripts,how many pass etc. Top management may be looking at overall percentages.
Always tailor automation and information to meet automation objectives.
We need to design a structured approach by which automation test engineers can produce maximum testcases by providing minimum efforts. We need to ensure maximum performance.Prepare best practices . Best would be to adopt a modular approach. Better to use a library driven approach rather putting everything in a script. Decomposition of the flow should be based on independent tasks. Not on the basis of a big flow. The independent task lets call Units should have only one trigger point and only one outcome. With these units, one can make flows.
Always create layer of framework. The top layer should be a simple script with simple English. GEB and SPOC are very popular in this aspect. The test inventory should be very user friendly to a non technical user.
There are many IDEs(Integrated development environment) available in the market.One should design the framework such a way that it can overcome the limitation of the tool’s GUI Part.
So framework development is not only a conceptual thing. There are finance area also attached to it. Be very careful to understand the requirements,tool selections and hiring.
5. Test Script:
Test script should be independent but structured. Each test case should be easy maintainable.Follow Hermetic Test Pattern for test development. Even now single ton approach is also nice.Test cases should be accumulated in easy and random way. Functional team should set testcase as per their requirement.Decomposition of the flow should be based on independent tasks. Not on the basis of a big flow. The independent task lets call Units should have only one trigger point and only one outcome. With these units, one can make flows.
Another way of automation is to check the heath of the test cases. And keep updating your inventory. The more we will test our testcases more we will get the quality. It will surely reduce pesticide paradox in automation.