Sunday, November 6, 2011

Threading and UI test automation


If there is one thing that is the most difficult part of test automation is waiting for some action to finish then proceed. I am not talking about ajax/waiting for UI element, waiting for the AUT do something or waiting for some time to elapse.

Most of the tools are use only sequential execution. I should say all, but I think there may some tool that has this feature. As this different from parallel or grid execution. Let me explain with steps,


Typical Test Script does the below functions,

1. open a page
2. Click something
3. go to next Page
4. do something
5. check for something

Above steps are perfectly good except when there is need to wait. See the below steps

1. open a page
2. Click something
3. go to next Page
4. do something
    < Wait for sometime>
5. check for something

If the <wait for something> time to is few seconds or few minutes then no need to worry unless it affects the execution time significantly.

What if that time is hours or day?
How do I automate an app/webpage that needs periodic wait time?

For ex, testing an Calender apps is a good example.



So, what needs to be done the automation tools to work better?

Programmers who reading would have shouted Threading/Concurrency. Yes, that is the obvious answer. Having a thread scheduler or task notifier will make this job easier. I am wondering, why this obvious things are not available in Test Automation tools? Why testers need to be satisfied with basic sequential execution?

Yes, I can use the threading in API tools such as Selenium. This why I love API based tools rather than Record and Playback or off the shelf tools. See my previous post here Test Automation using Tool or API (http://vrajasankar.blogspot.com/2011/08/test-automation-using-tool-or-api.html)

Further, this waiting for action can separated into two categories.

1. Checking/waiting for outside action (nothing to do with UI)
2. Checking/waiting for UI action.

Examples for trying to check a action outside of the UI is check for mails, checking the values in DB, check if files are available etc. For this, actions can be checked in another thread while UI execution move next script thus speeding up the test execution.

For the second option, either those actions can scheduled or another instance(head/headless) can be started to finish the test.

I think, without this threading/concurrency capability it is not possible to automate the complex enterprise applications.

ShareThis

raja's shared items

There was an error in this gadget

My "Testing" Bundle