Merge pull request #55 from telerik/develop

DevelopToMaster

docs-apitesting/system-requirements.md

@@ -8,9 +8,9 @@ position: 1
 ---
 # System Requirements#
 
-##S upported Environments##
+## Supported Environments
 
-* .NET Framework - 4.5.2
+* .NET Framework - 4.7.2
 
 ## Supported Operating Systems##
 

docs/_config.yml

@@ -261,6 +261,11 @@ navigation:
         title: "Testing Types"
         position: 14
 
+ # ....Azure DevOps mapper    
+    features/azure-dev-ops-mapper:
+        title: "Azure DevOps Mapper"
+        position: 15
+
 # ....Recorder section
     features/recorder/highlighting-menu:
         title: "Highlighting Menu Options"

docs/advanced-topics/coded-samples/general/custom-scripts-before-after.md

@@ -13,6 +13,11 @@ position: 1
 ## Solution ##
 
 Override the **OnAfterTestCompleted(TestResult result)** method for the "after" script and the **OnBeforeTestStarted()** method for the "before" script. They are both members of the BaseTest class that are invoked once the test finishes or before it starts. 
+
+> __Note__
+><br>
+><br>
+> If exist, the **OnAfterTestCompleted** and the **OnBeforeTestStarted()** methods gets executed also for <a href="/automated-tests/test-execution/partial-test-execution" target="_blank">partial test runs</a>.
  
 First, create a coded step in order to generate a code-behind file. Then open the code-behind class and add the override definition inside the BaseTest class.
 

docs/automated-tests/desktop-testing/desktop-test.md

@@ -6,7 +6,7 @@ position: 1
 ---
 # Desktop Tests in Test Studio
 
-Test Studio recording feature supports various desktop applications. To initiate recording session against specific application, you need to define which in the desktop test.
+Test Studio recording feature supports various desktop applications. To initiate recording session against specific application, you need to define which app to use in the desktop test.
 
 This article guides you through the desktop test configuration process.
 
@@ -32,27 +32,41 @@ The __configuration of the desktop test requires a desktop app to be specified__
 
 ## Choose the Desktop Application to Automate
 
