So we have formatted response data now, that's nice, but it would be a vast improvement to have the result colorized with links inside clickable. Makes it way easier to read at a glance.
Currently if you use a verify step on a <table> element, if the verify fails, you get "Expected count does not match" as an error message for failure information. I think this message should also include a line saying what the expected verified count was, and (or at the very least) an indicator of what the count was that the step failed to. Various things could cause a count to be wrong, and I believe that knowing what the count was at the moment that step failed, would help greatly in debugging these failures.
Rename failure screenshots to reflect parent test that was executed during Test List execution when there are test as step tests. Currently screenshots are named after the test which has the failing step instead of the parent test.
Test Studio's Step Failure Details dialog manages failure data correctly. The possible confusion comes when you explore the stored data in [projectFolder]\Results\[testListName] from windows explorer for example.
All details shared internally!!!
Details and project for reproduction provided internally
Make sure there is an easy way to slow down the test execution for a whole test list or test. At the moment the only to achieve that is by using "execution delay" steps you add after each action step. There should be a more convenient way to achieve the same outcome.
Add the ability to data drive the URL of a http request without using a previous step as source. Once a data file is bound to the test allow the user to data drive the URL of a request.
Steps to reproduce: 1. Use Run->To Here against Chrome or Firefox. 2. Once the recorder is attached immediately hit the Pause button. Expected: The recorder is paused. Actual: The recorder is displayed as paused but it actually still records steps.
Executing the following code in Chrome does not work: ActiveBrowser.Actions.InvokeScript("document.getElementById('elemenID').click()"); the behavior is the same with the following workarounds: Element.InvokeEvent(ScriptEventType.OnClick); Element.Click(); More details are provided in the internal description.
An exception is flooding the application log for a remote execution machine. The customer has two machines - one (win7) is execution only and the other (win 10) hosts the scheduling service and TS as well. Despite the exceptions the execution is successful. It would be good to investigate if we could find a solution for the faulty exceptions and if we could handle these. Details shared internally!
Client`s Custom application has issue locating elements during execution against Chrome and FF. However, IE executes test successfully.
Chrome cannot be started with the required by Test Studio arguments when the "Application Identity" service is enabled in Windows 10 and as a result cannot record or execute tests with Test Studio. It will be beneficial to investigate the case on our end and identify if there is anything we could improve or at least document the known issue. A workaround could be to either disable that service or to add an exception for Chrome in an AppLocker rule to exclude it from the respective GPO.
If locally scheduled test list with option to send e-mail with exported to HTML format does not send e-mail on test failure. As a workaround - once exported the result in HTML it can be send by e-mail manually. The other approach to this problem could be to install scheduling server and to use it when schedule test locally.
To reproduce the problem - first maximize Chrome and then resize the browser in a coded step using the sample line bellow: ActiveBrowser.Window.Move(new System.Drawing.Rectangle(150, 150, 1000, 700), false);
It would be useful to have the functionality to build the project from command line.
Please find attached a sample project demonstrating the below listed issue. Details shared internally