Important note: After its completion, this series will be gathered up, updated/polished and published as an eBook. Interested? Register to receive the eBook by sending us an email at email@example.com.
Test Studio ships three major releases per year, each followed by a Service with new features and enhancements, as well as numerous minor releases in the form of internal builds with bug fixes and small feature improvements.
For major releases we define two important timeframes:
For service packs, we define one milestone:
Note: Key approach is to prepare automation for new features before the release, so automation coverage daily runs can be performed prior to release to verify last minute priority changes
We exclusively use Telerik Test Studio to automate Test Studio and provide internal feedback by doing so. In addition, for some specific scenarios, we use MS UI Automation calls in our .tstests to simulate specific Windows user interactions which are then handled by Test Studio, like showing context menu in a Browser during Test Studio Recording. For some other custom scenarios we call SOAP UI web service tests within Test Studio tests and analyze the output, to cover End-To-End (E2E) cases. Key approaches we use for the automation include:
Working with common tests, automation helper classes and global constants and variables are heavily utilized and recommended by the Test Studio testing team. Rule of thumb is if the same chunk of test steps/code is used more than twice across the project, it should be moved to a common test/code.
var row = (System.Data.DataRow)
UI automation in general is not as fast as API or low level automation, since the tester has to ensure the UI is properly visualized and refreshed before a certain test step is executed. In Test Studio there is a Step property called WaitForNoMotion for WPF/SL elements that takes care of this. Appropriate usage of this property can save execution time without compromising test stability.
Example: when opening a new Window, first step (verification or action) should always have WaitForNoMotion=true to ensure UI is loaded fully, which can take 1-2 seconds before its execution. However if after this initial step there are 20 other steps that check the UI for example or do actions on controls that don’t change in the current context, setting WaitForNoMotion=false for those steps will get rid of these 1-2 seconds per step delay that ensures UI is properly loaded, because the user already knows this is the case and some 10-20 seconds are saved and execution is accelerated. When applying this approach to a large number of steps in big projects, the accumulated savings in time can be measured up to an hour.
There are cases when we want to simulate Windows user actions while the Telerik Test Studio engine is running to see if it behaves properly—for example simulating user actions while the Test Studio recorder is running to see if steps are recorded properly. We do this by defining helper classes with common methods using MS UI Automation:
"The input element is null - stop execution"
var p = element.Current.BoundingRectangle;
System.Drawing.Point poi =
Cursor.Position = poi;
System.Drawing.Point(Convert.ToInt32(p.X) + offset, Convert.ToInt32(p.Y + offset));
(executionContext.Test.ProjectId.ToString() == projVersion)
OnBeforeTestStarted(ExecutionContext executionContext, ArtOfTest.WebAii.Design.ProjectModel.Test test)
foreach (string pr in procsToKill)
"Telerik Storage Service"
"Telerik Scheduling Service"
stopWatch.Elapsed += StopWatchElapsed;
StopWatchElapsed(object sender, System.Timers.ElapsedEventArgs e)
OnAfterTestCompleted(ExecutionContext executionContext, TestResult result)
//create product version specific variable
//read configuration file
//execute this section only for the Automation project
(projVersion == list.ProjectId.ToString())
//prepare execution to re-run failed tests
(!rerun || list.TestListName.Contains(
//create new TestList object
failedTL.ProjectId = list.ProjectId;
failedTL.Id = list.Id;
failedTL.Settings = list.Settings;
And execute it runtime also:
//Only execute if re-run failed tests is selected
(!rerun || !isFailed)
//get the list of failed tests for re-run
var failedtestnames = result.TestResults.Where(x => x.Result == ArtOfTest.Common.Design.ResultType.Fail).ToList();
foreach (TestResult tr in failedtestnames)
Did you find these tips helpful? Stay tuned for the next chapter and let us know your feedback. And don't forget to register to receive the eBook that will be put together when this series is complete.
If you are interested in trying the latest Test Studio, feel free to go and grab your free trial.
Daniel has been the QA Architect of the Telerik ALM and Testing division for more than 5 years, with a main focus on Test Studio. He has 17 years of Quality Assurance experience, and has worked in a few multibillion-dollar world leading software companies. He has been driving the testing efforts and pushing through all major Test Studio releases from the product's inception to its current mature state as a leading player in the test automation market.
Copyright © 2017, Progress Software Corporation and/or its subsidiaries or affiliates. All Rights Reserved.
Progress, Telerik, and certain product names used herein are trademarks or registered trademarks of Progress Software Corporation and/or one of its subsidiaries or affiliates in the U.S. and/or other countries. See Trademarks or appropriate markings.