diff --git a/labs/azuredevops/agile/readme.md b/labs/azuredevops/agile/readme.md
index 84411c190d..486047f1fd 100644
--- a/labs/azuredevops/agile/readme.md
+++ b/labs/azuredevops/agile/readme.md
@@ -21,6 +21,8 @@ In this lab, you will learn about the agile planning and portfolio management to
### Prerequisites ###
+- Clone and build Azure DevOps Demo Generator
+
- This lab requires you to complete task 1 from the prerequisite instructions. (No cloning needed for this lab, skip Task 2)
diff --git a/labs/azuredevops/appregister/images/AppDetails.png b/labs/azuredevops/appregister/images/AppDetails.png
new file mode 100644
index 0000000000..1ce291273c
Binary files /dev/null and b/labs/azuredevops/appregister/images/AppDetails.png differ
diff --git a/labs/azuredevops/appregister/images/ChooseAPI.png b/labs/azuredevops/appregister/images/ChooseAPI.png
new file mode 100644
index 0000000000..f46da9a339
Binary files /dev/null and b/labs/azuredevops/appregister/images/ChooseAPI.png differ
diff --git a/labs/azuredevops/appregister/images/ChoosePermission.png b/labs/azuredevops/appregister/images/ChoosePermission.png
new file mode 100644
index 0000000000..46c9a49122
Binary files /dev/null and b/labs/azuredevops/appregister/images/ChoosePermission.png differ
diff --git a/labs/azuredevops/appregister/readme.md b/labs/azuredevops/appregister/readme.md
new file mode 100644
index 0000000000..b8d8330195
--- /dev/null
+++ b/labs/azuredevops/appregister/readme.md
@@ -0,0 +1,98 @@
+---
+title: Azure DevOps Lab Prerequisites
+layout: page
+sidebar: vsts
+permalink: /labs/azuredevops/appregister/
+folder: /labs/azuredevops/appregister/
+version: Lab version - 1.00.0
+updated: Last updated - 13/01/2025
+---
+
+
+
+## Overview
+
+Register Your Application in Azure AD
+
+
+
+## 1. Register a New Application
+
+- Sign in to the Azure Portal. Navigate to [Azure Portal](https://portal.azure.com).
+
+- Go to **Azure Active Directory** > **App registrations** > **New registration**.
+- Enter the following details:
+ - **Name**: Enter a meaningful name for your app.
+ - **Supported Account Types**: Choose an option based on your needs:
+ - Single tenant: Accounts in your organization only.
+ - Multi-tenant: Accounts in any organization's directory.
+ - **Redirect URI**: This is not required for Device Code Flow but can be added later if needed.
+- Click **Register**.
+
+
+
+## 2. Copy the Application (Client) ID
+
+- After registration, go to the **Overview** section.
+- Copy the **Application (client) ID** and the **Directory (tenant) ID** and save it for later.
+
+ 
+
+
+
+## 3. Configure API Permissions
+
+- Navigate to **API Permissions** > **Add a permission**.
+
+- Select **Azure DevOps** or any other API you want to access.
+
+ 
+
+
+
+## 4. Following are the scopes required
+
+| Scope | Description |
+| -------------------------- | ------------------------------------------ |
+| vso.agentpools | Agent Pools (read) |
+| vso.build_execute | Build (read and execute) |
+| vso.code_full | Code (full) |
+| vso.dashboards_manage | Team dashboards (manage) |
+| vso.extension_manage | Extensions (read and manage) |
+| vso.profile | User profile (read) |
+| vso.project_manage | Project and team (read, write and manage) |
+| vso.release_manage | Release (read, write, execute and manage) |
+| vso.serviceendpoint_manage | Service Endpoints (read, query and manage) |
+| vso.test_write | Test management (read and write) |
+| vso.variablegroups_write | Variable Groups (read, create) |
+| vso.work_full | Work items (full) |
+
+
+
+## 5. Configure the App Settings
+
+- Open your application’s configuration file (e.g., `appsettings.json`) under AppSettings.
+- Add the following details:
+
+ ```json
+ {
+ "AppSettings": {
+ "...": "...",
+ "clientId": "",
+ "tenantId": "",
+ "scope": "499b84ac-1321-427f-aa17-267ca6975798/.default"
+ }
+ }
+ ```
+
+- Replace placeholders with the actual values from the Azure Portal.
+
+
+
+## 5. Test the Application
+
+- Run your application.
+
+- The app will display a message instructing the user to go to `https://microsoft.com/devicelogin` and enter the provided device code.
+
+- After entering the code, users will authenticate, and the app will receive an access token.
diff --git a/labs/azuredevops/buildapp/readme.md b/labs/azuredevops/buildapp/readme.md
new file mode 100644
index 0000000000..11d597e3b1
--- /dev/null
+++ b/labs/azuredevops/buildapp/readme.md
@@ -0,0 +1,85 @@
+---
+title: Azure DevOps Lab Prerequisites
+layout: page
+sidebar: vsts
+permalink: /labs/azuredevops/buildapp/
+folder: /labs/azuredevops/buildapp/
+version: Lab version - 1.00.0
+updated: Last updated - 13/01/2025
+---
+
+
+
+## Overview
+
+To run the ADOGenerator project as a console application or executable, follow these steps:
+
+Ensure you have the following installed on your machine:
+
+- [.NET 8 SDK](https://dotnet.microsoft.com/download/dotnet/8.0)
+- [Visual Studio](https://visualstudio.microsoft.com/) or any other preferred IDE
+
+
+
+## Steps
+
+1. **Clone the Repository**
+ If you haven't already, clone the repository to your local machine:
+
+ ```sh
+ git clone
+ cd
+ ```
+
+2. **Open the Solution**
+ Open the ADOGenerator.sln solution file in Visual Studio or your preferred IDE.
+
+3. **Set ADOGenerator as the Startup Project**
+ In Visual Studio:
+
+ - Right-click on the ADOGenerator project in the Solution Explorer.
+ - Select Set as Startup Project.
+
+4. **Build the Solution**
+ Build the solution to ensure all dependencies are restored and the project compiles successfully:
+
+ - In Visual Studio, right-click on the solution in the Solution Explorer and select `Build Solution`.
+ - Alternatively, you can use the command line:
+ ```sh
+ dotnet build
+ ```
+
+5. **Run the Project**
+ To run the project as a console application:
+
+ - In Visual Studio, press `F5` or click on the Start button.
+ - Alternatively, you can run the project from the command line:
+ ```sh
+ dotnet run --project src/ADOGenerator/ADOGenerator.csproj
+ ```
+
+6. **Publish the Project**
+ To create an executable, publish the project:
+
+ - In Visual Studio, right-click on the ADOGenerator project in the Solution Explorer and select `Publish`.
+ - Follow the prompts to configure the publish settings (e.g., target folder, configuration, etc.).
+ - Alternatively, you can use the command line:
+ ```sh
+ dotnet publish src/ADOGenerator/ADOGenerator.csproj -c Release -r win-x64 --self-contained
+ ```
+
+7. **Run the Executable**
+ Navigate to the publish directory and run the executable:
+ ```sh
+ cd src/ADOGenerator/bin/Release/net8.0/win-x64/publish
+ ./ADOGenerator.exe
+ ```
+
+
+
+## Additional Notes
+
+- Ensure that any required configuration files (e.g., `appsettings.json`) are present in the output directory.
+- If you encounter any issues, check the console output for error messages and resolve any missing dependencies or configuration issues.
+
+By following these steps, you should be able to run the ADOGenerator project as a console application or executable.
diff --git a/labs/azuredevops/continuousdeployment/readme.md b/labs/azuredevops/continuousdeployment/readme.md
index 63d0bfe3bd..ab4930d1d2 100644
--- a/labs/azuredevops/continuousdeployment/readme.md
+++ b/labs/azuredevops/continuousdeployment/readme.md
@@ -24,6 +24,8 @@ In this lab, you will learn about the release management features available in A
- An Azure account (free from [https://azure.com/free](https://azure.com/free)).
+- Clone and build Azure DevOps Demo Generator
+
- Complete task 1 from the prerequisite instructions.
diff --git a/labs/azuredevops/continuousintegration/readme.md b/labs/azuredevops/continuousintegration/readme.md
index 04f36360e0..8275940954 100644
--- a/labs/azuredevops/continuousintegration/readme.md
+++ b/labs/azuredevops/continuousintegration/readme.md
@@ -23,6 +23,8 @@ In this lab, you will learn how to configure continuous integration (CI) and con
### Prerequisites ###
+- Clone and build Azure DevOps Demo Generator
+
- This lab requires you to complete task 1 from the prerequisite instructions.
diff --git a/labs/azuredevops/deliveryplans/readme.md b/labs/azuredevops/deliveryplans/readme.md
index fd9ddf7a14..9805a7ba9b 100644
--- a/labs/azuredevops/deliveryplans/readme.md
+++ b/labs/azuredevops/deliveryplans/readme.md
@@ -1,5 +1,5 @@
---
-title: Building a roadmap and tracking dependencies across teams with Delivery Plans
+title: Building a roadmap and tracking dependencies across teams with Delivery Plans
layout: page
sidebar: vsts
permalink: /labs/azuredevops/deliveryplans/
@@ -7,10 +7,11 @@ folder: /labs/azuredevops/deliveryplans/
version: Lab version - 1.37.1
updated: Last updated - 12/05/2022
---
+
-## Overview ##
+## Overview
It takes several teams to develop large software projects. Very large projects require multiple autonomous teams that can manage their own backlog and priority while contributing to a unified direction for that project. Regular reviews of the project schedule with these teams help ensure that the teams are working toward common goals. Delivery Plans provide the needed multi-team view of your project schedule.
@@ -20,188 +21,192 @@ It takes several teams to develop large software projects. Very large projects r
width: 48px; height: 48px;">Want additional learning? Check out the Manage Agile software delivery plans across teams module on Microsoft Learn.
-### Prerequisites ###
+
+### Prerequisites
+
+- Clone and build Azure DevOps Demo Generator
- This lab requires you to complete task 1 from the prerequisite instructions
-## Exercise 1: Managing Delivery Plans with Azure DevOps ##
+
+## Exercise 1: Managing Delivery Plans with Azure DevOps
-### Task 1: Creating a delivery plan ###
+
+### Task 1: Creating a delivery plan
1. From the **Boards** dropdown, select **Delivery Plans**.
- 
+ 
1. Click **New plan**.
- 
+ 
1. Since you may want to have multiple delivery plans for different aspects of your project, provide the specific name **"Web delivery"**. It should default to the **Parts Unlimited Team**, so select **Features** and click **Create**. Note that you could also organize your deliveries by **Stories** if you used that model instead. There is also the option to add additional teams and criteria to filter stories/features by, but we'll revisit those later.
- 
+ 
1. Due to the iteration reconfiguration performed earlier, the "Today" marker is right at the beginning of **Sprint 2**. We have a number of stories listed for delivery in the previous sprint, and we can also see an empty **Sprint 3**. Note that some of the stories shown are **Done**. Although it's useful to see the progress of work, we'll use that as an example by which to filter items out in a moment.
- 
+ 
1. Click the **Settings** button.
- 
+ 
1. Select the **Field criteria** tab and click **Add criteria**.
- 
+ 
1. Set the new criteria to filter down to items where **State** does not equal (**<>**) **Done**.
- 
+ 
1. We can also add a custom marker to keep track of significant dates. Select the **Markers** tab and click **Add marker**.
- 
+ 
1. Select the fourth Friday from today (it will be the Friday in the middle of **Sprint 3**) and set the **Label** to **"Team offsite"**. Select magenta as the **Color** and click **Save**.
- 
+ 
1. The first thing to notice is that the "Closed" story is no longer visible on the delivery plan due to the criteria set in the configuration. In addition, there is now a magenta marker in the middle of **Iteration 3** that says **"Team offsite"** when clicked.
- 
+ 
1. Another neat feature of the delivery plan extension is the ability to easily scale the calendar. You can use **Zoom out** to view multiple months at once. And **Zoom in** to a much more precise view.
- 
-
-
+ 
-### Task 2: Adding an external team to the project ###
+
+### Task 2: Adding an external team to the project
1. Our delivery plan has been pretty simple so far because we only have the one team. However, the real power of delivery planning comes into play when orchestrating multiple autonomous teams across their efforts. Open the settings page using the **Project Settings** navigation located at the bottom left of the page.
- 
+ 
1. From the **Teams** tab, click **New team**.
- 
+ 
1. This new team will be responsible for the efforts that involve integrating with external services, such as 3rd party services for things like weather forecasts and payment processing. Set the **Team name** to **"External integration team"** and click **Create team**.
- 
+ 
1. Select the **Project configuration** tab under **Boards**.
- 
+ 
1. Note the dates of **Sprint 2** and **Sprint 3**, which will vary for your account based on when you generated the project data. We're going to add two new iterations for the external services team that do not align exactly with the main team's schedule.
- 
+ 
1. With the root **PartsUnlimited** node select, click **New child**.
- 
+ 
1. Set the **Iteration name** to **"Iteration 50"**. Use today as the **Start date** and set the **End date** to three Fridays from today. This will also happen to be the day of the team offsite. Click **Save and close**.
- 
+ 
1. Use the same process to add an **Iteration 51** that starts the Monday after **Iteration 50** ends and has an end date three Fridays later.
- 
+ 
1. Now we need to configure the new team to use those new project sprints as its iterations. Select the **Teams** tab and click **External integration team**.
- 
+ 
1. Click **Iterations and Area Paths**.
- 
+ 
1. Select the **Iterations** tab.
- 
+ 
1. Click **Select iterations** and use the **+ Iteration** button to select **Iteration 50** and **Iteration 51**. Click **Save and close**.
- 
+ 
-### Task 3: Making delivery decisions ###
+
+### Task 3: Making delivery decisions
1. From the **Boards** dropdown, select **Delivery Plans**.
- 
+ 
1. Select the **Web Delivery** plan.
1. Click the **Settings** button.
- 
-
+ 
1. Select the **Teams** tab and click **Add team**.
- 
+ 
1. Select the **External integration team** and **Features**. Click **Save**.
- 
+ 
1. Use the **Zoom out** to fit the width of **Iteration 50** and **Iteration 51**.
- 
+ 
1. The new team doesn't have any stories added yet. Fortunately, you can add them directly to their team and iteration using the inline functionality. Select the **Iteration 50** iteration. Click the **New item** button that appears.
- 
+ 
1. Enter **"Integrate with weather service"** and press **Enter**. That item is now in the backlog with its area and iteration configured.
- 
+ 
1. Follow the same process to add an item for integrating with corporate branding assets to **Iteration 51**.
- 
+ 
1. Now we can step back to see how these two teams are working toward our common goals. Upon closer examination, it appears that the main team is planning to reuse some corporate branding assets during the current sprint that will not be available until well after it's over. It's a good thing we have this view to catch these sort of potential problems early on.
- 
+ 
1. The first thing we should do is to move the branding integration work to an earlier iteration. Drag and drop the corporate branding story onto **Iteration 50**. In order to free up the bandwidth, drag the weather service story onto **Iteration 51**.
- 
+ 
1. Next, drag the branding work item from **Sprint 1** to **Sprint 3** so that there's a chance the dependencies will be available in time for this team to be unblocked.
- 
+ 
1. Now we can review the delivery plan again. It should be more feasible now.
- 
-
+ 
1. There are a lot of ways to quickly customize the view of the delivery plan. For example, you can collapse all teams (or specific teams) using the toggle buttons next to their names.
- 
+ 
### Task 4 : Track dependencies by using Delivery Plans
-With Delivery Plans, you can track dependencies that have been added to work items. Dependency tracking supports the **Predecessor/Successor** link type between work items.
+
+With Delivery Plans, you can track dependencies that have been added to work items. Dependency tracking supports the **Predecessor/Successor** link type between work items.
1. Navigate to **Web Delivery** Plan.
1. Move branding feature to **Sprint 1**
- 
+ 
1. And click on **Links** tab and add **Integrate with weather service** and **integrating with corporate branding assets** features as **Successors** and **Save & Close**
- 
+ 
1. Now your delivery plan looks like below. Click on  to view the dependency summary
-
- 
-1. You can see the Dependencies detailed view. This indicates that the work item has two successors and no issues with delivery dates.
+ 
+
+1. You can see the Dependencies detailed view. This indicates that the work item has two successors and no issues with delivery dates.
@@ -216,11 +221,11 @@ With Delivery Plans, you can track dependencies that have been added to work ite
1. Click on **Show all dependencies** icon. Dependency lines that have no issues show up as black lines. Dependency lines that have issues, show up with red lines. To view the issue or details you can click on those lines.
-
+
## Reference
Thanks to **Nagaraj Bhairaji** for making a video on this lab. You can watch the following video that walks you through all the steps explained in this lab
-
\ No newline at end of file
+
diff --git a/labs/azuredevops/exploratorytesting/readme.md b/labs/azuredevops/exploratorytesting/readme.md
index de4c6162bb..b9a5717bad 100644
--- a/labs/azuredevops/exploratorytesting/readme.md
+++ b/labs/azuredevops/exploratorytesting/readme.md
@@ -8,23 +8,29 @@ version: Lab version - 1.38.0
updated: Last updated - 9/11/2019
redirect_from: "/labs/vsts/exploratorytesting/index.htm"
---
+
-## Overview ##
+## Overview
In this lab, you will learn about the exploratory testing and feedback management capabilities provided in the Test & Feedback extension. You will learn about how exploratory testing (also called XT, or agile testing) has become a first-class experience in the toolset. This allows a tester to more flexibly test the underlying software without relying solely on formal test cases. You'll also learn about how you can manage the process of eliciting and managing the customer feedback lifecycle.
-### Prerequisites ###
+
+### Prerequisites
+
+- Clone and build Azure DevOps Demo Generator
- This lab requires you to complete tasks 1 and 2 from the prerequisite instructions.
-## Exercise 1: Exploratory Testing ##
+
+## Exercise 1: Exploratory Testing
-### Task 1: Installing the Chrome Extension ###
+
+### Task 1: Installing the Chrome Extension
1. Install **Google Chrome** from [http://google.com/chrome](http://google.com/chrome). The rest of this exercise will use Chrome as its browser. If you're already using Chrome, just open a new instance for the next set of steps.
@@ -32,133 +38,134 @@ In this lab, you will learn about the exploratory testing and feedback managemen
1. Select the **Azure DevOps** tab. Search for "**feedback**" and click the **Test & Feedback** extension.
- 
+ 
1. Click on **Install** button on the details page.
- 
+ 
1. Click **Install** for the Chrome extension.
- 
+ 
1. In the **Chrome Web Store**, click **Add to Chrome**.
- 
+ 
1. Confirm the installation when asked.
- 
+ 
1. To open the extension, click the extension icon that will appear on the right of the address bar. Select the **Connection Settings** tab. Enter the URL of your Azure DevOps instance, such as "**https://dev.azure.com/MYTEAM**", as the **Server URL** and click **Next**.
- 
+ 
1. The extension can be used in two modes: **Connected** and **Standalone** mode. If you have Azure DevOps or Azure DevOps Server, select Connected mode. Standalone mode is for users who don't have either and want to use the extension to file bugs and share the report with their team.
1. After connecting to Azure DevOps, you will need to select the team you want these efforts associated with. Select the **Parts Unlimited Team** under the **Parts Unlimited** project and click **Save** to continue.
- 
+ 
-### Task 2: Exploratory Testing with the Chrome Extension ###
+
+### Task 2: Exploratory Testing with the Chrome Extension
1. In **Visual Studio**, press **F5** to build and run the **Parts Unlimited** project locally.
1. To start an exploratory testing session, click the **Start session** button from the extension toolbar.
- 
+ 
1. Navigate to [http://localhost:5001](http://localhost:5001/).
1. In search box enter **"jumper lead"** and press **Enter**.
- 
+ 
1. You will see the search results as shown below.
- 
+ 
1. Now in the search box enter **"jumper leads"** and press **Enter**.
- 
+ 
1. You can see there are no search results. When you search for **jumper lead** it showed the results. But when you search for **jumper leads** it showed no results. This seems to be a bug.
- 
+ 
1. Click the **Exploratory Testing** icon button and select **Capture screenshot | Browser**.
- 
+ 
1. Select a section of the screen and change the name of the screenshot to something more descriptive. Note that there are a variety of drawing tools available to really help you get your point across. Click the **Blur area** button.
- 
+ 
1. Highlight a section of the screenshot, which will be blurred out to become illegible. This makes it easy to report bugs and create other work items without risking sensitive information. Click the **Save screenshot** button to add it to the current session's timeline.
- 
+ 
1. Click the **Add note** button to start a note. Type in something insightful and click **Save** to save the note to the session's timeline.
- 
+ 
1. You can also record screen video to capture flaky issues like flickering, abnormal behavior of the web application etc. that are difficult to capture using screenshots alone. To record your screen click the **Record screen** button and click **Start recording**.
- 
+ 
1. Select the appropriate screen you want to record from the **Application Window** tab. In this case, select the 404 page and click **Share**. The recording for the screen selected has started.
- 
+ 
1. Search for **"jumper lead"** and show the results. Then search for **"jumper leads"** and show the lack of results.
- 
+ 
1. Click the **Stop recording** button on the extension to stop recording the screen. The screen recording gets saved.
- 
+ 
1. Click on the **View session timeline** button. You can see that all the content - screenshots, notes and videos you've captured are available in the current session's timeline. You can open the screenshots, read your notes or play the video from here.
- 
+ 
-### Task 3: Creating Bugs with the Chrome Extension ###
+
+### Task 3: Creating Bugs with the Chrome Extension
1. Click the **Create bug** icon button followed by the expanded **Create bug** text button.
- 
+ 
1. Enter **"Search for jumper leads fails"** as the name of the bug. All the screenshots and videos captured earlier are already a part of the bug. In addition to this the image action log (user actions) has also been inserted for you so that it's easy for others to easily reproduce the issue. Click **Save** to save the bug to Azure DevOps.
- 
+ 
1. Another great feature of this extension is its ability to view similar bugs and thus reduce redundant issues. Let's say you were another tester who happened to find this same bug and weren't aware that it was already logged. Click the **Create bug** icon button followed by the expended **Create bug** text button again to start a new bug form.
- 
+ 
1. As you type the title **"jumper leads**" for the bug you will notice that the extension has detected that there is already another bug in the backlog with a similar title. Click **1 similar** to view the similar bug.
- 
+ 
1. This bug appears to be the same as the one we were about to file, so select it and click **Edit** to edit the existing bug rather than to file a new bug.
- 
+ 
1. At this time the current repro steps are added to the image action log. In practice, you would now review the existing repro steps to determine if you located this bug using a different method, in which case you would update the contents to indicate that your method is an alternative repro. Click **Save** to save the bug.
- 
+ 
1. Click the **View session timeline** icon button and click the last created **Bug** link to open it.
- 
+ 
1. Now back on the Azure DevOps site, you can update the bug as needed, such as by assigning it to someone or adjusting the severity.
- 
+ 
1. In Chrome, end the testing session by clicking the **Stop Session** button.
- 
-
+ 
diff --git a/labs/azuredevops/load/readme.md b/labs/azuredevops/load/readme.md
index 50bfb518c4..499a701f1b 100644
--- a/labs/azuredevops/load/readme.md
+++ b/labs/azuredevops/load/readme.md
@@ -8,36 +8,42 @@ version: Lab version - 1.38.0
updated: Last updated - 03/26/2021
redirect_from: "/labs/vsts/load/index.htm"
---
+
-## Overview ##
+## Overview
In this lab, you will be introduced to the [Web performance and Load testing capabilities](https://www.visualstudio.com/en-us/docs/test/performance-testing/getting-started/getting-started-with-performance-testing) provided in Visual Studio Enterprise 2017. You will walk through a scenario using a fictional online storefront where your goal is to model and analyze its performance with a number of simultaneous users. This will involve the definition of web performance tests that represent users browsing and ordering products, the definition of a load test based on the web performance tests, and finally the analysis of the load test results.
-### Prerequisites ###
+
+### Prerequisites
- This lab requires that your **Visual Studio 2017** instance have the **Web performance and load testing tools** installed from the **Individual components** tab of the **Visual Studio Installer**.
+- Clone and build Azure DevOps Demo Generator
+
- This lab requires you to complete tasks 1 and 2 from the prerequisite instructions.
- This lab requires Microsoft Excel.
{% include note.html content= "Azure DevOps cloud-based load testing service feature is deprecated. And Visual Studio 2019 will be the last version of Visual Studio with the web performance and load test capability. For more information click [here](https://devblogs.microsoft.com/devops/cloud-based-load-testing-service-eol/) " %}
-## Exercise 1: Web Application Load and Performance Testing with Visual Studio 2017 ##
+
+## Exercise 1: Web Application Load and Performance Testing with Visual Studio 2017
-### Task 1: Recording web tests ###
+
+### Task 1: Recording web tests
1. In **Solution Explorer**, right-click the solution node and select **Add \| New Project**.
- 
+ 
1. Select the **Visual C# \| Test** category and the **Web Performance and Load Test Project** template. Enter a **Name** of **"PULWebTest"** and click **OK**.
- 
+ 
1. Once the project has been created, select **Debug \| Start Without Debugging** to build and launch the site locally.
@@ -45,339 +51,344 @@ In this lab, you will be introduced to the [Web performance and Load testing cap
1. The default (and empty) **WebTest1.webtest** file will be open as a result of the earlier project creation. Click the **Add Recording** button to begin a recording session.
- 
+ 
1. If asked to enable the extension in your browser, click to allow it. Then close the window and restart the recording session from Visual Studio using the previous step.
1. In the newly opened browser window, navigate to [http://localhost:5001/](http://localhost:5001/). This is the URL of the project site.
- 
+ 
1. Click the **Lighting** tab.
- 
+ 
1. Click the **Bugeye Headlights** product.
- 
+ 
1. Continue browsing the site to generate more traffic, if desired. However, do not log in or add anything to your cart. When ready to move on, click **Stop** in the **Web Test Recorder**.
- 
+ 
1. After stopping the recording session, Visual Studio will analyze the recorded traffic to attempt to identify dynamic parameters that can be abstracted for dynamic configuration later on.
- 
+ 
1. An initial test will also be run. However, it will likely fail based on some requests for Application Insights resources that were not configured in this starter project.
- 
+ 
1. In the web test, select each step for the placeholder URL (if there) and any tracking requests and press the **Delete** key to remove them one by one. You can also delete steps to download resources, such as fonts. When you're done, you should only have three requests: the **site root**, **/Store/Browse**, and **/Store/Details/2**.
- 
+ 
1. In the **Test Results** window, select the failed test and click **Run**.
- 
+ 
1. Since the browsing was basic, it should easily pass. Double-click the successful run to load its details.
- 
+ 
1. Select different requests throughout the test run to see details on how it performed, how large the payloads were, and so on. You can also dig into the specific HTTP requests and responses.
- 
+ 
1. Close the test results.
-### Task 2: Working with web tests ###
+
+### Task 2: Working with web tests
1. From **Solution Explorer**, open **WebTest1.webtest** if it's not already open.
- 
+ 
1. Locate the step that navigates to **/Store/Browse** and expand **QueryString Parameters**. Note that the parameters have been extracted so that you can easily swap in different values to test with other values.
- 
+ 
1. In **Solution Explorer**, rename **WebTest1.webtest** to **Browsing.webtest**.
- 
+ 
1. In **Browsing.webtest**, click the **Set Request Details** button.
- 
+ 
1. This dialog enables you to configure the **Think Time** to use for each step. **Think Time** simulates the time an end user would stop to read the current page, think about their next action, etc. Here you can manually set how much time to use for each step, as well as to set goals for response time on each navigation. Click **Cancel**.
- 
+ 
-### Task 3: Recording sophisticated tests ###
+
+### Task 3: Recording sophisticated tests
1. For the rest of this exercise we will need a registered site user. Return to the original browser window opened when running the project.
- 
+ 
1. Click **Register as a new user**.
- 
+ 
1. Register with the email **[admin@test.com](mailto:admin@test.com)** and password **P@ssw0rd**.
- 
+ 
1. Now we can add a more sophisticated test that involves completing a purchase. Return to **Visual Studio**.
1. In **Solution Explorer**, right-click the **PULWebTest** project and select **Add \| Web Performance Test**.
- 
+ 
1. Navigate to [http://localhost:5001/](http://localhost:5001/) like before.
- 
+ 
1. Click **Log in**.
- 
+ 
1. Enter the email **admin@test.com** and password **P@ssw0rd**. Click **Login**.
- 
+ 
1. Click the **Batteries** tab.
- 
+ 
1. Click the **12-Volt Calcium Battery**.
- 
+ 
1. Click **Add to Cart**.
- 
+ 
1. Click **Checkout**.
- 
+ 
1. Enter shipping information (details are not important) and be sure to use the Promo Code **FREE**. Click **Submit Order**.
- 
+ 
1. On the checkout page, click **view your order** to review the order details.
- 
+ 
1. The details should all match what you entered earlier.
- 
+ 
1. Click **Stop** in the **Web Test Recorder** to continue.
- 
+ 
1. In **Solution Explorer**, rename **WebTest1.webtest** to **Buying.webtest**.
- 
+ 
1. Like earlier, delete any steps that aren't made to the [http://localhost:5001/](http://localhost:5001/) site or are to resource files, like .EOTs.
-### Task 4: Viewing web test result details ###
+
+### Task 4: Viewing web test result details
1. As before, Visual Studio will process the recorded steps and then attempt to execute the test. Double-click the failed test run to view it.
- 
+ 
1. Locate the failed step after the checkout completes and click it. It should be the redirect that occurs immediately after the order is submitted. Click the **Details** tab to confirm.
- 
+ 
1. This failure makes sense. In our original test, we checked out and received an order number embedded in the redirect URL. However, since the next test run would presumably result in a different order number, the redirect received would have a different URL from the one expected. Right-click the failed step and select **Go to Web Test** to review that step in the process.
- 
+ 
1. Depending on your test goals, you might want to have the test to dynamically accept the order number returned and track it throughout the remainder of the test. However, for the purposes of this lab we will simply delete that step to avoid the failure. Right-click the step and select **Delete**.
- 
+ 
1. Click the **Run Test** button again to confirm the test passes now.
- 
+ 
1. The test should pass as expected.
- 
+ 
1. Return to **Buying.webtest** and click the **Set Request Details** button.
- 
+ 
1. Since we're going to use this test as part of a load testing run, let's update the **Think Time** columns with some realistic numbers. Try to have the whole run use around 30 seconds of total think time. For example, you may want the obvious navigations to each have 5 seconds of think time while all the other requests have 0. Click **OK** when done.
- 
+ 
-### Task 5: Adding a load test ###
+
+### Task 5: Adding a load test
1. Now that we have two tests that cover common scenarios, let's use them as part of a load test to see how the system might perform with a variety of simultaneous users. In **Solution Explorer**, right-click the **PULWebTest** project and select **Add \| Load Test**.
- 
+ 
1. There are two options for load testing: **cloud-based** and **on-premises**. The cloud-based load testing hosted by **Azure DevOps** offers a massively scalable environment to truly stress test your system. However, in this scenario we're going to select **On-premise Load Test** to contain testing entirely within the VM. Click **Next**.
- 
+ 
-
1. The **Run Settings** enable you to indicate whether you'd like to run the test for a specified duration or if you'd like to run for a certain number of iterations. In this scenario, select **Load test duration** and set the **Run duration** to **1** minute. You can also configure a variety of details for testing, such as the **Sampling rate** for collecting data. Keep this at **15** seconds. Click **Next**.
- 
+ 
1. Enter the name **"BrowseAndOrderProduct"** and click **Next**. Note that you could optionally configure how think times are applied. Although we entered explicit think times earlier, we can use the default option to add a degree of randomness (normally distributed based on the recorded times) so that each set of requests isn't exactly the same. Click **Next**.
- 
+ 
1. We'll keep things simple by have a **Constant Load** of **5** users. However, there are scenarios where you might prefer to have the users scale up over the course of the test to simulate growing traffic. Click **Next**.
- 
+ 
1. Since the users will vary across tests, you can select an algorithm for modeling how they vary. For example, if they are **Based on the total number of tests**, this allows you to specify the percentages that each test will be run. This is particularly useful when dealing with a scenario where you find that 1 out of every 4 users who browse the site end up buying something. In that case, you would want a mix of 75% "browsers" and 25% "browse & buyers". Click **Next**.
- 
+ 
1. Click **Add** to select tests to add to the mix.
- 
+ 
1. Select the **Browsing** and **Buying** tests and add them to the mix. Click **OK**.
- 
+ 
1. Set the relative percentages to **75** and **25**. Click **Next**.
- 
+ 
1. As with the tests, you can configure the network type mix to use when testing. Select **LAN** for all and click **Next**.
- 
+ 
1. As with network types, you can also specify the mix of browsers. Select **Internet Explorer 9.0** for all and click **Next**.
- 
+ 
1. As part of the load testing you can collect performance counters. Click **Add Computer** to add a computer to the test.
- 
+ 
1. Set the name of the computer to **localhost** and check **ASP.NET** and **SQL**. Click **Finish**.
- 
+ 
1. In **Solution Explorer**, double-click **Local.testsettings** under **Solution Items** to open it.
- 
+ 
1. The **General** tab provides a place for you to update basic info about the test, such as whether it should be run locally or in Azure DevOps.
- 
+ 
1. Select the **Data and Diagnostics** tab to view the available adapters. Options include those for **ASP.NET**, **Event Log**, **IntelliTrace**, **Network Emulation**, and more. No adapters are selected by default because many of them have a significant impact on the machines under test and can generate a large amount of data to be stored over the course of long load tests.
- 
+ 
-### Task 6: Configuring the test controller ###
+
+### Task 6: Configuring the test controller
1. **LoadTest1.loadtest** should already be open. Click the **Manage Test Controllers** button.
- 
+ 
1. No connection string will be set yet, so click the **Browse** button to specify one.
- 
+ 
1. Select a local database to use and click **OK** to save.
- 
+ 
1. Press **Esc** to close the **Manage Test Controller** dialog.
-### Task 7: Executing, monitoring, and reviewing load tests ###
+
+### Task 7: Executing, monitoring, and reviewing load tests
1. Click the **Run Load Test** button to begin a load test.
- 
+ 
1. The test will run for one minute, as configured. By default, you should see four panels showing some key statistics, with some key performance counters listed below that. Data is sampled every 15 seconds based on our configuration from earlier.
- 
+ 
1. After the load test run finishes, it will automatically switch to the **Summary** view. The **Summary** view shows overall aggregate values and other key information about the test. Note that the hyperlinks to specific pages open up even more details in the **Tables** view.
- 
+ 
1. Select the **Graphs** view and change the layout to use **Two Horizontal Panels**. The views are very flexible.
- 
+ 
1. By default, the top graph will show **Key Indicators** and the bottom graph will show **Page Response Time**. These are two very important sets of data for any web application.
- 
+ 
1. Click one of the **Key Indicator** graph lines or data points and select it. This will also highlight the counter that it is associated with the below graphs. The red line from the screenshot below represents the **User Load** at different points during the load test.
- 
+ 
1. Click the **Pages/Sec** row from the **Key Indicators** section of the counter grid to highlight it in the graph. In the screenshot shown below we can see that the average number of pages per second over the duration of the test was **1.18** (this may vary for you).
- 
+ 
-### Task 8: Generating and viewing load test trend reports ###
+
+### Task 8: Generating and viewing load test trend reports
1. Even though the initial load test may result in some numbers that don't seem to provide a wealth of information it does provide a good baseline and allow us to make relative measures between test runs to help measure performance impacts of code changes. For example, if we had seen a relatively high level of batch requests per second during our initial load tests, perhaps that could be addressed by adding in some additional caching, and then re-testing to make sure that the request per second goes down.
1. Return to **LoadTest1.loadtest** and click the **Run Load Test** button to run the load test again. Now there will be at least two test results to work with so that we can see how to perform some trend analysis. Feel free to run it a few times if you'd like lots of trend data.
- 
+ 
1. When the final load test is complete, click the **Create Excel Report** button from the toolbar to load **Excel**.
- 
+ 
1. Click **Next**.
- 
+ 
1. Select **Trend** and click **Next**.
- 
+ 
1. Set the **Report Name** to **"LoadTestTrend"** and click **Next**.
- 
+ 
1. Select all available runs.
- 
+ 
1. Keep the default performance counters selected and click **Finish**.
- 
+ 
1. Excel will now generate a thorough report based on the results from the various test runs.
- 
+ 
1. Click **Avg. Page Time** to view those results.
- 
+ 
1. Your report will vary based on the test results and number of tests. However, you can easily see how this would be very useful when analyzing how changes in the solution impacted performance. You would very easily be able to track a performance regression to a time (and build).
- 
-
+ 
diff --git a/labs/azuredevops/packagemanagement/readme.md b/labs/azuredevops/packagemanagement/readme.md
index a31c6f7a11..14944c2945 100644
--- a/labs/azuredevops/packagemanagement/readme.md
+++ b/labs/azuredevops/packagemanagement/readme.md
@@ -8,10 +8,11 @@ version: Lab version - 1.38.0
updated: Last updated - 05/11/2020
redirect_from: "/labs/vsts/packagemanagement/index.htm"
---
+
-## Overview ##
+## Overview
**Azure Artifacts** is an extension that makes it easy to discover, install, and publish NuGet, npm, and Maven packages in Azure DevOps. It's deeply integrated with other hubs like Build so that package management can become a seamless part of your existing workflows.
@@ -19,37 +20,40 @@ redirect_from: "/labs/vsts/packagemanagement/index.htm"
width: 48px; height: 48px;">Want additional learning? Check out the Manage build dependencies with Azure Artifacts module on Microsoft Learn.
-### Prerequisites ###
+
+### Prerequisites
- Visual Studio 2017 or later
-- This lab requires you to complete tasks 1 and 2 from the prerequisite instructions
+- Clone and build Azure DevOps Demo Generator
+
+- This lab requires you to complete tasks 1 and 2 from the prerequisite instructions
-## Exercise 1: Working with Azure Artifacts ##
-**Azure Artifacts** is an extension to Azure DevOps Services and Azure DevOps Server. It comes pre-installed in Azure DevOps Services, Azure DevOps Server 2019, Team Foundation Server (TFS) 2017 and 2018.
+## Exercise 1: Working with Azure Artifacts
+
+**Azure Artifacts** is an extension to Azure DevOps Services and Azure DevOps Server. It comes pre-installed in Azure DevOps Services, Azure DevOps Server 2019, Team Foundation Server (TFS) 2017 and 2018.
-### Task 1: Creating and connecting to a feed ###
+
+### Task 1: Creating and connecting to a feed
1. Navigate to the **Artifacts** hub.
- 
+ 
1. Click **Create feed**. This feed will be a collection of NuGet packages available to users within the organization and will sit alongside the public NuGet feed as a peer. The scenario in this lab will focus on the workflow for using Azure Artifacts, so the actual architectural and development decisions are purely illustrative.
- 
+ 
1. This feed will include common functionality that can be shared across projects in this organization. Select the scope as **Organization** for this lab. Set the name to **"PartsUnlimitedShared"** and click **Create**. Leave the default options.
- 
+ 
1. Any user who wants to connect to this NuGet feed must configure their environment. Click **Connect to feed**.
- 
-
-
+ 
1. In the **Connect to feed** window, select **Visual Studio** and copy the **Source** url . This is the only thing Visual Studio and NuGet need to start taking advantage of the new feed. Leave the dialog open in the browser.
@@ -58,191 +62,196 @@ redirect_from: "/labs/vsts/packagemanagement/index.htm"
1. Launch a **new** instance of **Visual Studio**. Do not use the instance open from cloning the primary **Parts Unlimited** solution.
1. Select **Tools \| NuGet Package Manager \| Package Manager Settings**.
-
- 
+ 
1. Locate the **Package Sources** section and click the **Add** button to add a new package source.
- 
+ 
1. Set the **Name** to **"PartsUnlimitedShared"** and paste the **Source** URL copied earlier. Click **Update** followed by **OK**. Visual Studio is now connected to the new feed.
- 
+ 
1. Close and Reopen the other Visual Studio instance used for cloning the PartsUnlimited repository ( prerequisites Task 2), so that it shows this new source.
-### Task 2: Creating and publishing a NuGet package ###
-1. From the main menu of **Visual Studio**, select **File \| New \| Project** ("Create a new project" in VS2019). We will now create a shared assembly that will be published as a NuGet package so that other teams can integrate it and stay up to date without having to work directly with the project source.
+### Task 2: Creating and publishing a NuGet package
-1. From the **Visual C#** section, select the **Class Library (.NET Framework)** template and set the **Name** to **"PartsUnlimited.Shared"**. Click **OK** to create the project.
-(If VS2019 used, look for "class" in the finder and select **Class Library (.NET Framework)** and choose version 4.5.1)
+1. From the main menu of **Visual Studio**, select **File \| New \| Project** ("Create a new project" in VS2019). We will now create a shared assembly that will be published as a NuGet package so that other teams can integrate it and stay up to date without having to work directly with the project source.
- **VS2017**
+1. From the **Visual C#** section, select the **Class Library (.NET Framework)** template and set the **Name** to **"PartsUnlimited.Shared"**. Click **OK** to create the project.
+ (If VS2019 used, look for "class" in the finder and select **Class Library (.NET Framework)** and choose version 4.5.1)
- 
+ **VS2017**
- **VS2019**
+ 
- 
- 
+ **VS2019**
-1. In **Solution Explorer**, delete **Class1.cs**.
+ 
+ 
+
+1. In **Solution Explorer**, delete **Class1.cs**.
-1. Right-click the project node and select **Properties**.
+1. Right-click the project node and select **Properties**.
-1. Set the **Target framework** to **.NET Framework 4.5.1** and click **Yes** to confirm the change. (Confirm the same if you are using VS2019)
+1. Set the **Target framework** to **.NET Framework 4.5.1** and click **Yes** to confirm the change. (Confirm the same if you are using VS2019)
-1. Press **Ctrl+Shift+B** to build the project. In the next task we'll use **NuGet.exe** to generate a NuGet package directly from the built project, but it requires the project to be built first.
+1. Press **Ctrl+Shift+B** to build the project. In the next task we'll use **NuGet.exe** to generate a NuGet package directly from the built project, but it requires the project to be built first.
-1. Return to the Azure DevOps browser tab. On the feed created before click **Connect to Feed** \| **NuGet.exe** \| **Get the tools**.
+1. Return to the Azure DevOps browser tab. On the feed created before click **Connect to Feed** \| **NuGet.exe** \| **Get the tools**.
-1. Click on **Download the latest Nuget**
+1. Click on **Download the latest Nuget**
-1. On the opened window, select nuget.exe version **v5.5.1**
-
+1. On the opened window, select nuget.exe version **v5.5.1**
-1. Return to **Visual Studio**. From **Solution Explorer**, right-click the **PartsUnlimited.Shared** project node and select **Open Folder in File Explorer**.
+1. Return to **Visual Studio**. From **Solution Explorer**, right-click the **PartsUnlimited.Shared** project node and select **Open Folder in File Explorer**.
-1. Move the downloaded **nuget.exe** file into the folder containing the **.csproj** file.
+1. Move the downloaded **nuget.exe** file into the folder containing the **.csproj** file.
-1. In the same **Windows Explorer** window, select **File \| Open Windows PowerShell \| Open Windows PowerShell as administrator**.
+1. In the same **Windows Explorer** window, select **File \| Open Windows PowerShell \| Open Windows PowerShell as administrator**.
-1. Execute the line below to create a **.nupkg** file from the project. Note that this is a quick shortcut to package the NuGet bits together for deployment. NuGet is very customizable and offers a lot of great flexibility for providing detailed information for consumers. You can learn more over on the [NuGet package creation page](https://docs.microsoft.com/en-us/nuget/create-packages/overview-and-workflowhttps:/docs.microsoft.com/en-us/nuget/create-packages/overview-and-workflow).
+1. Execute the line below to create a **.nupkg** file from the project. Note that this is a quick shortcut to package the NuGet bits together for deployment. NuGet is very customizable and offers a lot of great flexibility for providing detailed information for consumers. You can learn more over on the [NuGet package creation page](https://docs.microsoft.com/en-us/nuget/create-packages/overview-and-workflowhttps:/docs.microsoft.com/en-us/nuget/create-packages/overview-and-workflow).
```
./nuget.exe pack ./PartsUnlimited.Shared.csproj
```
-1. NuGet builds a minimal package based on the information it is able to pull from the project. For example, note that the name is **PartsUnlimited.Shared.1.0.0.nupkg**. That version number was pulled from the assembly.
+
+1. NuGet builds a minimal package based on the information it is able to pull from the project. For example, note that the name is **PartsUnlimited.Shared.1.0.0.nupkg**. That version number was pulled from the assembly.
-1. Return to **Visual Studio**. From **Solution Explorer**, open **Properties\AssemblyInfo.cs**.
+1. Return to **Visual Studio**. From **Solution Explorer**, open **Properties\AssemblyInfo.cs**.
-1. The **AssemblyVersion** attribute specifies the version number to build into the assembly. Each NuGet release requires a unique version number, so if we continue to use this method for creating packages, we will need to remember to increment this before building.
+1. The **AssemblyVersion** attribute specifies the version number to build into the assembly. Each NuGet release requires a unique version number, so if we continue to use this method for creating packages, we will need to remember to increment this before building.
-1. Return to the **PowerShell** window and execute the following command (it should be on one line). Note that you need to provide an "API Key", which can be any non-empty string. We're using **"VSTS"** here. Log in using your Azure DevOps credentials when asked.
+1. Return to the **PowerShell** window and execute the following command (it should be on one line). Note that you need to provide an "API Key", which can be any non-empty string. We're using **"VSTS"** here. Log in using your Azure DevOps credentials when asked.
```
./nuget.exe push -source "PartsUnlimitedShared" -ApiKey VSTS PartsUnlimited.Shared.1.0.0.nupkg
```
-1. The command should succeed after a few seconds.
+
+1. The command should succeed after a few seconds.
-1. Return to the browser window open to Azure DevOps and **refresh** the window. You should now see the organization's NuGet package is published in the feed. Click it to view the details.
+1. Return to the browser window open to Azure DevOps and **refresh** the window. You should now see the organization's NuGet package is published in the feed. Click it to view the details.
-1. The details have been imported and are now ready for others to consume.
+1. The details have been imported and are now ready for others to consume.
-### Task 3: Importing a NuGet package ###
+
+### Task 3: Importing a NuGet package
1. Switch to the instance of **Visual Studio** that has the full **Parts Unlimited** solution open.
1. In **Solution Explorer**, right-click the **References** node under the **PartsUnlimitedWebsite** project and select **Manage NuGet Packages**.
- 
+ 
1. Click the **Browse** tab and change the **Package source** to **PartsUnlimitedShared**. The only package will be the one we just added, so click **Install** to add it to the project.
- 
+ 
1. If asked, confirm the addition by clicking **OK**.
- 
+ 
1. Press **Ctrl+Shift+B** to build the project. It should succeed. The NuGet package doesn't add any value yet, but at least we know it's there.
-### Task 4: Updating a NuGet package ###
+
+### Task 4: Updating a NuGet package
1. Switch to the instance of **Visual Studio** that has the **PartsUnlimited.Shared** project open (the NuGet source project).
1. In **Solution Explorer**, right-click the **PartsUnlimited.Shared** project node and select **Add \| New Item**.
- 
+ 
1. Select the **Class** template and enter the **Name "TaxService.cs"**. Click **Add** to add the class. We can pretend that tax calculation will be consolidated into this shared class and managed centrally so that other teams can simply work with the NuGet package.
- 
+ 
1. Replace the code in the new file with the code below. For now it will just hardcode a 10% rate.
- ```c#
- namespace PartsUnlimited.Shared
- {
- public class TaxService
- {
- static public decimal CalculateTax(decimal taxable, string postalCode)
- {
- return taxable * (decimal).1;
- }
- }
- }
- ```
+ ```c#
+ namespace PartsUnlimited.Shared
+ {
+ public class TaxService
+ {
+ static public decimal CalculateTax(decimal taxable, string postalCode)
+ {
+ return taxable * (decimal).1;
+ }
+ }
+ }
+ ```
+
1. Since we're updating the assembly (and package), return to **AssemblyInfo.cs** and update the **AssemblyVersion** to **1.1.0.0**.
- 
+ 
1. Press **Ctrl+Shift+B** to build the project.
1. Return to the **PowerShell** window and execute the following line to repackage the NuGet package. Note that the new package will have the updated version number.
- ```
- ./nuget.exe pack PartsUnlimited.Shared.csproj
- ```
+ ```
+ ./nuget.exe pack PartsUnlimited.Shared.csproj
+ ```
+
1. Execute the following line to publish the updated package. Note that the version number has changed to reflect the new package.
- ```
- ./nuget.exe push -source "PartsUnlimitedShared" -ApiKey VSTS PartsUnlimited.Shared.1.1.0.nupkg
- ```
+ ```
+ ./nuget.exe push -source "PartsUnlimitedShared" -ApiKey VSTS PartsUnlimited.Shared.1.1.0.nupkg
+ ```
+
1. Return to the browser window open to Azure DevOps and refresh the page. You will still be looking at the 1.0.0 version of the package, but you can change that by selecting the **Versions** tab and selecting **1.1.0**.
- 
+ 
1. Switch back to the instance of **Visual Studio** open to the main **PartsUnlimited** project (with **PartsUnlimitedWebsite**).
1. From **Solution Explorer**, open **PartsUnlimitedWebsite\Utils\DefaultShippingTaxCalculator.cs**.
- 
+ 
1. Locate the call to **CalculateTax** around line **20** and add the qualifier **"PartsUnlimited.Shared.TaxService."** to the beginning. The original code called a method internal to this class, so the code we're adding to the beginning of the line is redirecting it to code from our NuGet assembly. However, since this project hasn't updated the NuGet package yet, it's still referencing 1.0.0.0 and doesn't have these new changes available, so the code will not build.
- 
+ 
1. In **Solution Explorer**, right-click the **References** node and select **Manage NuGet Packages**.
- 
+ 
1. NuGet is aware of our update, so click the **Updates** tab to view the details. Click **Update** to bring down the new version. If the **Updates** tab hasn't yet updated, you can still update the package from the **Browse** tab. Note that there may be many NuGet updates available, but you should only need to update **PartsUnlimited.Shared**. Note that it may take a little while for the package to become completely available for updating. If you get an error, wait a moment and try again.
- 
+ 
1. If asked, click **OK** to approve the update.
1. Press **F5** to build and run the site. It should work as expected.
-
diff --git a/labs/azuredevops/prereq/images/101.png b/labs/azuredevops/prereq/images/101.png
new file mode 100644
index 0000000000..f3170abbb1
Binary files /dev/null and b/labs/azuredevops/prereq/images/101.png differ
diff --git a/labs/azuredevops/prereq/images/102.png b/labs/azuredevops/prereq/images/102.png
new file mode 100644
index 0000000000..d1bab6deac
Binary files /dev/null and b/labs/azuredevops/prereq/images/102.png differ
diff --git a/labs/azuredevops/prereq/images/103.png b/labs/azuredevops/prereq/images/103.png
new file mode 100644
index 0000000000..8e7464af32
Binary files /dev/null and b/labs/azuredevops/prereq/images/103.png differ
diff --git a/labs/azuredevops/prereq/readme.md b/labs/azuredevops/prereq/readme.md
index 02703b7b9b..26829463db 100644
--- a/labs/azuredevops/prereq/readme.md
+++ b/labs/azuredevops/prereq/readme.md
@@ -4,38 +4,72 @@ layout: page
sidebar: vsts
permalink: /labs/azuredevops/prereq/
folder: /labs/azuredevops/prereq/
-version: Lab version - 1.38.0
-updated: Last updated - 13/11/2020
+version: Lab version - 1.39.0
+updated: Last updated - 16/01/2025
---
+
-## Overview ##
+
+## Overview
+
Certain Azure DevOps labs require a preconfigured **Parts Unlimited** team project. This document outlines the required steps to set up the required data.
-### Task 1: Configuring the Parts Unlimited team project ###
-1. Navigate to [https://azuredevopsdemogenerator.azurewebsites.net](https://azuredevopsdemogenerator.azurewebsites.net/). This utility site will automate the process of creating a new Azure DevOps project within your account that is prepopulated with content (work items, repos, etc.) required for the lab. For more information on the site, please see [https://docs.microsoft.com/en-us/azure/devops/demo-gen](https://docs.microsoft.com/en-us/azure/devops/demo-gen).
+### Task 1: Configuring the Parts Unlimited team project
+
+Keep Azure DevOps Demo Generator app ready. This app will automate the process of creating a new Azure DevOps project within your account that is prepopulated with content (work items, repos, etc.) required for the lab.For more information on the site, please see [https://docs.microsoft.com/en-us/azure/devops/demo-gen](https://docs.microsoft.com/en-us/azure/devops/demo-gen).
+
+
+
+### 1. Select the project template
+
+When you run the application you will see the information about predefined templates, choose the template by entering the corresponding number
-1. Sign in using the Microsoft account associated with your Azure DevOps subscription.
+
- 
+
-1. **Accept** the permission requests for accessing your subscription.
+### 2. Select the authentication method
-1. Select your Azure DevOps organization and enter the project name **"Parts Unlimited"**. Click **Choose Template**.
+Here you have 2 methods to authenticate Azure DevOps Demo Generator:
- 
+1. Device Login using AD authentication
-1. Select the **PartsUnlimited** template and click **Select Template**.
+ Register Your Application in Azure AD. Refer Register and Setup
- 
+ Login with the code displayed
-1. Click **Create Project** and wait for the process to complete.
+ After the login, organizations will be listed and select organization to create project
- 
+ 
+
+2. With Personal Access Token (PAT)
+
+ Create Personal Access Token with the given scopes below
+
+ | Scope | Description |
+ | -------------------------- | ------------------------------------------ |
+ | vso.agentpools | Agent Pools (read) |
+ | vso.build_execute | Build (read and execute) |
+ | vso.code_full | Code (full) |
+ | vso.dashboards_manage | Team dashboards (manage) |
+ | vso.extension_manage | Extensions (read and manage) |
+ | vso.profile | User profile (read) |
+ | vso.project_manage | Project and team (read, write and manage) |
+ | vso.release_manage | Release (read, write, execute and manage) |
+ | vso.serviceendpoint_manage | Service Endpoints (read, query and manage) |
+ | vso.test_write | Test management (read and write) |
+ | vso.variablegroups_write | Variable Groups (read, create) |
+ | vso.work_full | Work items (full) |
+
+ Enter the organization name and the Personal Access Token (PAT). Provide the project name and press enter to create a project
+
+ 
-### Task 2: Configuring the Parts Unlimited solution in Visual Studio ###
+
+### Task 2: Configuring the Parts Unlimited solution in Visual Studio
1. Some labs will require you to open the **Parts Unlimited** solution in **Visual Studio**. If your lab doesn't require this, you can skip this task.
@@ -43,21 +77,20 @@ Certain Azure DevOps labs require a preconfigured **Parts Unlimited** team proje
1. Navigate to the **Repos** hub.
- 
+ 
1. Click **Clone** and select **Clone in Visual Studio** (choose it in the dropdown if other option shown as default).
- 
- 
+ 
+ 
1. Follow the workflow to clone and configure the project in Visual Studio. Click **Clone** to copy the repo locally.
- 
+ 
1. From **Team Explorer**, double-click **PartsUnlimited.sln** from the **Solutions** section to open the solution. You can ignore if you see any warnings about unsupported project types (just click OK on the prompted window and ignore the migration report opened on the browser)
- 
+ 
- 
+ 
1. Leave Visual Studio open for use in your lab.
-
diff --git a/labs/azuredevops/sonarcloud/readme.md b/labs/azuredevops/sonarcloud/readme.md
index 8b50570f01..e1c93c82f8 100644
--- a/labs/azuredevops/sonarcloud/readme.md
+++ b/labs/azuredevops/sonarcloud/readme.md
@@ -1,179 +1,186 @@
---
-title: Managing Technical Debt with Azure DevOps and SonarCloud
+title: Managing Technical Debt with Azure DevOps and SonarQube Cloud
layout: page
sidebar: vsts
-permalink: /labs/azuredevops/sonarcloud/
+permalink: /labs/azuredevops/SonarQube cloud/
folder: /labs/azuredevops/sonarcloud/
version: Lab version - 15.8.2
updated: Last updated - 9/6/2018
---
+
-## Overview ##
+## Overview
-In this lab, you will be introduced to technical debt, how to configure your Azure Build definitions to use SonarCloud, how to understand the analysis results, and finally how to configure quality profile to control the rule set used by SonarCloud for analyzing your project.
+In this lab, you will be introduced to technical debt, how to configure your Azure Build definitions to use SonarQube Cloud, how to understand the analysis results, and finally how to configure quality profile to control the rule set used by SonarQube Cloud for analyzing your project.
Technical debt is the set of problems in a development effort that make forward progress on customer value inefficient. Technical debt saps productivity by making code hard to understand, fragile, time-consuming to change, difficult to validate, and creates unplanned work that blocks progress. Technical debt saps an org's strength due to high costs in customer support, and, eventually, some combination of these issues creates a larger problem that someone runs into. Technical debt is insidious. It starts small and grows over time through rushed changes, lack of context and lack of discipline. It can materialize out of nowhere even for a project regarded as clean at some point in time, due to a change in project circumstances: prototype code may be promoted to serve as the basis for a feature; code produced for the U.S. market may be proposed for international, instantly creating debt related to localizability; technologies evolve, but the app doesn't keep up.
-### Prerequisites ###
-- A SonarCloud account from [https://sonarcloud.io](https://sonarcloud.io/).
+### Prerequisites
+
+- A SonarQube Cloud (SaaS) account from [https://www.sonarsource.com/](https://www.sonarsource.com/).
+
+- Clone and build Azure DevOps Demo Generator
- This lab requires you to complete task 1 from the prerequisite instructions.
-## Exercise 1: Managing Technical Debt with Azure DevOps and SonarCloud ##
+
+## Exercise 1: Managing Technical Debt with Azure DevOps and SonarQube
-### Task 1: Install and configure the SonarCloud extension ###
+
+### Task 1: Install and configure the SonarQube extension
1. Navigate to your team project on Azure DevOps.
-1. SonarCloud is provided as a marketplace extension. From the **Marketplace** navigation dropdown, select **Browse Marketplace**.
+1. SonarQube is provided as a marketplace extension. From the **Marketplace** navigation dropdown, select **Browse Marketplace**.
- 
+ 
-1. Search for **"SonarCloud"**.
+1. Search for **"SonarQube Cloud"**.
- 
+ 
-1. Select the **SonarCloud** option.
+1. Select the **SonarQube Cloud** option.
- 
+ 
1. Click **Get it free**.
- 
+ 
-1. Select the organization to install **SonarCloud** into. This should be the organization that contains your **Parts Unlimited** project. Click **Install**.
+1. Select the organization to install **SonarQube Cloud** into. This should be the organization that contains your **Parts Unlimited** project. Click **Install**.
- 
+ 
1. Click **Proceed to organization**.
- 
+ 
1. Navigate to your **Parts Unlimited** team project.
-### Task 2: Integrating a build with SonarCloud ###
+
+### Task 2: Integrating a build with SonarQube Cloud
1. Navigate to **Pipelines \| Pipelines**.
- 
+ 
1. Select **New pipeline** to create a new build pipeline.
- 
+ 
1. Click **use the classic editor**.
- 
+ 
1. Accept the default options and click **Continue**.
- 
+ 
-1. Select the **.NET Desktop with SonarCloud** template and click **Apply**.
+1. Select the **.NET Desktop with SonarQube Cloud** template and click **Apply**.
- 
+ 
-1. This build definition is pretty standard for a .NET project, except that it also includes three additional tasks for **SonarCloud**. Note that you could easily integrate these specific tasks with your existing build definitions. There's no need to start from scratch like we are in this lab.
+1. This build definition is pretty standard for a .NET project, except that it also includes three additional tasks for **SonarQube Cloud**. Note that you could easily integrate these specific tasks with your existing build definitions. There's no need to start from scratch like we are in this lab.
- 
+ 
1. Set the **Agent pool** to **Hosted**. It should be the first option and have the **Visual Studio** logo.
- 
+ 
-1. Select the **Prepare analysis on SonarCloud** task. This task defines the connection configuration for any later tasks.
+1. Select the **Prepare analysis on SonarQube Cloud** task. This task defines the connection configuration for any later tasks.
- 
+ 
-1. Click **New** to configure a new **SonarCloud Service Endpoint**.
+1. Click **New** to configure a new **SonarQube Cloud Service Endpoint**.
- 
+ 
-1. Click **your SonarCloud account security page** to open the account page in a new tab.
+1. Click **your SonarQube Cloud account security page** to open the account page in a new tab.
- 
+ 
-1. Navigate to [https://sonarcloud.io](https://sonarcloud.io/) and sign in to your SonarCloud account.
+1. Navigate to [https://www.sonarsource.com](https://www.sonarsource.com) and sign in to your SonarQube Cloud account.
1. Click "My account link" and move to "Security" tab
- 
+ 
1. To generate a token, enter a name like **"azuredevops"** and click **Generate**.
- 
+ 
1. When the token is generated, click **Copy** to copy it to your clipboard. This token is tied to your account and the only thing necessary to access the service on your behalf.
- 
+ 
-1. Enter a **Service connection name** of **"SonarCloud"** and paste the token as the **SonarCloud Token**. Click **Verify and save**.
+1. Enter a **Service connection name** of **"SonarQube Cloud"** and paste the token as the **SonarQube Cloud Token**. Click **Verify and save**.
- 
+ 
-1. Select **SonarCloud** as the **SonarCloud Service Endpoint** and select an **Organization** associated with the account. You'll also need to provide a globally unique **Project Key**, such as **"partsunlimited.YOURNAME"**.
+1. Select **SonarQube Cloud** as the **SonarQube Cloud Service Endpoint** and select an **Organization** associated with the account. You'll also need to provide a globally unique **Project Key**, such as **"partsunlimited.YOURNAME"**.
- 
+ 
1. Select **Save & queue \| Save & queue** to kick off a new build.
- 
+ 
1. Click the new build link to follow its progress through to completion.
- 
+ 
-### Task 3: Reviewing SonarCloud results ###
-1. From the left panel, select the **Run Code Analysis** task. This contains the processes where SonarCloud analyzes the code.
+### Task 3: Reviewing SonarQube Cloud results
- 
+1. From the left panel, select the **Run Code Analysis** task. This contains the processes where SonarQube Cloud analyzes the code.
+
+ 
1. Near the end of the log, locate the URL to the results viewer and open it.
- 
+ 
-1. The SonarCloud results are organized for easy access to the key results you're looking for.
+1. The SonarQube Cloud results are organized for easy access to the key results you're looking for.
- 
+ 
1. Select the **Issues** tab. This provides a convenient way to filter and sort the results so that you can attack the section you feel needs immediate attention. Select the first result.
- 
+ 
1. The code view provides an in-depth review of each issue, along with suggestions and configuration options. For this issue, select **Open \| Resolve as won't fix**.
- 
+ 
1. Select the **Measures** tab. This provides a visualization of issues as selected by the available filters.
- 
+ 
1. Filter down to see the **Reliability \| Overview**. This enables you to hover over the various assets to see the amount of effort required to fix and/or maintain various components for reliability.
- 
+ 
1. Select the **Code** tab and drill into the **PartsUnlimitedWebsite** project. This provides a way to review project issues at a file level.
- 
+ 
1. Open **Bootstrapper.cs**.
- 
+ 
1. Locate the first issue related to having commented code. Expand it using the **chevron** and click the **ellipses** to see a detailed explanation and references as to the relevance and importance of this rule.
- 
-
-1. Expand the **Administration** option. Note that there is an incredible amount of flexibility available here for customizing your SonarCloud analysis.
+ 
- 
+1. Expand the **Administration** option. Note that there is an incredible amount of flexibility available here for customizing your SonarQube Cloud analysis.
+ 
diff --git a/labs/azuredevops/testmanagement/readme.md b/labs/azuredevops/testmanagement/readme.md
index c908d81c26..2037c2c208 100644
--- a/labs/azuredevops/testmanagement/readme.md
+++ b/labs/azuredevops/testmanagement/readme.md
@@ -8,213 +8,223 @@ version: Lab version - 15.8.2
updated: Last updated - 9/6/2018
redirect_from: "/labs/vsts/testmanagement/index.htm"
---
+
-## Overview ##
+## Overview
In this lab, you will learn how to use Azure DevOps to manage your project's testing lifecycle. This project will guide you through creating test plans designed to efficiently validate your software milestones. You will also create and execute manual tests that can be consistently reproduced over the course of each release.
-### Prerequisites ###
-- This lab requires you to complete tasks 1 and 2 from the prerequisite instructions.
+### Prerequisites
+
+- Clone and build Azure DevOps Demo Generator
+
+- This lab requires you to complete tasks 1 and 2 from the prerequisite instructions.
-## Exercise 1: Managing Test Plans, Suites and Cases ##
+
+## Exercise 1: Managing Test Plans, Suites and Cases
In this exercise, you will learn how to create and manage test plans, test suites and test cases.
-### Task 1: Understanding Test Plans, Suites and Cases ###
+
+### Task 1: Understanding Test Plans, Suites and Cases
1. Navigate to your team project on Azure DevOps.
1. Select **Test Plans** to navigate to the **Test Hub**. The test hub provides a central place for all test planning, execution, and analysis.
- 
+ 
1. In general, every major milestone in a project should have its own **test plan**. Within each test plan are **test suites**, which are collections of **test cases** (and optionally other test suites) designed to validate a work item, such as a feature implementation or bug fix. Each test case is designed to confirm a specific behavior and may belong to one or more test suites. The Parts Unlimited project has one test plan, which is under the **Parts Unlimited Team** and called **Parts Unlimited_TestPlan1**. Select the **Parts Unlimited_TestPlan1** test plan.
- 
+ 
1. Select the suite of tests for the story **As a customer, I would like to store my credit card details securely**. This suite of tests focuses on that work item, which happens to be a feature. Note that the work item numbers will vary every time you generate demo data for a lab.
- 
+ 
1. On the right side you can see that this test suite has three test cases designed to confirm expected behavior of the feature implementation. Double-click the **Verify that user is allowed to save his credit card detail** test case.
- 
+ 
1. This dialog provides all the info you need on this test case. Locate the **Related Work** panel and note that this test case is linked to the suite it belongs to. Click the work item to navigate to it.
- 
+ 
1. In the test suite, we can see all of the linked work items, which happen to be the test cases.
- 
+ 
1. However, it's not yet associated with the feature it's designed to test, which we can link now. Click **Add link \| Existing item**.
- 
+ 
1. Set the **Link type** to **Parent** and search for **"credit card"**.
- 
+ 
1. Select the **Feature** for **Credit Card Purchase**.
- 
+ 
1. Click **OK**.
- 
+ 
1. The parent feature is now associated with the suite that tests it and anyone can navigate between them to view their relationship relative to the other work items involved.
- 
+ 
1. Click **Save & Close**.
- 
+ 
1. Dismiss the original test case dialog.
-### Task 2: Managing Tests ###
+
+### Task 2: Managing Tests
1. Sometimes a set of test cases should be run in a specific order to maximize efficiency. Click **Order tests** to specify the order these test cases should be run.
- 
+ 
1. While these test cases could be run separately to confirm the behavior, it probably makes more sense to run the test case that rejects invalid cards first. Then, the tester can confirm that a valid card can be saved, followed by the test case for editing a saved card. Drag and drop the second test case above the first and click **Done**.
- 
+ 
1. You can now see that the **Order** has been updated and that the list is now sorted by it.
- 
+ 
1. Another significant aspect of testing has to do with the environment each test is run in. For this web app, the browser and operating system are key considerations. Right now all the tests only use one configuration: Windows 10.
- 
+ 
1. Select the **Configurations** tab.
- 
+ 
1. Note that there is one existing configuration for **Windows 10**. Each test configuration includes a name and a description, as well as a set of customizable **Configuration variables**. This project has one configuration variable set for **Operating System**. You can easily add more and/or edit the available entries for each. Click **Add configuration variable**.
- 
+ 
1. Select the **Browser** variable and set it to **Microsoft Edge**.
- 
+ 
1. Click **Save** to save the configuration.
- 
+ 
1. Now let's suppose the test team has acquired an iPhone X and wants to add it into the test matrix. It's really easy to register this environment as a new configuration so that test cases can specify it. However, before adding it, we'll need an **Operating System** option for **iOS 10**. Click the **Operating System** configuration variable.
- 
+ 
1. Click **Add new value** and add an entry for **iOS 12**.
- 
+ 
1. Click **Save**.
- 
+ 
1. Now we have everything we need to add the iPhone X. Click the **Add** dropdown and select **New test configuration**.
- 
+ 
1. Set the **Name** to **"iPhone X"**.
- 
+ 
1. Click **Add configuration variable** twice and set the **Browser** to **Safari** and **Operating System** to **iOS 12**.
- 
+ 
1. Click **Save** to save the new configuration.
- 
+ 
1. Return to the **Test Plans** tab.
- 
+ 
1. Click the dropdown next to the test suite we've been working with so far and select **Assign configurations to test suite**.
- 
+ 
1. Check the **iPhone X** option and click **Save**.
- 
+ 
1. Notice that each test case has been duplicated with an additional configuration for **iPhone X**. Now each environment can be tested and tracked separately.
- 
+ 
-### Task 3: Authoring Tests ###
+
+### Task 3: Authoring Tests
1. Expand the dropdown next to the test plan and select **New static suite.** A **static suite** of test cases is a suite where the cases have been manually assigned. You can also create suites based on common requirements (**requirement-based suite**) or a query of test cases and/or work items (**query-based suite**).
- 
+ 
1. Set the name of the new suite to **"Shipping tests"**. These tests will all focus on functionality related to shipping. Remember that you can easily share test cases across suites, so there's minimal redundancy when having a lot of overlapping suites.
- 
+ 
1. Expand the dropdown next to the newly created suite and select **New requirement-based suite**.
- 
+ 
1. You could customize the query used to specify which requirements are retrieved, but just leave the defaults and click **Run query**. Locate and select the three product backlog items related to shipping. Click **Create suites** to create a test suite for each.
- 
+ 
1. Select one of the newly created suites, such as the one associated with tracking package status.
- 
+ 
1. While you can create test cases one at a time, it's sometimes easier to use a grid layout to quickly add many test cases. In the test cases panel, select **New \| New test case using grid**.
- 
+ 
1. Enter a few test cases and click the **Save All** button. The **Title** will be the eventual title of the test case. **Step Action** will be the first (and possibly only) step of the test. If that step has an expected result, you can specify it as **Step Expected Result**.
- 
+ 
1. You can optionally continue to add and edit work items in the grid view. When satisfied, return back to the list view by clicking the **View: Grid** toggle.
- 
+ 
1. The list view shows the same data, but in a different view.
- 
+ 
1. Another option to create suites is via work item query. Expand the dropdown next to the **Shipping tests** suite and select **new query-based suite**.
- 
+ 
1. Let's say you wanted to create a test suite out of test cases related to shipping in the project. Change the **Work Item Type** to **Microsoft.TestCaseCategory** to search for test cases and click **Run query**. You now have a list of test cases that you can select to create suites from, if you choose.
- 
+ 
1. Press **Esc** to close the dialog.
-## Exercise 2: Authoring, Running and Analyzing Manual Tests ##
+
+## Exercise 2: Authoring, Running and Analyzing Manual Tests
In this exercise, you will learn how to create a manual test plan and populate it with steps. The plan can later be run to confirm the expected behavior of your software. In this lab, we're going to focus on creating a new manual test case and running it.
-### Task 1: Installing the Test & Feedback Extension ###
+
+### Task 1: Installing the Test & Feedback Extension
1. Install **Google Chrome** from [http://google.com/chrome](http://google.com/chrome). The rest of this exercise will use Chrome as its browser. If you're already using Chrome, just open a new instance for the next set of steps.
@@ -222,266 +232,265 @@ In this exercise, you will learn how to create a manual test plan and populate i
1. Select the **Azure DevOps** tab. Search for "**feedback**" and click the **Test & Feedback** extension.
- 
+ 
1. Click on **Install** button on the details page.
- 
+ 
1. Click **Install** for the Chrome extension.
- 
+ 
1. In the **Chrome Web Store**, click **Add to Chrome**.
- 
+ 
1. Confirm the installation when asked.
- 
+ 
1. To open the extension, click the extension icon that will appear on the right of the address bar. Select the **Connection Settings** tab. Enter the URL of your Azure DevOps instance, such as "**https://MYTEAM.visualstudio.com**", as the **Server URL** and click **Next**.
- 
+ 
1. The extension can be used in two modes: **Connected** and **Standalone** mode. If you have Azure DevOps or Team Foundation Server (TFS), select Connected mode. Standalone mode is for users who don't have Azure DevOps or TFS and want to use the extension to file bugs and share the report with their team.
1. After connecting to Azure DevOps, you will need to select the team you want these efforts associated with. Select the **Parts Unlimited Team** under the **Parts Unlimited** project and click **Save** to continue.
- 
+ 
-### Task 2: Authoring a Manual Test Plan ###
+
+### Task 2: Authoring a Manual Test Plan
1. In Chrome, navigate to your **Parts Unlimited** project.
1. As before, navigate to the **Test Plans** hub.
- 
+ 
1. Expand the dropdown next to the test plan and select **New static suite**.
- 
+ 
1. Name the new suite **"End-to-end tests"** and press **Enter**.
- 
+ 
1. From the **Tests** tab, select **New \| New test case** to create a new test case.
- 
+ 
1. In the **Title** box, type "**Confirm that order number appears after successful order**" as the name of the new test case.
- 
+ 
1. At this point, we're ready to add steps to this manual test. Each step includes an **Action**, which describes the action the tester needs to perform. Optionally, a step can include an **Expected Result**, which describes the expected result of the given action. In the **Steps** panel, create a step for each of the following **Actions**, only one of which has an **Expected Result**.
-
- |Action|Expected Result|
- --- | ---
- |Open project site||
- |Click Brakes||
- |Click Disk and Pad Combo||
- |Click Add to Cart||
- |Click Checkout||
- |Enter @Email, @Password||
- |Enter @Name, @Phone, @Email, @Address, @City, @State, @PostalCode, @Country, @Promo||
- |Click Submit Order||
- |Confirm order page has order #|Order # should appear on order confirmation page|
- |Log out||
- |Close browser||
+ | Action | Expected Result |
+ | ----------------------------------------------------------------------------------- | ------------------------------------------------ |
+ | Open project site | |
+ | Click Brakes | |
+ | Click Disk and Pad Combo | |
+ | Click Add to Cart | |
+ | Click Checkout | |
+ | Enter @Email, @Password | |
+ | Enter @Name, @Phone, @Email, @Address, @City, @State, @PostalCode, @Country, @Promo | |
+ | Click Submit Order | |
+ | Confirm order page has order # | Order # should appear on order confirmation page |
+ | Log out | |
+ | Close browser | |
**Note:** If you end up with an extra empty step, delete it.
-
1. At this point, the **Steps** panel should look similar to the following:
- 
+ 
1. Note the "Enter @Email, @Password" and "Enter @Name, @Phone, @Email, @Address, @City, @State, @PostalCode, @Country, @Promo" steps. In these steps, we used the **@** sign to indicate that there were iteration-specific variables to be used during the manual test pass. We can define which variables to use by scrolling down to the **Parameter Values** section of this form and entering them for each iteration. Note that you may need to use the scroll bar on the far right side of the test case dialog to view this section.
- 
+ 
1. Use the following table to set up values for two iterations.
-
- |Fields|Iteration 1|Iteration 2|
- --- | --- | ---
- |Email|admin@test.com|sachin@test.com|
- |Password|P@ssw0rd|P@ssw0rd|
- |Name|Admin User|Sachin Raj|
- |Phone|425-555-1234|555-555-5555|
- |Address|One Microsoft Way|Two Tailspin Trail|
- |City|Redmond|Springfield|
- |State|WA|IL|
- |PostalCode|98052|11135|
- |Country|USA|USA|
- |Promo|FREE|FREE|
-
+ | Fields | Iteration 1 | Iteration 2 |
+ | ---------- | ----------------- | ------------------ |
+ | Email | admin@test.com | sachin@test.com |
+ | Password | P@ssw0rd | P@ssw0rd |
+ | Name | Admin User | Sachin Raj |
+ | Phone | 425-555-1234 | 555-555-5555 |
+ | Address | One Microsoft Way | Two Tailspin Trail |
+ | City | Redmond | Springfield |
+ | State | WA | IL |
+ | PostalCode | 98052 | 11135 |
+ | Country | USA | USA |
+ | Promo | FREE | FREE |
1. The **Parameter Values** section should now look like this. Note that you can enter as many iterations as you need to fully test the breadth of the scenario.
- 
+ 
1. Click **Save & Close** to save the test case.
- 
+ 
-### Task 3: Running a Manual Test Plan ###
+
+### Task 3: Running a Manual Test Plan
1. In this task, you will learn how to run the manual test plan that we created earlier. Note that the process for triggering an automated test run follows a similar workflow. You can learn more about that in the [documentation](https://docs.microsoft.com/en-us/vsts/build-release/test/run-automated-tests-from-test-hub).
1. Right-click the test case created earlier and select **Run with options** to begin a manual test run.
- 
+ 
1. There are a few options that you can use to customize each test run. The first option is to select a **Runner**, which will be the browser in this scenario. Next, you may have the option to specify which kinds of **data to collect**. Finally, you may optionally specify which build is being tested to make it easier to associate the results with the build they were from. Click **OK** to continue.
- 
+ 
1. If the **Test Runner** window does not appear, check to see if it was blocked by the pop-up blocker. If so, click the **Pop-up blocker** button, select **Always allow pop-ups...**, and then click **Done**. You can then launch the test run again with success.
1. In the **Test Runner** window, expand the **Test 1 of 1: Iteration 1** dropdown. Note that there are two iterations: one for each set of parameters specified in the test case. In the first iteration, the [admin@test.com](mailto:admin@test.com) account is used. In the second, [sachin@test.com](mailto:sachin@test.com) will be used.
- 
+ 
1. The first step in the test is to open the project site. To do this, switch to the **Visual Studio** instance that has the **Parts Unlimited** solution loaded. From the **IIS Express** target dropdown, select **Browse With...**.
- 
+ 
1. Select **Google Chrome** and click **Browse**.
- 
+ 
1. If you're working on a large screen, it may be easier to resize the new window to fit next to the **Test Runner** window. Otherwise you can just switch back and forth.
- 
+ 
1. Once the site loads, return to the **Test Runner** and click the **Pass test step** button. As you complete the next steps of this test, be sure to check the **Pass test step** buttons for them as well.
- 
+ 
1. The next step is to click the **Brakes** menu item.
- 
+ 
1. Then click the **Disk and Pad Combo** product.
- 
+ 
1. The next step is to click **Add to cart**.
- 
+ 
1. On the next page, click **Checkout**.
- 
+ 
1. Log in using the credentials specified in the next step.
- 
+ 
1. Unfortunately, this will fail because there isn't an [admin@test.com](mailto:admin@test.com) account.
- 
+ 
1. The **Test Runner** provides three valuable ways to record media from a test run. The first option is to take screenshots. The second is to capture each user action in an image action log. The final is to record the screen as a video. Click the **Capture screenshot** button to take a screenshot.
- 
+ 
1. Crop the screen down to show the login form and error message. Specify the name **"No admin account"** and click the **Confirm** button.
- 
+ 
1. Right-click the failed step and select **Add comment**.
- 
+ 
1. Enter a comment of **"Admin account does not exist by default"** and fail the test using the **Fail test step** button.
- 
+ 
1. Click **Create bug** to log a new bug.
- 
+ 
1. Enter the bug title of **"Admin account does not exist by default"** and click **Save & Close** to log the bug.
- 
+ 
1. Since the test cannot be completed due to a bug not directly related to the functionality being tested, expand the **Mark test case result** dropdown and select **Block test**. Click **Save and close** to save the test run.
- 
+ 
1. Close the test browser windows.
-### Task 4: Analyzing Manual Test Results ###
+
+### Task 4: Analyzing Manual Test Results
1. In this task, you will learn how to review the results of a manual test run.
1. Return to the browser window hosting the **Test Hub**. Select the **Runs** tab.
- 
+ 
1. Double-click the most recent test run to open it. You may need to refresh the data to see it.
- 
+ 
1. The **Run summary** tab provides an overview of the test run, as well as high-level details on the results of all tests included as part of the run.
- 
+ 
1. Select the **Test results** tab. This tab lists the results of each individual test case included in the run along with their results. Since there was only one test case included here, double-click it to open.
- 
+ 
1. You can review all details for this particular test case run from here.
- 
+ 
1. Scroll to the bottom to locate the iterations. Expand the first iteration.
- 
+ 
1. Review the results of each step in this iteration, as well as the failed login step, which shows the screenshot attached during the test run.
- 
+ 
-### Task 5: Creating Shared Steps ###
+
+### Task 5: Creating Shared Steps
1. In this task, you will learn how to create shared steps. A shared step combines multiple steps that are commonly performed in sequence into a single logical step, which can be shared across tests. If the process defined by the shared steps ever changes in the future, you can update the shared step in one place and it will be reflected in all tests that reference it.
1. Click the test case link in the **Summary** section.
- 
+ 
1. Double-click the case to open it in the test case editor.
- 
+ 
1. Select steps 2-4 (use **Shift+Click**) and click the **Create shared steps** button.
- 
+ 
1. Set the name of these shared steps to **"Add Disk and Pad Combo to cart"** and click **Create**.
- 
+ 
1. Now you can see the previous steps replaced with the shared steps. Double-click the shared steps to open.
- 
+ 
1. If necessary, you can revisit these steps later on to update them for new requirements.
- 
+ 
1. Press **Esc** to close the **Shared Steps** dialog.
1. Click **Save & Close** to save the test case.
- 
-
+ 