This is not really a bug. We are integrating Azure Dev Ops into our development environment and I've come across several links explaining how to integrate Test Studio to work in the Azure Dev Ops environment. It's still somewhat abstract to me, but it seems that one of the prerequisites highlighted in red below does not exist in our Azure Dev Ops Environment. Could I be missing something? Or have significant changes been made in the terminology that make it hard to keep up with?

Any help would be welcome or a point the right direction.

SSq

 I generated html report using  ArtOfTest.Runner.exe, but when I open the html file in browser,  I'm not able to see the images for Actual or Expected. It's always displays a default images.

When you enable annotations and execute the test from  project's explorer context menu the annotations are turned off. 

As a workaround you should use quick execute button or F5

There are times where test studio throws this exception described in http://feedback.telerik.com/Project/161/Feedback/Details/121035-path-too-long-on-backup-problem

[04/24 11:48:37,Telerik.TestStudio.RemoteExecutor.exe(5092:133),TestStudio] AutomationHostState.StoreToFile() : EXCEPTION! (see below)
     Situation: AutomationHostState.StoreDomOnDisk
     Outer Exception Type: System.IO.PathTooLongException
     Message: The specified path, file name, or both are too long. The fully qualified file name must be less than 260 characters, and the directory name must be less than 248 characters.
     HRESULT: 0x800700CE (Official ID (if app.) = 2147942606, Error Bit = FAILED, Facility = FACILITY_WIN32, Code = ERROR_FILENAME_EXCED_RANGE)
     Call Stack:
          at System.IO.PathHelper.GetFullPathName()
          at System.IO.Path.NormalizePath(String path, Boolean fullCheck, Int32 maxPathLength, Boolean expandShortPaths)
          at System.IO.Path.NormalizePath(String path, Boolean fullCheck, Int32 maxPathLength)
          at System.IO.FileStream.Init(String path, FileMode mode, FileAccess access, Int32 rights, Boolean useRights, FileShare share, Int32 bufferSize, FileOptions options, SECURITY_ATTRIBUTES secAttrs, String msgPath, Boolean bFromProxy, Boolean useLongPath, Boolean checkHost)
          at System.IO.FileStream..ctor(String path, FileMode mode, FileAccess access, FileShare share, Int32 bufferSize)
          at ArtOfTest.WebAii.Design.AutomationHostState.StoreToFile(String filePath, Object value, String traceMethod)

[04/24 11:48:37,Telerik.TestStudio.RemoteExecutor.exe(5092:133),TestStudio] AutomationHostState.StoreImageBytesOnDisk() : EXCEPTION! (see below)
     Situation: AutomationHostState.StoreImageBytesOnDisk
     Outer Exception Type: System.IO.PathTooLongException
     Message: The specified path, file name, or both are too long. The fully qualified file name must be less than 260 characters, and the directory name must be less than 248 characters.
     HRESULT: 0x800700CE (Official ID (if app.) = 2147942606, Error Bit = FAILED, Facility = FACILITY_WIN32, Code = ERROR_FILENAME_EXCED_RANGE)
     Call Stack:
          at System.IO.PathHelper.GetFullPathName()
          at System.IO.Path.NormalizePath(String path, Boolean fullCheck, Int32 maxPathLength, Boolean expandShortPaths)
          at System.IO.Path.GetFullPathInternal(String path)
          at System.IO.File.InternalMove(String sourceFileName, String destFileName, Boolean checkHost)
          at ArtOfTest.WebAii.Design.AutomationHostState.StoreImageBytesOnDisk(String projectResultsPath, String fileRelativePath, String expectedImageRelativePath)

There was a MSDN blog by Kim Hamilton that suggested a possible solution to this issue.  http://blogs.msdn.com/b/bclteam/archive/2008/07/07/long-paths-in-net-part-3-of-3-redux-kim-hamilton.aspx

Please see if this exception handling is feasible.

When I run my test that requires a button click event it works fine. However, when that same test is run from test list, it does not - the web page remains the same, with the visible button not being clicked.

Weird, this only seemed to happen after upgrading to 2022.1.215.0

If a manual mouse click is introduced on the login dialog it is able to update the textbox with the DataDriven info.

Steps to reproduce: 

1. Record a sample test on https://demos.telerik.com/kendo-ui/textbox/index. 
2. Enter name in the KendoInput field. 
3. Add a step to verify the value of the KendoInput through the highlighting menu and execute these recorded steps. 

Expected: Successful execution.
Actual: The test fails on the verification step and reports that the value of the KendoInput is null. 
Additional note: If the verification is added for the input control (instead of using the KendoInput), it is executed as expected. 

The Kendo Angular Multiselect control is not covered with the built-in translators.

It will be very useful and consistent if such translator is added in Test Studio.

The translator for KendoAngularTextbox matches the textbox control in Kendo MVC and records the respective step. The execution of the test is not consistent. 

Currently Test Studio load test can only use a dynamic target of type URL, if this takes its value from the response of a previous request. It will be useful to allow data driving this type of dynamic target with data from external source. 

A picture is worth a thousand words...

Allow the ArtOfTest.Runner to publish the results to the Executive Dashboard. There they can be seen by members of the team, who do not have Test Studio installed.

Make it possible for the ArtOfTest.Runner to use multiple execution machines. Distribute the test list execution to other execution servers.

Currently the exported result contains extended details only for the failed steps. If there is a warning for a step - like the warning that the element was found only by image, this can be only seen in the Test Studio result file. 

Extending the HTML exported result to show the step warning details will be very useful for anyone who review this type of result (attached in an email after a scheduled run, for example). 

Update the predefined device config settings with the latest available common iOS and Android devices. Check if the User-Agent request header needs to be updated as well, or more options to be provided. 

We have a large PDF (60+ pages) and try to verify certain content on specific pages. During the recording process some elements are captured with TagName and TextContent and others with TagIndex. In this scenario TagIndex is not reliably, because the document is large and the elements change dynamicaly.

One solution is to update the element's find logic manually on all elements that use TagIndex, but this is very time consuming. 

Another option is to use coded step to find the target element by TextContent and verify it.

When the Scheduling server is not added during installation, the Configure button in Test Studio will be greyed out (disabled). It will be helpful to add some kind of tool tip or note about this.

The solution is to modify the existing installation of Test Studio and add the Scheduling Server feature to the installation.

Allow users to add custom arguments when executing tests against any of the supported browsers.

This includes the Chrome Headless execution, which always defaults to en-EN language argument for example and you can't change it.

When generating videos for the test runs from a test list, the output video files uses the name of the test only. There is no indication which is the test list from which this test was executed and when having multiple runs and videos it is difficult to relate these with the generated results. 

It will be useful to generate the names of the videos from a test list in a way to correspond to the test list name and particular run. 

We need to be able to verify the text in dialogs in different browsers.

The current solution is in code, but is not stable due to browser structure changes -> https://docs.telerik.com/teststudio/advanced-topics/coded-samples/html/verify-dialog-text-chrome

 

It will be helpful to have an element, which is defined based on another element. This is similar to chained find expression, but instead of defining the parent element with its find expression, add the ability to reference an already recorded element in the project as a parent one. Then add find expression for the child element.