Visual Studio Integration - Include Test Complete Tests as part of Visual Studio Load Tests
Visual Studio enterprise allows us to create Load Tests to performance test our application. This achieved by creating a series of Web Performance Test scripts and then creating a Load Test setup to distribute the scripts and user load in a controlled manner. (Fig 1) Currently Test Completes support integration with Visual Studio where Test complete scripts can be run via a Visual Studio controller and Test Agent config. But this is limited to only running Test complete tests one by one (Like a regression test suite). Unfortunately a Test Complete script which is in a Visual Studio project cannot be run via the Visual Studio Load Test setup as it does not recognise Test Complete scripts. You get the below error when tying to add the test to a load test config (Fig 2) The reason why Test Complete comes in handy for load tests is because some applications depend on processing in the client end before displaying the results in the GUI (something like a thick client). The time taken for this processing would not be captured via middle tier simulation supported by Visual Studio. Business critical systems which require transaction performance monitored release by release will benefit from the ability to include Test complete scripts in a Visual Studio Load Test as it will allow us to create background "Load" via Visual Studio scripts and monitor real life End to end transaction performance under load via a series of Test complete scripts which run as part of the load test.
Feature request to support Keyword Parameter dialogue in User Forms
If we want to create a custom keyword operation and want to use a user form than there is no way that we can access the Keyword parameter dialogue from that form. This is required while creating some functionality where we need to use the user forms but the components/parameters in the user form can be of different type.In that case default keyword parameter dialogue/window will be helpful. Something like: https://community.smartbear.com/t5/TestComplete-Desktop-Testing/Let-the-user-pick-a-variable/td-p/109873 Thanks.TestComplete JIRA Script Extension
Hi everyone, With the release of TestComplete 14.4, Smartbear has released a new JIRA script extension, so that we can use it in more ways than just the toolbar option that we see in our test logs. It can be downloaded in the Smartbear github link below, following the instructions as described in the readme file. This may be old news to alot of you by now as well. https://github.com/SmartBear/testcomplete-jira-extension I think this is a great step forward in creating some more elegant workflows with JIRA, which has sort of become the de facto issue tracking software for many agile organizations. We can see all of the methods that are available here within the docs page: https://support.smartbear.com/testcomplete/docs/reference/program-objects/jira/login.html With this new script extension, this means we can elegantly and automatically create new issues, and update old ones, possibly even using event handlers to update the relevant issues with more context like the visually pleasing mht files. Recently though, I came across a question of whether or not we could move resolution statuses (i.e backlog, selected for development, done, etc.) based on those same type of triggers (i.e onLogError, or conditionally based on logerrorcount). After a quick google search, it seems that jira workflow statuses aren't fields that can be set; they need to be transitioned. This meant that we couldnt use our new jira script extension, and the setField or setFieldJson methods to do just that. Thinking a little bit further about this, it makes sense, because why have a kanban board, unless we want to visually confirm some facts about our issues and physically move them across the various stages of development. Also, we probably don't want our issues to move drastically via automation (my worst nightmare would be waking up to 40 emails from JIRA telling me that all of my issues changed resolution statuses, and later find out that these moves were mistakenly triggered via a CI framework because of a bug in a one of the systems under test) The only way to "transition" the workflow statuses seems to be through accessing JIRA's api. There are certainly endpoints that do this for us. (along with some external libraries aka pip install jira) But as for whether or not we should be doing that? I dont know. ----and now moving this to our tc ide
