Onboarding New Team to Playwright Test Automation Framework#

Introduction#

To streamline the onboarding process of product or partner teams to the Playwright Test Automation Framework, we’ve pre-onboarded a majority of the team information into the playwright-teams-info package. This package serves as a centralized repository for team-related details, including team names, emails, routing IDs, area paths, Azure DevOps (ADO) organization, and ADO project details. By utilizing this package, you can effortlessly add your team’s information, facilitating bug creation in Azure DevOps, sending email notifications, and triggering ICM alerts for the correct target team.

Pre-Onboarded Teams#

We have pre-onboarded many teams in our Playwright test infrastructure for rapid onboarding. If your team is not yet onboarded and you would like to integrate into our test framework, follow the steps below.

Steps to Add Your Team#

1. Update the Team Enum#

First, add your team to the Team enum in the teams.ts file:

export enum Team {
  // ...existing code...
  YourTeamName = "YourTeamName", // replace 'YourTeamName' with your team's name
}

2. Add Team Information#

Next, add your team’s information to the TeamInfo map:

export const TeamInfo = new Map<Team, ITeamInfo>([
  // ...existing code...
  [
    Team.YourTeamName, // replace 'YourTeamName' with your team's name
    {
      email: ["yourteamemail@microsoft.com"], // replace with your team's email
      routingId: "", // replace with your team's routing ID
      areaPath: "", // replace with your team's area path
      adoOrg: "", // replace with your team's Azure DevOps organization
      adoProject: "", // replace with your team's Azure DevOps project
    },
  ],
]);

3. Generate a Change File#

After making the changes, run the rush change command to generate a change file that documents your additions:

rush change

Follow the prompts to provide:

  • A description of your changes

  • The type of change (patch, minor, or major)

4. Submit Your PR#

Create a pull request with your changes to the PowerApps-Engineering repository, including:

  • Your updates to teams.ts

  • The generated change file

  • A clear PR description explaining the team being added

Teams.ts File Structure#

Interface: ITeamInfo#

The ITeamInfo interface defines the structure of team information:

export interface ITeamInfo {
  email: string[]; // Array of team email addresses
  routingId: string; // ICM routing ID for the team
  areaPath?: string; // ADO area path (optional)
  iterationPath?: string; // ADO iteration path (optional)
  adoOrg?: AdoOrg; // ADO organization (optional)
  adoProject?: AdoProject; // ADO project (optional)
}

Note: adoOrg and adoProject are optional parameters. If your team does not use Azure DevOps, you can leave these fields undefined.

Using Team Information in Tests#

Once your team is added, you can specify it as the owner of tests using the integrationTest wrapper:

integrationTest(
  {
    envTypes: [EnvironmentType.MakerShell],
    runTypes: [RunType.Runner],
    runEnvironments: [[RunEnvironment.Test, Severity.S3]],
    runGeos: [RunGeo.USA],
  },
  Team.YourTeamName, // Your team as the owner
  "Test Title",
  async ({ page }) => {
    // Test implementation
  }
);

Test Reporting Configuration#

When configuring your build pipeline, you can enable automated bug creation and ICM alerts by setting:

  • createBugForFailures: true - Creates bugs in Azure DevOps for failing tests

  • pushFailuresToTelemetry: true - Creates ICM incidents for failing tests

Severity for ICM Incidents#

You can specify ICM severity levels in the test configuration:

integrationTest(
  {
    // ...other config...
    runEnvironments: [
      [RunEnvironment.Prod, Severity.S2], // Production = S2
      [RunEnvironment.Test, Severity.S3], // Test = S3
    ],
  }
  // ...rest of your test code
);

Note: Tests running in production environments are automatically set to S2 severity, while tests in preview environments use S3 severity.

Bug Severity and Priority#

Bug severity and priority are not assigned automatically by the system. These values need to be determined by your team during the bug triage process based on impact and urgency.

Additional Resources#