Test automation starts with feasibility analysis for any project, it includes activities like identifying the list of software automation testing tools and analyse which all can automate the client’s application, support and budget.
- Feasibility analysis can be best done by navigating through all the screens of application under test and list all the unique possible UI components of the application. Evaluate the % of UI components which can be automated by each automation testing tool, here we need to understand that at times we may not be able to automate every UI component present in application under test.
- As part of feasibility analysis we may have to figure out ways if any automation testing tool can help to automate those UI components by performing few tweaks or by any alternative identification mechanism. It is always recommended to select an automation testing tool which gives flexibility to extend.
- It is always recommended to chose an automation testing tool for which there is a support team to take care of issues or queries, it plays a very vital role in between of the project to address any uncertainties that arise.
- Once we drill down to a smaller list of automation testing tools which can automate the client’s application have some POCs done with respect to each automation testing tool to understand the intricacies. This will help to take a better decision on which automation testing tool to be proposed. Also, it is advised to document all the observations when creating the POCs, it would help during the actual automation testing cycle of the project.
- None the least capture the cost that need to be incurred as sometimes budget can play an important role on the decision making. Come up with a best possible balance of automation testing coverage and optimal budget.
Request to share your queries or suggestions in the form of comments.
Hi Srini, it’s a nice article……and I would like also to share my view on feasibility study of an automation tool.
I am keeping my experience of tool selection here in terms of below factors:
Object Recognition:
You have already discussed this in your first two points…………here is my thought on the same.
All the tools won’t have the same capability in identifying objects. The mechanism used for object identification for different tools will enable us to create easy and robust scripts. In QTP, it uses smart identification. In selenium it uses Xpath for identifying the object…likewise the tools efficiency in identifying the object while running the script will decide the robustness of the scripts.
Operating system:
Support to various operating systems will differ from tool to tool. Our application under test might have separate need to be developed on specific operating system. In that case we should consider a tool which supports the specific operating system. For an example QTP supports only windows OS, whereas selenium supports windows, linux and Mac OS. Hence depending on our application usage on different OS, we have to select the automation tool.
Test Results:
Test results generated should be easy to understand and give a flexibility to share it to client without any modification. Of course we can have user defined functions to generate the test result format whatever we required, but this should be easily incorporated in the test results of the tool which we are using. There should be a privilege to publish our required format of test results in the tool’s format test report.
Programming Language:
We should also consider the programming language the tool supported and the availability of the resources that have the knowledge of programming language. Should also consider how easy that programming language to learn and work on that in case the resources are not available to work on that.
Version Control and sharing of scripts:
Consider the accessibility of the scripts through SVN or CVS and the support of the tool to any version control software. In case if we are using some test management tool like QC we should also consider how far the automation tool is supporting test management activities.
DB access and Data Pools:
Tools should support the data pools for data dynamicity and should also support database accessibility. Few tools have data base support using inbuilt objects and few works on third party drivers. We have to select a tool depending on our requirement of data driven tests.
Record and Playback:
Tools we have selected should have the stable recording and playback.
Initial test setup:
Initial test environment creation should be an easy operation and we should also consider this while selecting a tool.
Browsers support:
It is also important to identify the browsers to be supported by tool. Few tools have the complete support to all type of browsers, and few won’t. We should also consider the version of the browser too.
Issues and concerns:
We should also consider our tool is having any issues w.r.t any aspect of test automation by having discussions with the professionals who used it previously. Another source is to browse its usability issues and concerns through professional networking.
Speed of execution:
Speed of execution is one of the factors while selecting a tool. Does tool has any customization w.r.t to speed is the factor to be considered. Speed of the tool may vary according to various network topologies and this need to be discussed with your network admin.
Support of tool:
As Srini told in above article it is better to select a testing tool for which there is a support team to take care of issues or queries.
Price of the tool:
This plays a major role because most of the customers won’t like to spend much on tools and always tries to fetch this automation through open source tools. This cannot be always possible when consider all of the above factors…hence it makes the customer to buy a licensed tool to achieve their automation needs. As an automation engineer it is our responsibility to give a cost effective solution to customer by considering all of the above factors.
With all these considerations, before jumping directly in to automating an application under test, it is always suggested to have pilot project/POC to make sure our selected tool is meeting our customer/organization requirements.
Thank you so much shilpa for sharing your views, keep sharing and let your friends also be aware of this topic and ask them for sharing their view points.
The other important factor would be coming up with ROI index. Could you please detail on caluculating the ROI.
Hi Anil,
Thank you so much for providing an input, would write an article for the same and will keep you notified.
Keep watching the space.
Thanks,
Srinivas p
which tool would be feasible for a secured site having online transactions , it should be com[patible with windows, IOS , Mobile based usability. It is dynamic in nature and scalable and maintained through cloud based infrastructure .
I would suggest to go with Selenium(web based),appium(mobile), xcode(IOS) as you are looking for multiple platforms.