Post summary: How to sell your automation to management. Guide for running the tests unattended.
References
This post is part of Automation of WPF applications with Telerik Testing Framework and TestStack White series. The sample application can be found in GitHub SampleApp repository.
Test frameworks need mouse and keyboard
As you have noticed when running the examples it is not possible to do anything else while tests are running because both Telerik Testing Framework and TestStack White are using mouse and keyboard in order to click and type text. This is how both frameworks are designed and work. It doesn’t seem very effective if you are wasting your time watching tests running on your workstation instead of doing something productive. This is not a good argument when advocating your automation.
The essence of automation is being effective
This topic is not about Automation vs. Manual testing so I will not go in that direction. I’ll just say that still there are companies lacking management willpower to support and embrace automation. So we need to be good salesmen!
How to drive your automation to success
As I said we need to be wise when promoting our automation to get more time and resources. Sales strategy is pretty easy and straightforward not requiring huge investments:
- Free to use and pretty easy to work with frameworks.
- Some enthusiasm to make the first automation. Remember, be smart and first automate most repeating scenarios. This will show real results and help you buy some time for further automation.
- Virtual (or real) machine with test running on it during the night
- Mail with results is sent to management with results in the morning
Run the tests unattended
You get the machine, set up the framework, set up scheduled tasks for deploying the latest application under test and latest test code. Run the tests and get into trouble. Tests do not run! This is because there are special requirements to schedule unattended run. There must be an active Windows session in order mouse and keyboard to be used. Once the session is interrupted tests stop. This is detailed KB article on the topic with several possible solutions.
Working solution
You can try solutions in the article to see which works best for you. For me, the solution is to have a remote desktop in remote desktop. This requires Windows Server installation. The only server provides two simultaneous remote desktop sessions. There are unofficial patches for non-server versions which I haven’t tried and cannot comment. Two local users are needed on the Windows Server with no desktop locking or screen saver (domain users most likely will have desktop locked after a time). Log from your machine to test machine with the first user. From first user’s session log to same testing machine with the second user. Tests are started from second user’s session. Once tests are started you can freely close desktop (not log out!). You can create a scheduled task which runs only when the user is logged in and just wait for results in the morning. If two accounts are overhead there is an option to use software that prevents your computer to lock. See prevent screen lock thread if something works for you.
Conclusions
Automation is an exciting field of career development for test engineers. This blog is dedicated to automation testing. You will find very useful and interesting topics in it. I would definitely encourage you just to give it a try. Good luck!
