ContributionsMost RecentMost LikesSolutionsRe: SmartBear Talks | Meet the TestComplete Product Management Team - Justin Kim hkim5,sonya_m, amazing interview! Looking forward to IQ on steroids😀 Re: Log no longer appears after running scripts Hi All, TestExecute 14.90 indeed introduced a bug to the /SilentMode functionality. The bug should be fixed in version 14.92 scheduled to release in August 2021. For version 14.91, our product team prepared a patch fixing the issue. nathanginoza, it looks like you were provided the patch in the support ticket you opened regarding this problem.adam_kuczkowski,ChiefBrian- please feel free to contact our support team and request the same patch for TE 14.91. You can submit a case here:https://support.smartbear.com/testcomplete/message/. Thanks, Re: String Default Values Hi Alex, Thanks for the detailed description of the scenario! However, it looks like the functionality not working for temporary variables and test items is expected. First, the way Shared Mode works currently, the Default Value of variables is never customized, the configuration only stores the Local Value. With temporary variables, there's simply nothing to store - they don't retain their values after the test run is over. So, their Local Value is always equal to the Default Value no matter how this value may change in the test. This is also the reason why the Local Value column is not shown for temporary variables. Now, as for storing the "Enabled" property for the test items, I can see how this could be useful. However, I haven't found any mentions of this feature in the documentation for TestComplete 4. Our support team also confirmed it when working on case00126077 that this feature was not a part of the later versions. It might be that the feature you described was available in older TestComplete versions (TestComplete 2 or 3, maybe). However, it's not a part of the product right now, so the Shared Mode functionality seems to work exactly as expected. As you know, our product team welcomes any feedback, but the number of enhancements we can implement is limited. So, the team tries to implement the ideas that would benefit most customers. Unfortunately, right now it seems that the scenario we discuss is not exactly a common one, so no enhancements are planned at the moment. As a way to prevent breaking project execution from a CI system, I'd recommend either specifying exactly what test items should be run instead of running the whole project. Or, if the number of test items is too big, you can use source control to make sure no local changes affect the project in the remote repository used by the CI system. Re: String Default Values Hi AlexKaras, Thanks for replying to Lee! It looks like some Shared Mode feature does not work as expected for you. I'd like to understand exactly what goes wrong - if the functionality does not work as stated in the documentation, our product team will investigate it. Lee originally asked about the default values of persistent variables. As I can see, they work exactly as you described (see this GIF). I've also reviewed case 00126077 where you discussed the customized set of test items feature with our team. The case was submitted for TestComplete 11, and as I can see, our developers confirmed that neither of the versions after TestComplete 4 (released circa 2006) included this feature. So, it was decided to submit an enhancement request: https://community.smartbear.com/t5/TestComplete-Feature-Requests/Make-settings-for-the-project-opened-in-the-shared-mode-to-be/idi-p/105106. Thus, the conclusion was that the feature functions as expected. Could you please describe how you'd like to use Shared Mode and what issues you see with your scenario? Re: Default parameter from variable Hi Lee, It looks like there indeed was a misunderstanding from our side - my apologies for that. As for this particular task, it looks like you have found a solution that works best for you. Just as a theoretical alternative, I can also suggest using the project variable in the keyword test directly so that the parametrization only takes place once. As for the inability to achieve the task without using code, you can register it as a feature request here: https://community.smartbear.com/t5/TestComplete-Feature-Requests/idb-p/TestXCompleteFeatureRequests. Thank you! Re: Network Suite Replacement Hiexdunepilot, I'm sorry for not being clear - each process can theoretically trigger a test on a remote machine, provided you wrote a script that does it (using cmd, PowerShell, whatever works for establishing a connection to a remote machine). As I mentioned, that would essentially be creating a clone of Network Suite that doesn't seem to be a viable approach. Re: Network Suite Replacement Hi exdunepilot,AlexKaras,seebs, Though the Network Suite functionality is indeed no longer supported, it will remain available in the product for quite some time before eventually being removed. To start a process of migration to a dedicated CI\CD tool, you can use this article: "Migrating Distributed Tests to CI/CD Systems". It demonstrates how to replicate the Network Suite setup, including synchpoints (https://support.smartbear.com/testcomplete/docs/netsuite-deprecated.html#synch), in Jenkins, but the same should be achievable in every other CI\CD system. Thus, in Azure Pipelines you don't even have to use scripting - the visual Classic mode allows creating several jobs and making them co-dependent. This should address the "multiple environment" case described above. exdunepilot, the Parallel object you mentioned was indeed created to make orchestrating cross-platform web test execution easier. However, this object, particularly Parallel.RunTests method is not bound to web testing - it simply starts several helper processes in parallel on the same machine. Since TestComplete tests simulate real user actions, they cannot be executed on the same machine in parallel. But each process can trigger the test on a remote machine. For web testing, we offer remote machines provided by CrossBrowserTesting as Selenium Grid. It's not possible to provide the same service for desktop testing, but one could theoretically create custom logic for remote desktop execution utilizing the Parallel object. However, this would essentially be a clone of Network Suite. So, I'd recommend looking into CI\CD solutions - TestComplete has native integrations withJenkins and Azure DevOps, but SessionCreator makes it possible to run tests from any tool. exdunepilot,AlexKaras,seebs,if you run into any issues with running TestComplete tests from Jenkins or Azure DevOps or have any questions, please reach out to our support team. Re: Add Project name in the execution plan item. Hiankit05gupta, Thanks for posting this idea! The "Execution Plan" item is very new, so we're glad to hear any feedback. We'll discuss the idea internally. For now, as a way to work around this, I can suggest checking the project suite tree on the left when working with different "Execution Plan" tabs - when you switch between them, TestComplete highlights the corresponding projects. Also, if you hover over the name of the tab, you should be able to see the full path that includes the project name. Re: Display all Test Cases linked to current sprint TM4J Hipmerrill, As I can see, you submitted the same question to our support team and got a response. Let me copy it here in case anyone else comes across this thread with the same question. You can obtain the needed data by generating the "Traceability > Traceability Report" report. First, you will need to create a filter to get the stories linked to the current sprint and add it to your favorite filters. The filter's JQL should look like this: issuetype = Story AND Sprint = {required_sprint_id} Once you have this favorite filter in place, you will be able to select it in the traceability report and obtain the needed data. Re: TC doesnt map object names automatically YuriSdev,jaward916, Thanks for reporting the issue. We would like to investigate it, so could you please contact our support team by creating a case here? We'll need the following information: The project where the issue occurs. Also, please check if the same problem occurs in a newly created project. The technology your tested application uses. Please also check whether the issue persists for every application or only for the one under test. If you can record a short video demonstrating the issue, that will help a lot as well. You can use free tools like Loom or Jing for that. Finally, we'll need a report - this way, our developers will be able to find out what's going on inside TestComplete when you observe the issue. Here are the steps to collect the report: Run Report Generator (<TestComplete>\x64\Bin\ReportGenerator.exe for the 64-bit TC version or <TestComplete>\Bin\ReportGenerator.exe for the 32-bit TC version. Choose an option that corresponds to your tested application type (I assume "When testing a desktop app") and follow the on-screen instructions. Reproduce the problem. Click the "Create memory dump" button. Click the "Save..." button - this will save the report into an archive. Send this archive to us. If you need any help with collecting the mentioned info, just create a case - we'll assist you with that!