github Archives

Zero Code, Zero Headache – How to do Manual Testing with Playwright MCP?

by Rutuja Raut | Oct 3, 2025 | Blog

Manual Testing with Playwright MCP – Have you ever felt that a simple manual test should be less manual?

For years, quality assurance relied on pure human effort to explore, click, and record. But what if you could perform structured manual and exploratory testing, generate detailed reports, and even create test cases—all inside your Integrated Development Environment (IDE), using zero code?

I’ll tell you this: there’s a tool that can help us perform manual testing in a much more structured and easy way inside the IDE: Playwright MCP.

Section 1: End the Manual Grind – Welcome to AI-Augmented QA

The core idea is to pair a powerful AI assistant (like GitHub Copilot) with a tool that can control a real browser (Playwright MCP). This simple setup is done in only a few minutes.

The Essential Setup for Manual Testing with Playwright MCP: Detailed Steps

For this setup, you will integrate Playwright MCP as a tool that your AI agent can call directly from VS Code.

1. Prerequisites (The Basics)

VS Code installed in your system.
Node.js (LTS version recommended) installed on your machine.

2. Installing GitHub Copilot (The AI Client)

Open Extensions: In VS Code, navigate to the Extensions view (Ctrl+Shift+X or Cmd+Shift+X).
Search and Install: Search for “GitHub Copilot” and “GitHub Copilot Chat” and install both extensions.

Authentication: Follow the prompts to sign in with your GitHub account and activate your Copilot subscription.
- GitHub Copilot is an AI-powered code assistant that acts almost like an AI pair programmer.

After successful installation and Authentication, you see something like below

3. Installing the Playwright MCP Server (The Browser Tool)

Playwright MCP (Model Context Protocol): This is the bridge that provides browser automation capabilities, enabling the AI to interact with the web page.

