There are 2 +1 ways test automation is implemented for Enterprise Software Web applications. I will be writing a separate blog article for mobile apps test automation for Enterprises. The thought process is a bit different as we move towards Mobility solutions. Let’s see what are the 2 +1 ways to decide on selecting Software Test Automation tools.
1. Traditional – We have a stable application [legacy HTML + CSS] with an automation request or application currently being developed in agile where a subset of application [ex. few modules/components] is stable and ready to be test automated. There would be a dedicated environment where the automation scripts should always run. The scripts are expected to have reusable functions used across the application to be test automated.
In such cases, from a Services Organization perspective, depending on customer, we either go for licensed or open source or totally new test automation tool [that fits requirement with low license cost]. We know this, so I will not add more here. The Product Organizations have also started to look into Open source tools to reduce the cost of licensing a commercial tool.
2. Evolving – Off late, there is a paradigm shift in getting automation done quickly with focus on releasing updates to customers more frequently. The application being developed is also quite dynamic. There could be multiple environments where the test automation scripts are expected to run [where configuration changes only are expected]. But the application is expected to behave the same way across environments.
There is also this growing trend to not have any scripting involved OR dev to take care of automation as well [SDET] with minimum effort. The expectation here is to minimize script maintenance even though the applications may get updates [frontend UI or at the backend]. This is where AI based automation tools are mushrooming. These tools help in generating automation scripts quickly, and also adapt to changes made on the applications in future.
But for one of our customers, the requirement is different. As per my knowledge, they have created an open source set of components [APIs] with a basic framework and it is Angular in nature. This is expected to cater to different adopters. We are part of one such set presently, but data configuration and flow are dynamic.
Expectation from automation is also along same lines – open source tool and language to be used, the scripts should be very generic, dynamic and cater to all adopters.
We have used open source test automation tool [Selenium] and language [Java]. We are able to take care of this dynamic variation from scripts what we have developed. We also believe, with configuration changes made on our config files, the same scripts should work across multiple environments. The scripts are mostly generic within the adopter for whom we are working.
But we have not taken care of properly the Angular aspect so far. Due to this, we are facing synchronization issues and hence failures. This aspect is what we are trying to address by including ngWebDriver. This is where the design team from the customer side is raising a concern – they had proposed ‘Protractor‘ earlier which would have served all these expectations. But from our end, we had raised some issues that time, like this tool had limitations for interactions at the system level and have been working on Java + Selenium since. They have not asked us to switch to ‘Protractor’ now at least, but had asked us to come up with a solution to take care of this issue. When we got back to them with the solution, partly I think they got confused that ngWebDriver is a new tool we are proposing and hence asked us to compare ‘Protractor’ and ‘ngWebDriver’.
The other aspect we came to know very recently is, the snapshot captured for every UI failure is insufficient to confirm whether it is an application issue or not. This is where they have asked us to check if we can capture relevant console logs in addition to UI snapshot. In my earlier projects, I have not come across such a requirement. Because any network issue from console observed were logged by manual QA team.
I am not sure if we have to switch to their generic dev framework, all adopters will be able to reuse the same test scripts – the reason is very basic – for this to work, we should also have generic test automation framework along the lines of dev platform. We had it earlier I think, but have tweaked to make it work for one adopter with whom we are working presently. What we have to propose is, we will also come up with a generic framework, this should be possible from our existing one – we have to remove the additional packages we have created specifically for one adopter and tweak a bit.
3. Emerging – Application itself is AI based, so need to see if automation has a role here! I think the AI based test automation should still work here as the basic idea still holds good – the application gets updated with the AI/ML algorithms, the scripts generated previously from the AI based test automation tool should also get updated during the next cycle of execution.
If oprimes can help you with your test automation requirements and are curious to know how, check out our Test Automation page and book a demo now.
