@lukke Yes, generally the point of an automated e2e tests in a pipeline is so that you can test your site after it changes. The author is trying to describe replacing your manually executed tests with test automation that use Playwright as an alternative to Selenium for browser automation, and then the mechanics of how to integrate these tests into an Azure DevOps pipeline.
I think what you're interested is what comes next -- how can I convert my test automation into a fully automated system that tests the site whenever the site changes? There are several different approaches for this, but having the pipeline is the first step into replacing hand-executed tests with automation.
The most common answer is that most teams just execute the pipeline manually, as needed. There can be many different factors that influence the timing. For example, an enterprise application composed of multiple services with independent pipelines or other manual activities such as a data-refresh, might not be able to reliably predict when the test-automation pipeline should be automatically executed.
However, in a simplistic scenario you could execute the test-automation using one of these sample approaches:
- integrate the pipeline tasks mentioned in this article as part of the application deployment pipeline, so that the tests are part of the deployment; or
- have the application deployment pipeline trigger the test-automation-pipeline at the end of the deployment activities (using Azure DevOps REST API, or custom task) -- this decouples the deployment from the testing such that failing tests aren't considered a failed deployment; or
- configure the application-deployment-pipeline as a "resource" to the test-automation-pipeline and automatically trigger the test-automation-pipeline when the application-deployment-pipeline completes.