Hi Team, I would like to be able to use a cloud based browser platform similar to BrowserStack, Sauce Labs, Ghostlab, Browsershots, etc. In order to avoid setting up massive VM farms to distribute browser iteration testing. Thanks!
I would like to be able to manually move an element from one page definition to another by dragging & dropping it in the Elements pane. I would also like to be able to duplicate an element in another page by copy & pasting in the Elements pane.
It is currently not possible to set “OR” rules in dynamic test lists. For instance if we have lots of folders with tests and we want to create a list with tests from the folders “Pages” and “News”, currently test studio applies “AND” rule and searches for a path name containing both words.
Be able to execute the same test case or step multiple times for each record in a data source (external file or built-in collection). Each record in the data source should provide arguments to be used as input values for execution of the step or as expected values for verifications.
Deleting steps delete elements in the Elements Explorer that are already used in Coded steps. Steps to reproduce: 1. Create a simple test that includes a step that selects one element. This element will be visible in the Elements Explorer. 2. Add a coded step that uses the same element. 3. Select the the first step that adds the element in the Elements Explorer and delete it. Actual: Compilation fails. The element that is used in the coded step is no longer in the Elements Explorer. Expected: Test passes .
This is a limitation/bug in TestStudio. Here’s where the customer creates the variable: http://10.225.68.127:8080/prweb/PRServlet/nF-qFK4ha1B9XolnJtsJWpQlh9AKUteKa55vdjEHm_Y%5B*/!STANDARD?pzPostData=1316036933 <input type='hidden' id='pzHarnessID' value='HID1CE396E7F15CF6B5FC350407D4BF1FDD'> Test Studio is looking for values that are wrapped in double-quotes. For whatever reason, the server has decided to wrap its values in single quotes, which leads us to fail to identify this as a source. More information along with the test is provided in the internal description.
I would like to have official support for Atlassian's Bamboo CI tool. This is a very heavily used CI environment, and although we can still call from the CLI, it would be nice to have baked-in compatibility.
There are several requests over the years to implement a way to force stop the execution of a test in cases of a hanging processes during execution. For example to set 10 minutes timeout and if a started test does not finish in this timeframe, to force stop the execution of the test and kill active processes related to the test, so that the execution of the rest of the tests in the list is not hang because of this particular test.
Make the test status box dockable so the user can still use the other functionality of test studio. Currently if it is open you cannot interact with any part of Test studio. Screenshot attached
Make Tests that are hung up on agents fail after a configurable amount of time. This might be an existing setting that is not functioning correctly.
We occasionally need to end a test list in order to fix a specific test, and the list could be halfway through and 45 minutes in. I think it would be beneficial to still be able to pick a starting point in a test list (with the default being the beginning), and run the test list starting from the test you choose. This way if you've run half your list and needed to stop it for some reason, you can just pick it back up from the next test in the list.
Need report that shows pass/fail over multiple projects and email sent to distribution. I have not been able to locate any tools in Telerik to do this basic function. I have attacted a screenshot to explain what I am trying to https://www.telerik.com/account/support-tickets/view-ticket?threadid=1048558
Steps to reproduce: 1. Open a source control connected project and keep it open on a machine. 2. Open the same project from source control on another machine and change the UnexpectedDialogAction setting of a test list to anything else and check in your changes into the TFS. 3. Get back to the initial machine and pull the latest version of the project. Expected behavior: To get the recent state of the test list settings as checked in from the second machine. Actual behavior: The test setting remains the same as it used to be.