Sample date picker used here. 

Steps to reproduce:

1. Start recording session and try to enter date into the date input

Expected: To record a step to 'Enter Text'
Actual: A 'Click' step gets recorded and no date entered is registered in the test. 

Workaround:

1. Navigate to the page where is the date picker - I used this sample. 
2. Add the date input field into the test elements (the Elements Explorer) - for this you can either use the recorded click step, or highlight the element and choose to add it to the element repository. 
3. Once the element is into the project, you can add steps for it from the Step Builder - that includes the 'Enter text' action as well (from the Quick Actions section). 
4. Type the date you want to enter without using the slashes - for example 1072022 for today's date. 
5. Execute this step - you can use the partial test run options to execute only that step. Check what happens upon execution.
   Note: The Enter text step consists of few actions one after the other - these include a click action, which is being sent by default in the absolute center of the input field. Depending on the date picker implementation that could bring some inconsistency when entering the date - for example the month doesn't get changed at all. Actually if you manually click in the center of the input (even if this is not that precise) and enter the date, you will see the same behavior. If you click over the month, though, in the left part of the input you can then enter the date correctly. 
   If this is the case, you will need the adjustments described in the next steps. These will actually change the click action so that it clicks on the left side of the input.
6. The 'Enter text' step needs to be converted to code in order to modify the properties of the click action. When the step is edited in code you can see the MouseClick() method is the default one and doesn't use any parameters. You can directly choose any of the methods overloads and specify a click point in the input field. 
7. If you are not proficient in code writing and need some assistance to identify the right method to specify the location, you can use the following approach - while recording add a mouse click step through the Advanced Recording tools and choose the option to click on specific point from the target element. 
8. Once you have that step, you can convert it to code - that way you can see the MouseClick() method and what attributes it uses to click on a specific point. You can copy that line of code and replace the click action in the 'Enter text' step sequence. 
9. Then, remove or uncheck from the test the help mouse click step used to sort out the code.

Currently the WaitForFrame method only takes FrameInfo object as parameter. It will be helpful to use WaitForFrame method with frame name only.

DisplayLabels can contain text, but because it is not a supported FrameworkElement, it is difficult to work with in code. Tests instead have to store a path to the element and use the full name - like Applications.MyApp.MyWindow.DisplayLabel1 - every time I want to refer to it. It leads to a lot of repetitious code as well as storing of unnecessary elements, especially where a Find.AllByType would otherwise be able to take advantage of the consistent structure.

Custom WPF app cannot be automated as the recorder crashes the application. Currently I am unable to login and cannot provide details if the recorder can be attached to the running instance. 

Details shared internally! 

Step up/ Step down is not working as it should. To be able to choose value we should set initial one first. 

Using FF - The popup is recognized and recorder is being attached to it but no actions inside get recorded, highlighting cannot be activated at all and the DOM tree is not displaying all elements. When executing a test recorded properly the popup gets closed immediately after it is opened and no actions can be executed against it. 
Using Chrome and IE - Recording and execution works as expected. 

Further details shared internally! 

We have tens of fields on 100s of our scripts, it will be too laborious and not efficient to enter verification step for each field (text box, drop downs, radio buttons, etc.).
We would like Telerik software to improve and detect automatically if it was able to enter the data in a particular field. If not, the script should error out like it does when a field (element) is not found.

steps to reproduce: 

1. Open the test in the sample project.

2. Check the target elements' find logic for step 2 and 3 - these are modified to use TextContent for the html anchor.

3. The target elements in step 4 and 5 are the same - recorded in a second recording session. 

Expected: To record steps against the same elements already existing. 

Actual: Two new elements are recorded with TagIndex used. 

Steps to reproduce: 

1. Open the sample project and run the test to the step before while. 

2. Once the recorder is attached please select to run the while step only

Actual: The cycle is being executed once although the condition is not met

Expected: To run the cycle until the condition is met

Details shared internally!

Steps to reproduce: 

1. Create a Verify element Exists and Wait for element exists steps

2. Converting both to code generates Pages.Element.Wait.ForExists(30000);

Expected would be that the Verify element Exists step rely on the global project elements timeout or alternatively verifies immediately. 

Actual: The current implementation is that the Verify step takes the default wait timeout for a wait step. 

Steps to reproduce: 

1. Create a sample project and add the following steps: 

- Verify element Exists

- Verify element ExistsNot

- Wait element Exists

- Wait element ExistsNot

2. Convert these to code and double check that the ExistsNot steps refer to an element with the current find expression. In contrary the Exists steps refer the element from the Pages file directly. 

That way editing the find expression of the element will be updated and referred in the Exists steps. But the ExistsNot steps in code should be manually updated. 

Expected: The elements in all converted steps to be referred from the elements' repository. 

The options optionally provided to the command line runner related to publish results to TFS are not working correctly with the new builds in TFS 2017 vNext. 

Multiple customers reported that after applying a Windows update KB4041676 on a windows 10 system all excel files bound as data source in a Test Studio project stopped working as expected - the file stayed bound but no tables appear to select any of these. 

It would be good to investigate what that update causes.

1. Create a new WebForm project, build it, no AWSSDK.Core.dll in the bin folder.
2. Converted the project to a "Telerik UI for ASP.NET AJAX" project, build it, and now the AWSSDK.Core.dll and AWSSDK.S3.dll are added to the bin folder.



Expected: These are not required outside of Test Studio. 

1. Start recording a test against it and click over the cells in grid. Note that the first step is recorded against an element relying on TextContent. Each next element relies on AutomationID. 

2. Run the test. 

Expected: To run successfully.

Actual: Only the first step is being successful since the automationIDs are not present in the DOM tree. 

Note: The application does generate the automationIDs when started. They are only not present in the recorder DOM tree before a click is performed. 

Sample app shared internally. 

I am unable to capture Load scenario traffic, from an existing web test, on Server 2012 R2 machine, running Test Studio version 2017.2.615.0
I am attaching the screenshot of what I am getting in each browser.  It appears to be a certificate issue possibly.

It would be nice if there is a 'End Recording' button instead of closing the application under test to terminate the process. 

Using Windows Server 2016 cannot run tests remotely. The configuration is correct and clean, no firewall, no AV, unblocked ports. Although remote execution does not start at all. 

The issue was observed by two customer's environments. 

Mobile testing is not super steady in recognising elements, and as a result often taps the wrong element. A way to improve this could be the add a way to tap an element with a specific text (i.e a button).