-Test Studio provides few options to define the application to automate - you can [specify an executable file](#configure-application-path-in-desktop-test) for this test, [use a default path](#use-default-desktop-application-path) to the executable file set on project level, or [specify an Application User Model ID](#configure-application-user-model-id). 
+Test Studio provides different options to define the application to automate: 
+
+- [Specify an executable file](#configure-application-path-in-desktop-test) for this test;
+- [Use a default path](#use-default-desktop-application-path) to the executable file set on project level;
+- [Define startup arguments and working directory](#startup-arguments-and-working-folder-for-desktop-application)
+- [Specify an Application User Model ID](#configure-application-user-model-id);
+- [Choose to not launch an application](#do-not-launch-desktop-application)
 
 ![Config Desktop app wizard](/img/automated-tests/desktop-testing/desktop-test/fig2.png)
 
-### Configure Application Path in Desktop Test
+## Configure Application Path in Desktop Test
 
-Choose the __Browse__ button to open File Explorer and browse to the folder where the executable file is and select it.
+Click the __Browse__ button to open File Explorer and browse to the folder with the executable file and select it.
 
 ![Specify path to Desktop app](/img/automated-tests/desktop-testing/desktop-test/fig3.png)
 
-The __Desktop Application Path__ field also allows you to use environment tokens (such as `%Program Files%\MyApp\App.exe`). In any case the __Full Path__ field displays the full path to the executable file.
+The __Desktop Application Path__ field supports using environment tokens (such as `%Program Files%\MyApp\App.exe`). When using environment tokens, the __Full Path__ field displays the full path to the executable file. 
 
 ![Full application path](/img/automated-tests/desktop-testing/desktop-test/fig4.png)
 
-### Use Default Desktop Application Path
+## Use Default Desktop Application Path
+
+The automation process requires multiple tests to be created for a single application. In such case configuring each created test will be a tedious task. Thus Test Studio allows you to __set a default desktop app path on project level__ and use this for all desktop tests. 
 
-The automation process requires multiple tests to be created for a single application. In such case configuring each created test will be a tedious task. Thus Test Studio allows you to __set a default desktop app path on project level__ and use this for all desktop tests. The option is available in <a href="/features/project-settings/general" target="_blank">Project Settings -> General</a> and once a __Default Desktop App is configured__ each new Desktop test in the project is created directly configured to use it.
+The option is available in <a href="/features/project-settings/general" target="_blank">Project Settings -> General</a> and once a __Default Desktop App is set__ each new Desktop test in the project is configured to use it.
 
 ![Use default path](/img/automated-tests/desktop-testing/desktop-test/fig5.png)
 
-### Configure Application User Model ID 
+## Startup Arguments and Working Folder for Desktop Application
+
+The configuration of a desktop application lets you set startup __Arguments__ and a __Working folder__ if these are required for the proper functioning of the tested app. 
+
+![Arguments and Working folder](/img/automated-tests/desktop-testing/desktop-test/fig5a.png)
+
+## Configure Application User Model ID 
 
 Modern desktop applications are not always started with an executable file. Example of such apps are all applications from the Windows store, UWP or Maui-based apps. To enable this type of automation Test Studio Desktop tests support configuring a test using the <a href="https://docs.microsoft.com/en-us/windows/win32/shell/appids" target="_blank">Application User Model ID</a>. 
 
@@ -63,6 +77,20 @@ Modern desktop applications are not always started with an executable file. Exam
 ><br>
 > __Not sure what is the Applications ID for the tested app?__ Follow <a href="/automated-tests/desktop-testing/desktop-app-user-model-id" target="_blank">few simple steps to find the User Model Id</a> and use it in the Test Studio desktop test configuration. 
 
+## Do Not Launch Desktop Application
+
+This option lets you prevent the automatic start of an application on test startup. If you select it __use the steps to launch an application and connect the Test Studio process__ to it:
+
+- <a href="/features/custom-steps/desktop-common/launch-app-step" target="_blank">Launch application step</a> 
+- <a href="/features/custom-steps/desktop-common/connect-to-app" target="_blank">Connect to application step</a>
+
+![Do not launch default app](/img/automated-tests/desktop-testing/desktop-test/fig7.png)
+
+>__Tip__
+><br>
+><br>
+> __Initiate the recording session__ using the <a href="/automated-tests/test-execution/partial-test-execution#run-to-here" target="_blank">partial test run option Run->To Here</a>. 
+
 ## Finish Desktop Test Configuration
 
 Once you choose the path to the desktop application executable file, you can __confirm the configuration__ by pressing the __OK__ button. Then, use the <a href="/automated-tests/recording/overview#start-a-recording-session" target="_blank">__Record__ button</a> to launch the specified app in Test Studio recording mode.

docs/automated-tests/scheduling/multiple-machines-scheduling-setup/create-scheduling-server.md

@@ -143,6 +143,11 @@ Once the necessary data is entered, hit the **Apply** button to reflect the chan
 
 ![Scheduling SMTP][5a]
 
+> **Note**
+> <br>
+> <br>
+> If you are using an Outlook account with two-factor authentication enabled, you need to use an __Application password__ created for the SMTP configuration. See the response in <a href="https://learn.microsoft.com/en-us/answers/questions/602284/sending-email-with-smtp-while-two-factor-enable" target="_blank">this Microsoft forum post</a> for further details. 
+
 <br>
 <div><a style="float:right" href="#configure-the-test-studio-services">Back to top of section</a></div>
 <br>

docs/automated-tests/scheduling/remote-scheduled-run.md

@@ -126,6 +126,11 @@ Optionally, you can configure the Test Studio Scheduling service to use an Email
 
 ![Scheduling SMTP][13a]
 
+> **Note**
+> <br>
+> <br>
+> If you are using an Outlook account with two-factor authentication enabled, you need to use an __Application password__ created for the SMTP configuration. See the response in <a href="https://learn.microsoft.com/en-us/answers/questions/602284/sending-email-with-smtp-while-two-factor-enable" target="_blank">this Microsoft forum post</a> for further details. 
+
 <br>
 <div><a style="float:right" href="#configure-the-test-studio-services">Back to top of section</a></div>
 <br>

docs/automated-tests/wpf/wpf-test.md

@@ -6,12 +6,12 @@ position: 1
 ---
 # WPF Tests in Test Studio
 
-Test Studio recording feature supports WPF applications built with .Net 4.5+ or .Net Core 3.1 and above, and .Net 5. To be able to initiate recording session against specific application, you need to list its executable in the WPF test.
+Test Studio recording feature supports WPF applications built with .Net 4.5+ or .Net Core 3.1, and .Net 5 and above. To initiate recording session against specific application, you need to list its executable file in the WPF test.
 
 This article guides you through the WPF test configuration process.
 
 - [Configure WPF Test to Automate Specific App](#configure-wpf-test-to-record-specific-application)
-- [Set Default Project Path to WPF App](#set-default-wpf-application-path)
+- [Choose the Application to Automate](#choose-the-application-to-automate)
 - [Record Application Window State](#record-application-window-state)
 - [Finish WPF Test Configuration](#finish-wpf-test-configuration)
 
@@ -33,42 +33,59 @@ The __configuration of the WPF test requires an executable file of a valid WPF a
 
 ## Choose the Application to Automate
 
-Test Studio provides few options to define the application to automate - you can __browse to the folder__, where the executable file is located; or if the application is started, you can directly __select it from the list of active apps__.
+Test Studio provides different options to define the application to automate: 
 
-![Specify path to WPF app][2]
+- [Specify an executable file](#configure-application-path-in-wpf-test); 
+- [Use a default path](#set-default-wpf-application-path);
+- [Select application from the list of active apps](#select-running-wpf-application);
+- [Define startup arguments and working directory](#startup-arguments-and-working-folder-for-wpf-application)
 
-The __WPF Application Path__ field allows you to drag and drop the application's shortcut icon into it, or click _Browse_ and locate it manually in File Explorer. 
+![Specify path to WPF app][2]
 
-![Browse path to WPF app][3]
+## Configure Application Path in WPF Test
 
-The __Active WPF Applications__ list displays all WPF apps currently running and detected by Test Studio. Click on the desired one and hit the  __Select Application__ button and this will populate automatically the path to the executable file in the __WPF Application Path__ field.
+The __WPF Application Path__ field accepts drag and drop of the application's shortcut icon; Or use the __Browse__ button to locate the executable file manually in a File Explorer. 
 
-![Select running WPF app][4]
+![Browse path to WPF app][3]
 
-Once an executable file is selected, the __WPF Application Path__ and __Current Path Expanded__ fields get populated accordingly. __WPF Application Path__ supports environment tokens (i.e. _%Program Files%\MyApp\App.exe_) and when using such, the __Current Path Expanded__ field displays the full path to the executable file. 
+__WPF Application Path__ field supports using environment tokens (such as `%Program Files%\MyApp\App.exe`). When using environment tokens, the __Current Path Expanded__ field displays the full path to the executable file. 
 
 ![Selected app and expanded path][5]
 
 ## Set Default WPF Application Path
 
-The automation process requires multiple tests to be created for a single application. In such case configuring each created test will be a tedious task. Therefore Test Studio allows you to __set a default WPF app path on project level__ and use this for all WPF tests. The option is available in <a href="/features/project-settings/general" target="_blank">Project Settings -> General</a> and once a __Default Path is set__ each new WPF test in the project will be configured to use it.
+The automation process requires multiple tests to be created for a single application. In such case configuring each created test will be a tedious task. The solution offered by Test Studio is to __set a default WPF app path on project level__ and use this for all WPF tests. 
+
+The option is available in <a href="/features/project-settings/general" target="_blank">Project Settings -> General</a> and once a __Default Path is set__ each new WPF test in the project is configured to use it.
 
 ![Use default path][6]
 
+## Select Running WPF Application
+
+The __Active WPF Applications__ list displays all currently running WPF apps detected by Test Studio. Click on the desired one and hit the  __Select Application__ button and the path to the executable file in the __WPF Application Path__ field gets automatically populated.
+
+![Select running WPF app][4]
+
+## Startup Arguments and Working Folder for WPF Application
+
+The configuration of a WPF application lets you set startup __Arguments__ and a __Working folder__ if these are required for the proper functioning of the tested WPF app. 
+
+![Arguments and Working folder][5a]
+
 ## Record Application Window State
 
-For WPF tests you can choose whether to record the changes in the application window state - __Minimize, Maximize, Restore__ and __Close__ actions can be captured automatically in the recording process. If the recording scenarios require to interact with the window state, you can enable the checkbox under the __Recording Options__ section in the __Config Wizard__.
+Test Studio lets you record the changes in the application window state - __Minimize, Maximize, Restore__ and __Close__ actions can be captured automatically while in the recording process. If the automation scenarios require to interact with the window state, enable the checkbox under the __Recording Options__ section in the __Config Wizard__.
 
 ![record the changes in the application window state][7]
 
 > **Note**
 > <br>
 > <br>
-> Recording the changes in the application window state is a __setting on project level__. So, if it is enabled for one test in the project, it will be also applied for all existing and newly created WPF tests in the project.
+> __Recording the changes in the application window state is a setting on project level__. So, once you enable it for one WPF test in the project, it is applied for all existing and newly created WPF tests in the current project.
 
 ## Finish WPF Test Configuration
 
-Once you applied all necessary settings, you can __confirm the configuration__ by pressing the __OK__ button. Then, when you hit the <a href="/automated-tests/recording/overview#start-a-recording-session" target="_blank">__Record__ button</a>, the configured WPF application will be launched and the recorder will be attached to it, so you can proceed with recording the test scenario.
+Once you applied all necessary settings, __confirm the configuration__ by pressing the __OK__ button. Then, when you hit the <a href="/automated-tests/recording/overview#start-a-recording-session" target="_blank">__Record__ button</a>, the configured WPF application is launched and the Test Studio recorder gets attached to it, so you can proceed with recording the test scenario.
 
 > **Tip**
 > <br>
@@ -84,5 +101,6 @@ Once you applied all necessary settings, you can __confirm the configuration__ b
 [3]: /img/general-information/create-test-standalone/wpf-test/fig3.png
 [4]: /img/general-information/create-test-standalone/wpf-test/fig4.png
 [5]: /img/general-information/create-test-standalone/wpf-test/fig5.png
+[5a]: /img/general-information/create-test-standalone/wpf-test/fig5a.png
 [6]: /img/general-information/create-test-standalone/wpf-test/fig6.png
 [7]: /img/general-information/create-test-standalone/wpf-test/fig7.png

docs/features/azure-dev-ops-mapper/azure-results-sync.md

@@ -0,0 +1,65 @@
+---
+title: Azure Results Sync
+page_title: Azure Results Sync
+description: "Learn how to use Telerik.TestStudio.AzureTestPlansMapper.exe to create mappings between Test Studio tests and Azure DevOps test cases."
+position: 3
+---
+
+# Azure Results Sync
+
+**Telerik.TestStudio.AzureResultsSync.exe** is a CLI tool that converts Test Studio test results to Azure DevOps test results and uploads these as a new Azure DevOps run.
+
+# How to Use the Tool
+
+1. Run a Test Studio test list and specify where to output the results. 
+
+  - The run can be initiated using the <a href="/features/test-runners/artoftest-runner" target="_blank">CLI runner ArtOfTest.Runner.exe</a>. 
+  - Or through the project option <a href="/automated-tests/test-lists/test-list-execution#execute-test-list-locally" target="_blank">__'Run List'__</a> which outputs the results in the project sub-folder __'Results'__. 
+
+1. Use command prompt to run **Telerik.TestStudio.AzureResultsSync.exe**. 
+
+	- Use **url** parameter to specify the Azure DevOps organization. </br>
+    __For example:__ https://dev.azure.com/my-org
+  - Use **map** parameter to specify the absolute path to the mapping file generated from the mapper tool.
+  - Use **aiiresult** parameter to specify the absolute path to the Test Studio test list results file.
+  - Use **token** parameter to specify your personal access token (PAT). </br>
+    __Note:__ If **token** param is missing the tool tries to read the value from **TSAzureToken** environment variable. 
+
+
+# Local Machine Example
+
+```cmd 
+"c:\Program Files (x86)\Progress\Test Studio\Bin\AzureResultsMapper\Telerik.TestStudio.AzureResultsSync.exe" url=https://dev.azure.com/my-org token=<MY-TOKEN> map="<PATH-MAPPING-FILE>" aiiresult="<PATH-MAPPING-FILE>"
+```
+
+# Azure DevOps Example
+
+In the scenario of building a CI pipeline the test list run needs to be set through the Test Studio CLI runner ArtOfTest.Runner.exe with specifying where to output the result. Check <a href="/advanced-topics/build-server/azure-devops" target="_blank">here how to implement the test list execution in Azure DevOps pipeline</a>. Next comess the call to the mapper tool which defines where the results to be uploaded. 
+
+Below is an example pipeline with only these two jobs:
+
+```yml
+jobs:
+  - job: Run and Upload Results
+    steps:
+      - task: CmdLine@2
+        displayName: Run Test Studio tests
+        continueOnError: true
+        inputs:
+          script: |
+             "c:\Program Files (x86)\Progress\Test Studio\Bin\ArtOfTest.Runner.exe" list="$(System.DefaultWorkingDirectory)\TestingProjects\HTMLProject\MapperPipeline\TestLists\mixed list.aiilist" result=myResult
+
+      - task: CmdLine@2
+        displayName: Upload results
+        condition: always()
+        env:
+          TSAzureToken: $(System.AccessToken)
+        inputs:
+          script: |
+            "c:\Program Files (x86)\Progress\Test Studio\Bin\AzureResultsMapper\Telerik.TestStudio.AzureResultsSync.exe" url=https://dev.azure.com/prgs-devtools map=$(System.DefaultWorkingDirectory)\TestingProjects\HTMLProject\MapperPipeline\AzDoMap.tsazdo aiiresult=$(System.DefaultWorkingDirectory)\TestingProjects\HTMLProject\MapperPipeline\Results\myResult.aiiresult
+
+```
+
+- The __'Run Test Studio tests'__ task executes a test list with the ArtOfTest.Runner.exe and stores the results in file named myResult.aiiresult.
+- The __'Upload results'__ task converts the Test Studio results from myResult.aiiresult file and uploads them as new Azure DevOps run. 
+- The __'Upload results'__ task is configured to be executed always - "condition: always()". This way, even if the test execution from the previous step fails, the results get uploaded.