The Add Test as Step screen should let me double-click to add a test from that dialog. Currently I have to click the test, then use the Select button to add the test. Double-clicking an item to use it is common practice for most lists, and it makes sense to support it in this list too.
Hi, I think it would be add on to Test Studio's features if the name of the test is displayed in the title bar when the steps are viewed. Right now only the project name is displayed and the name of the project is not glued on opening a specific test within a project. I think it would be usefual for the user in way say he leaves the machine for 30 minutes and returns, he'll get to know his current test name he was working on. In case the count of tests is high this is a feature that could comfort the user. Hope to see this in the update. Regards, Sharabh Sharma
When working with coded steps and code behind file in Test Studio (standalone), a very helpful feature would be to add the ability to collapse to definition, collapse/expand single methods and collapse/expand by region. This would make navigating through tests with a lot of code much easier.
Using TS Standalone, when creating a Test As Step from existing test steps, the Name field should have focus by default. This would speed up the process of creating reusable Test As Steps and save a few extra clicks.
Please make the elements menu in the JS recorder resizable. Currently it's extraordinarily hard to work with the DOM explorer and a page. I'd like to be able to expand it as much across the page as I need to.
In customer own words: "starting with test studio wasn't easy. I've had a lot of trouble with a few features i didn't understand at start and i've been resorting to coded steps alot at the beginning. I know you have a lot of samples, tutorial videos, and documentation available online, but i was hoping to find a nice tutorial with pictures i could share my colleagues that wanted to try test studio as well. If you have some simple GETTING STARTED tutorial, i would really appreciate if you would share it with me." I'm attaching the latest tutorial, which unfortunately includes a lot of outdated screens.
It would be a nice optimization to allow two coded steps within the same test to use the exact same method. What you have to do now is implement two different methods which both call a common method that is not an actual coded step.
We noticed a really weird issue where although the Chrome Extensions follow a similar version scheme as the TS releases (eg. 2014.4.1211.8), the latest version of the extensions are NOT MATCHING the corresponding version number of Test Studio. For example, as of today the latest version shown for the Chrome Recorder is 2014.4.1211.8, but the corresponding version of TS is 2015.2.715.0... Shouldn't these version numbers be matching? Thanks!
An excel export of test list results include the test name and the failure information, but it would be nice if it showed the step that failed as well. We have some users that do not access the test list section of Test Studio (due to all of the problems we have been having in that area as of late), so would be nice if the results showed the step rather than me having to drill down the results in the test lists tab to tell them what steps need to be addressed.
Hi guys, the Telerik sample app contains a Kendo Editor control. TS is able to successfully record typing against Kendo Editor from our demo page: http://demos.kendoui.com/web/editor/index.html But it doesn't successfully record it for the same control in the sample app. Steps to repro: 1) Start the TS recorder 2) Navigate to http://stoichev:8080/inbox.html (only accessible internally) 2) Click "Compose" button 3) In Compose view start typing into the Kendo Editor Expected: typing action is recoded Actually: it will only record a click against an HTML object with the tagname Iframe (which is not actually an HTML frame!?)
Suppose I want to validate the text value of a input element with type="email". How would I do that? Even using the Sentence Verification Builder there doesn't seem to be a way to access the text value. When the SVB is used on an input element with type="text", there is an HtmlInput verification that allows me to check the input value. However, when used on an input with type="email", that verification is not there. To demonstrate, navigate to this page: http://www.w3schools.com/html/tryit.asp?filename=tryhtml5_input_type_email, type a value into the email field and then try to create a validation to verify the value.
Some J2EE will put the session ID in the main part of the URL for example: https://localhost:8443/supermart/login.htm;jsessionid=1A530637289A03B07199A44E8D531427 Notice how it starts with a ; and is a key/value format. Test Studio sees it as one long URL, will record and play it back in a load test exactly like that. It does not recognize jsessionid as a dynamic target. It would be helpful if Test Studio was capable of handling dynamic URL's like this.
In customer's application it generates a number of dynamic frames. The Name and ID will changes based on if it's the first or second or third tab of the application. This means you cannot use these properties to reliably find the correct frame because when you run the test you don't know which tab it will generate. The baseurl of the src attribute is always the same no matter what type of tab is being created, so you can't rely on that either. There is a long complicated query string which can be used to identify the correct frame however the client needs this to be parameterized for reusable subtests. One test will require one value and another test will require a different value (e.g. the name of a "Property" as created and used in their application). Ideally they would like to be able to data drive the Frame Info just like you can data drive finding elements. Barring that they need some mechanism of being able to parameterize which frame to look in when looking for elements. Different tests will create different frames with different src values but the rest of the content in the frame will be the same e.g. the tab for Property AAA will have the same elements as the tab for Property BBB. But since they src property is different they are currently being forward to write two different tests that effectively do exaclty the same thing but in different frames.
If during the test the WPF application crashes, .Window.Close() will not be executed (which is expected behavior), however it will not timeout or throw an exception.
Test Studio needs to support ATDD-style workflows where test skeletons can be written without a live page. To support this we need to be able to manually add pages and elements to the repository. One workflow might look like this: * Add a new test to the project * Open that test, manually add a Navigation step to the test * Via new UX, add the page to the repository using appropriate identification logic. Page would now appear in the repository browser window. * Now you would be able to right-click on that page and select "Add New Element" or something similar. * New UX would allow you to add the element. *** Minimum feature: create appropriate Find logic to identify the element *** Bonus: Also define the element type
Currently it is not immediately clear if the new version available for download is official or internal build. It will be best if that is clear in the UI so that the user can decide whether to download/update it or not.
If a test list is frozen, it will effectively block the service from running any other test lists the following days. We'd like to have something like a watchdog feature implemented that simply kills off a scheduled test-list run completely if it is inactive for a long period of time (also killing the IE processes ofc). This would allow the service to continue the following day and the next etc.
When schedule the test list IsAlive (project attached in internal description) for 24 hours running at 15 min intervals a lot of IE instances about blank are left over. Steps to reproduce: 1. Schedule the attached project for 24 hours or overnight run at 15 min intervals. It is important that you get it running at those 15min intervals as otherwise you wont see any issues most likely. Expected behavior: No IE instances are left opened Actucal behavior: A lot of IE instances are left over in about blank state