Thought of automation process reduce the time
We have desk top application though this desktop application for creating loan it will take minium 2hrs manually. For this scenario we automated through QTP, Now QTP also taking time 3-5hr without any validation just inserts input values.
Now we thought need to reduce automation execution hours, for that we need to apply the process.
Please let me know which process suitable to reduce the execution hours
Few of process we started.
1) Create loan no in the data base itself without execute GUI level process, but as QA we have access permission only one environment we donít have permission other environment
2) Reduce the more steps existing automation but all steps are required to insert the data if any one step missing loan will not generate
3) Try to use another automation tool instead of QTP but it will not possible at this time because again writing new automation script it will take time.
Let me know if any thought to implement the process.
I've used many automation tools, but not QTP itself. Why has it taken automating the whole process to see it's so slow?
Typically data entry and navigation are much quicker via a tool, although some tools have default 'pauses', which make scripts easier to watch run for debugging, but aren't intended to be used when running end-to-end. You might have to wait for a QTP expert to tell you where they are controlled in QTP, or the help docs?
What is actually taking the time, the data entry, the navigation, waits in the scripts, AUT processing?
Yeah need more detail on what the source of your delays are. Especially with it being so much longer than doing it manually. There's got to be some unnecessary waits in there or something.
Is there an API you can use instead of direct db calls to do the setup work?
I found that loan approval usually takes several steps. It goes into different queues while being approved.
When testing loans, I made an Excel sheet that I called the "Cargo" sheet in business meetings. I would write scripts that would move the loans into different conditions. I would have a machine running all of the time to produce dummy conditions and track them on the Cargo sheet.
I could then run scripts on multiple machines from one state to another without having to go end to end.
* For test data setup, I use the builder pattern, and have builders that either call the database ORM objects the app uses, or an API call to create all the test data in a headless fashion before the test, and clean it up after the test. The goal where is I can always deploy a fresh system, run my tests, and clean up after myself very quickly.
* I like to put all settings and account data moved into configuration files. Tests access this data via a centralized configuration manager class. This allows me to run against different environments by simply passing in a different config file. Config files can be generated on the fly for cloud deployments.
* Write tests so they are independent of each other. Although total run time is more, you can run more threads in parallel.
* Given the points above, it allows me to run my tests in the cloud. For example, I can deploy the system or the AUT onto say 50 or so cloud instances and run my tests in massive parallel.
* Building automation right into the AUT itself. Any licensed tool will get relatively expensive to run in massive parallel. Most enterprises will in their latter phases build automation hooks right into the product to automate it without any vendor supplied tools. Generally automation tools are very slow and memory hogs. This is because it has to observer every object in the AUT and create object proxies for each of them, building automation directly into the AUT, you can save lots of memory and CPU by only monitoring objects you're interested in. Besides automation, this has other business side benefits. APIs for this can be used for creating mashup services other developers can integrate, and the apis could be consumed by assistive devices so your software could be used by the blind.
* Avoid hard coded waits. There's usually something that's just a bit more work but is more effective. For example, polling for an element to appear, or a loading indicator to disappear.