Test Studio Scheduling is Back and Better Than Ever

As part of the latest Test Studio R3 2015 release, the team introduced a huge Scheduling feature refactoring. This delivered a number of improvements and fixed known functional, performance and scalability issues.

We're proud of the Scheduling feature in Test Studio, but we can be honest—in the last two years, we encountered a significant number of reported Test Studio Scheduling problems from our customers and from our Quality Assurance team. With the feature heavy product roadmap and the fact that we needed to change the whole Scheduling feature architecture, we were facing a big challenge. It was a lot of hard work, but in the end I am extremely happy that we managed to include this highly anticipated feature refactoring in the new R3 release.

The improvements cover several feature areas:

• Database and Results
• Setup and Configuration
• Test dependencies uploads
• Status Reporting
• Logging

Database and Results

The Scheduling environment consists of two services—Scheduling and Storage—and one of our biggest improvements is with the latter. Test Studio communicates with the Scheduling service, which sends the project over to the database through the Storage service. It then initiates test execution on the selected machines, and after the test lists runs finish, it throws the results back. So the first and the main improvement is in the Storage service, its operation and the database technology used.

We replaced the SQL database with MongoDB, which would scale better for continuous usage. This makes it possible for the entire system (from processing runs, to reporting results, to the UI) to function as expected even under heavy load.

Despite the good overall performance and stability boost, there is one downside here—people need to switch to the new database, and the old results and any other custom scripts will be lost. This is not such a deal breaker however, because we provide a tool which easily migrates your old results to the new databases. Here are the instructions for how to use our migration tool. If you have some custom scripts which extract results, for example, you may find these hints on how to re-create them on top of the new MongoDB database useful.

Setup and Configuration

Since SQL is no longer a dependency, the Scheduling setup is also simplified. This obsoletes problems like being unable to start the storage service due to missing permissions or required impersonation.

Another new thing is the Scheduling Configuration tool that we put together. Now the Scheduling and Storage services setup happens in one place—the integrated configuration tool, which is easily accessed from within the Test Studio IDE.

Test Dependencies Uploads

The system is improved to detect and upload dependencies needed for remote runs. That covers all possible scenarios like coded files, new/updated elements generation, data sources/data-binding a test, referenced assemblies as well as renamed or cloned tests and test lists.

Status Reporting and Logging

There are some other small usability improvements. Cases like incorrect status of unavailable Scheduling server are covered so that the user can easy figure out if there is a problem with the system setup. Major issues in logging (exceptions, cannot connect logs) are resolved. This makes the log much useful for troubleshooting and also helps in avoiding troubles with resources (memory usage, disk space).

All these changes are in the latest R3 release of Test Studio. We believe that they significantly enhance the Scheduling feature and that it will be again one of the most significant features in Test Studio.

As more and more customers start to use our resurrected Scheduling, the next step for us is to collect feedback, positive or negative, and to fix the remaining problems. If you have feedback, we encourage you to leave a comment below or in our Feedback Portal.