The most direct way to install the server and configure the agent is via the official GitHub page:
Navigate to the Source: Open your browser and search for the Playwright MCP Server official GitHub page (https://github.com/microsoft/playwright-mcp).
The One-Click Install: On the GitHub page, look for the Install Server VSCode button.

Launch VS Code: Clicking this button will prompt you to open Visual Studio Code.

Final Step: Inside VS Code, select the “Install server” option from the prompt to automatically add the MCP entry to your settings.

To verify successful installation and configuration, follow these steps:
- Click on “Configure Tool” icon

After clicking on the “configure tool “ icon, you see the tools of Playwright MCP as shown in the below image.

After clicking on the “Settings” icon, you see the “Configuration (JSON)” file of Playwright MCP, where you start, stop, and restart the server as shown in image below

{
    "servers": { 
        "playwright": { 
            "command": "npx", 
            "args": [ 
                "@playwright/mcp@latest" 
            ], 
            "type": "stdio" 
        } 
    }, 
    "inputs": [] 
}

1. Start Playwright MCP Server:

After the Playwright MCP Server is successfully configured and installed, you will see the output as shown below.

2. Stop and Restart Server

Playwright MCP Start Stop Restart Server

This complete setup allows the Playwright MCP Server to act as the bridge, providing browser automation capabilities and enabling the GitHub Copilot Agent to interact with the web page using natural language.

Section 2: Phase 1: Intelligent Exploration and Reporting

The first, most crucial step is to let the AI agent, powered by the Playwright MCP, perform the exploratory testing and generate the foundational report. This immediately reduces the tester’s documentation effort.

Instead of manually performing steps, you simply give the AI Agent your test objective in natural language.

The Exploration Workflow:

Exploration Execution: The AI uses discrete Playwright MCP tools (like browser_navigate, browser_fill, and browser_click) to perform each action in a real browser session.
Report Generation: Immediately following execution, the AI generates an Exploratory Testing Report. This report is generated on the basis of the exploration, summarizing the detailed steps taken, observations, and any issues found.

Our focus is simple: Using Playwright MCP, we reduce the repetitive tasks of a Manual Tester by automating the recording and execution of manual steps.

Execution Showcase: Exploration to Report

Input (The Prompt File for Exploration)

This prompt directs the AI to execute the manual steps and generate the initial report.

Prompt for Exploratory Testing

Exploratory Testing: (Use Playwright MCP)

Navigate to https://www.demoblaze.com/. Use Playwright MCP Compulsory for Exploring the Module <Module Name> and generate the Exploratory Testing Report in a .md file in the Manual Testing/Documentation Directory.

Output (The Generated Exploration Report)
The AI generates a structured report summarizing the execution.

Live Browser Snapshot from Playwright MCP Execution

Section 3: Phase 2: Design, Plan, Execution, Defect Tracking

Once the initial Exploration Report is generated, QA teams move to design specific, reusable assets based on these findings.

1. Test Case Design (on basis of Exploration Report)

The Exploration Report provides the evidence needed to design formal Test Cases. The report’s observations are used to create the Expected Results column in your CSV or Test Management Tool.

The focus is now on designing reusable test cases, which can be stored in a CSV format.
These manually designed test cases form the core of your execution plan.
We need to provide the Exploratory Report for References at the time of design test Cases.
Drag and drop the Exploratory Report File as context as shown in the image below.

Input (Targeted Execution Prompt)

This prompt instructs the AI to perform a single, critical verification action from your Test Case.

Role: Act as a QA Engineer. 
Based on Exploratory report Generate the Test cases in below of Format of Test Case Design Template 
======================================= 
🧪 TEST CASE DESIGN TEMPLATE For CSV File 
======================================= 
Test Case ID – Unique identifier for the test case (e.g., TC_001) 
Test Case Title / Name – Short descriptive name of what is being tested 
Preconditions / Setup – Any conditions that must be met before test execution 
Test Data – Input values or data required for the test 
Test Steps – Detailed step-by-step instructions on how to perform the test 
Expected Result – What should happen after executing the steps 
Actual Result – What happened (filled after execution) 
Status – Pass / Fail / Blocked (result of the execution) 
Priority – Importance of the test case (High / Medium / Low) 
Severity – Impact level if the test fails (Critical / Major / Minor) 
Test Type – (Optional) e.g., Functional, UI, Negative, Regression, etc. 
Execution Date – (Optional) When the test was executed 
Executed By – (Optional) Name of the tester 
Remarks / Comments – Any additional information, observations, or bugs found

Output (The Generated Test cases)

The AI generates structured test cases.

2. Test Plan Creation

The created test cases are organized into a formal Test Plan document, detailing the scope, environment, and execution schedule.

Input (Targeted Execution Prompt)

This prompt instructs the AI to perform a single, critical verification action from your Test Case. 2

Role: Act as a QA Engineer.
- Use clear, professional language. 
- Include examples where relevant. 
- Keep the structure organized for documentation. 
- Format can be plain text or Markdown. 
- Assume the project is a web application with multiple modules. 
generate Test Cases in Form Of <Module Name >.txt in Manual Testing/Documentation Directory  
Instructions for AI: 
- Generate a complete Test Plan for a software project For Our Test Cases 
- Include the following sections: 
  1. Test Plan ID 
  2. Project Name 
  3. Module/Feature Overview 
  4. Test Plan Description 
  5. Test Strategy (Manual, Automation, Tools) 
  6. Test Objectives 
  7. Test Deliverables 
  8. Testing Schedule / Milestones 
  9. Test Environment 
  10. Roles & Responsibilities 
  11. Risk & Mitigation 
  12. Entry and Exit Criteria 
  13. Test Case Design Approach 
  14. Metrics / Reporting 
  15. Approvals

Output (The Generated Test plan)

The AI generates structured test plan of designed test cases.

3. Test Cases Execution

This is where the Playwright MCP delivers the most power: executing the formal test cases designed in the previous step.

Instead of manually clicking through the steps defined in the Test Plan, the tester uses the AI agent to execute the written test case (e.g., loaded from the CSV) in the browser.
The Playwright MCP ensures the execution of those test cases is fast, documented, and accurate.
Any failures lead to immediate artifact generation (e.g., defect reports).

Input (Targeted Execution Prompt)

This prompt instructs the AI to perform a single, critical verification action from your Test Case.

Use Playwright MCP to Navigate “https://www.demoblaze.com/” and Execute Test Cases attached in context and Generate Test Execution Report.

First, Drag and drop the test case file for references as shown in the image below.

Live Browser Snapshot from Playwright MCP Execution

Output (The Generated Test Execution report)

The AI generates structured test execution report of designed test cases.

4. Defect Reporting and Tracking

If a Test Case execution fails, the tester immediately leverages the AI Agent and Playwright MCP to generate a detailed defect report, which is a key task in manual testing.

Execution Showcase: Formal Test Case Run (with Defect Reporting)

We will now execute a Test Case step, intentionally simulating a failure to demonstrate the automated defect reporting capability.

Input (Targeted Execution Prompt for Failure)

This prompt asks the AI to execute a check and explicitly requests a defect report and a screenshot if the assertion fails.

Refer to the test cases provided in the Context and Use Playwright MCP to execute the test, and if there is any defect, then generate a detailed defect Report. Additionally, I would like a screenshot of the defect for evidence.

Output (The Generated Defect report and Screenshots as Evidence)

The AI generates a structured defect report of designed test cases.

Conclusion: Your Role is Evolving, Not Ending

Manual Testing with Playwright MCP is not about replacing the manual tester; it’s about augmenting their capabilities. It enables a smooth, documented, and low-code way to perform high-quality exploratory testing with automated execution.

Focus on Logic: Spend less time on repetitive clicks and more time on complex scenario design.
Execute Instantly: Use natural language prompts to execute tests in the browser.
Generate Instant Reports: Create structured exploratory test reports from your execution sessions.
Future-Proof Your Skills: Learn to transition seamlessly to an AI-augmented testing workflow.

It’s time to move beyond the traditional—set up your Playwright MCP today and start testing with the power of an AI-pair tester!

Rutuja Raut

Automation Testing | Playwright MCP | QA & AI Integration

How to trigger a workflow from another workflow using GitHub Action

by Yogesh Dhole | Dec 6, 2023 | Blog

GitHub Actions has revolutionized the way developers and testers automate their workflows. With Actions, developers can easily define and customize their CI/CD processes, enhancing productivity and code quality. One of the powerful features of GitHub Actions is the ability to trigger workflows from another workflow GitHub Actions. In this article, we will delve into the intricacies of mastering GitHub Actions and explore how to trigger workflows from other workflows.

Understanding GitActions and their Benefits:

GitHub Actions is a powerful automation framework integrated into GitHub. It allows developers and testers to define custom workflows composed of one or more jobs, each consisting of various steps. These workflows can be triggered based on events such as push and pull requests, commits, or scheduled actions. The benefits of using GitHub Actions include faster development cycles, improved collaboration, and streamlined release processes.

Defining workflow in GitHub Actions:

Before we delve into triggering workflows, let’s define what a workflow is in GitHub Actions. A workflow is a configurable automated process that runs on GitHub repositories. It consists of one or more jobs, each defining a set of steps. These steps can perform tasks such as building, testing, and deploying code.

Overview of triggering workflows from another workflow using GitHub Action:

It is important to understand workflow dependencies to trigger a workflow from another workflow. Workflow dependencies refer to the relationships between different workflows, where one workflow triggers the execution of another workflow. By leveraging workflow dependencies, developers and testers can create a seamless and interconnected automation pipeline.

In complex development scenarios, there is often a need to trigger workflows based on the completion of other workflows. This can be particularly useful when different parts of the development process depend on each other and when different teams collaborate on a project. By triggering workflows from related workflows, developers and testers can automate the execution of dependent tasks, ensuring a smoother development workflow.

The advantages of workflow interdependency are numerous. Firstly, it allows for a modular and reusable approach to workflow automation. Instead of duplicating steps across different workflows, developers, and testers can encapsulate common operations in one workflow and trigger it from others. This promotes code reusability, reduces maintenance efforts, and enhances overall development efficiency. Moreover, workflow interdependency enables better collaboration between teams working on different aspects of a project, ensuring a seamless integration between their workflows.

GitHub Action Prerequisites:

A GitHub repository having a workflow defined in it (repository_01)
Another GitHub repository (repository_02) has a workflow defined in it that triggers after repository_01 workflow completion.
GitHub personal access token

As we have all the required stuff for our goal then let’s get it done. First will understand about GitHub personal access token.

GitHub Personal Access Token (PAT):

Personal access tokens are an alternative to using passwords to authenticate GitHub when using the GitHub API or the command line. Personal access tokens are intended to access GitHub resources on your behalf.

To learn more about GitHub personal access tokens visit the official website of GitHub https://docs.github.com/en/authentication/keeping-your-account-and-data-secure/managing-your-personal-access-tokens

How to Generate PAT?

1: First, Access your GitHub account by logging in.

2: Navigate to your profile, click on “Settings,” and proceed to “Developers.”

3: Click on Personal Access Token and then Select Token Classic.

4: Navigate to and choose “Generate new token,” then select Generate new token Classic.

5: Here, we Include a note for your Access Token (PAT) – it’s optional. Choose the expiration date for your PAT. Select the scope and at last click on generate token. Copy the token and paste it on a notepad.

(Remember the selected scope will decide the permissions and authorization to access another repository and workflow)

So now we need to add the generated PAT to our repository_01 as a secret to do this follow the below steps.

To navigate to your repository, you can click on the settings.

Then go to secrets and variables then select the Action button.

Select the repository secret, add PAT_TOKEN in the name, and paste the copied personal access token in the value. Click on Add Secret.

Workflow Creation (repository_01):

To create a workflow head over to the action tab and click on new workflow. Then select Set up workflow yourself. Now customize your workflow and add the below step to trigger the (repository_02) workflow.

name: Workflow01
on:
  push:
    branches:
      - main
jobs:
  build:
    runs-on: ubuntu-latest
    timeout-minutes: 600

    steps:
       - name: Checkout to repository
      - uses: actions/checkout@v3

      # Your existing workflow steps
      #  At the end of your all steps add the below step
          
  trigger-workflow02:
    needs: build
    runs-on: ubuntu-latest
    steps:
      - name: Trigger Workflow02
        uses: peter-evans/repository-dispatch@v2
        with:
          token: ${{ secrets.PAT_TOKEN }}
          repository: username/repository_02 name
          event-type: trigger-workflow02

Let’s understand the trigger-workflow02 stage. Following is the secret we have added is used here to provide the permissions and the authorization to understand and trigger the workflow_02 of repository_02 also replace the username with your GitHub username and repository_02 name with your other repository name.

Workflow Creation (repository_02):

As our first workflow is ready now let’s create our second workflow for repository_02. Follow the same steps described in the above step for the creation of a workflow.

name: Workflow02
on:
  repository_dispatch:
    types:
      - trigger-workflow02
jobs:
  build-and-test:
    runs-on: ubuntu-latest

    steps:
    - uses: actions/checkout@v2
   # your existing steps of workflow

Now let’s understand what to consider here, first the triggering event is set as repository_dispatch means when the other repository is completed this workflow will get triggered and now to specify which repository we arousing types as trigger-workflow02 which is defined as a stage in the workflow01.

We are done this is how we can trigger the workflow02 of repository_02 when the execution of workflow01 of repository_01 is completed and the status is passed. Below are the output screenshots give it a check.

For Organization Account:

Till this point whatever we have seen it’s for our personal GitHub account and if we want to implement this concept for the organization’s GitHub account then we need to introduce a small change in the workflow01 of the repository_01.

name: Workflow01
on:
  push:
    branches:
      - main
jobs:
  build:
    runs-on: ubuntu-latest
    timeout-minutes: 600

    steps:
       - name: Checkout to repository
      - uses: actions/checkout@v3

      # Your existing workflow steps
      #  At the end of your all steps add the below step
          
  trigger-workflow02:
    needs: build
    runs-on: ubuntu-latest
    steps:
      - name: Trigger Workflow02
        uses: peter-evans/repository-dispatch@v2
        with:
          token: ${{ secrets.PAT_TOKEN }}
          repository: organization/repository_02 name
          event-type: trigger-workflow02

Let’s understand the trigger-workflow02 stage. The secret we have added is used here to provide the permissions and authorization to trigger the workflow_02 of repository_02 also replace the organization with your organization’s GitHub name and repository_02 name with your other repository name.

Conclusion:

In this blog, we have explored the powerful feature of trigger workflow from another workflow using GitHub Actions. By understanding workflow dependencies, leveraging workflow events and triggers, implementing remote triggers, and building scalable workflow chains, developers can enhance their CI/CD processes and workflow automation. To summarize, triggering workflows from another workflow allows for increased reusability, collaboration, and customization of automation processes. By embracing these features, developers can optimize their development workflows and empower their teams to achieve greater productivity and efficiency.

Zero Code, Zero Headache – How to do Manual Testing with Playwright MCP?

Manual Testing with Playwright MCP – Have you ever felt that a simple manual test should be less manual?

Section 1: End the Manual Grind – Welcome to AI-Augmented QA

The Essential Setup for Manual Testing with Playwright MCP: Detailed Steps

1. Start Playwright MCP Server:

2. Stop and Restart Server

Section 2: Phase 1: Intelligent Exploration and Reporting

Execution Showcase: Exploration to Report

Live Browser Snapshot from Playwright MCP Execution

Section 3: Phase 2: Design, Plan, Execution, Defect Tracking

1. Test Case Design (on basis of Exploration Report)

2. Test Plan Creation

3. Test Cases Execution

Live Browser Snapshot from Playwright MCP Execution

4. Defect Reporting and Tracking

Conclusion: Your Role is Evolving, Not Ending

How to trigger a workflow from another workflow using GitHub Action

Understanding GitActions and their Benefits:

Defining workflow in GitHub Actions:

Overview of triggering workflows from another workflow using GitHub Action:

GitHub Action Prerequisites:

GitHub Personal Access Token (PAT):

How to Generate PAT?

Workflow Creation (repository_01):

Workflow Creation (repository_02):

For Organization Account:

Conclusion:

Recent Posts

Smart way of E2E testing using cypress new features cy.prompt

Boosting Web Performance: Integrating Google Lighthouse with Automation Frameworks

Top 10 tips to debug your Java code with IntelliJ

10 Prompting Secrets Every QA Should Know to Get Smarter, Faster, and Better Results

7 Common Software Testing Mistakes and How to Fix Them Using AI