Our Impact on Business

What is Serenity Screenplay?   Screenplay is a test automation design pattern used to write readable, maintainable tests; it is part of Serenity BDD. Screenplay uses a model based on the Actors. Every Screenplay test has at least one actor (you can also have multiple actors). You can model scenarios involving multiple users, each with specific Abilities and Interactions. Besides Actors, other important components of Screenplay are Tasks, Interactions, Questions, and Abilities. Tasks and Actions are reusable across different test scenarios, helping minimize code duplication.   To use Screenplay, you will have to add these dependencies into pom.xml file:   <dependency>    <groupId>net.serenity-bdd</groupId>    <artifactId>serenity-screenplay</artifactId>    <version>4.2.34</version>         </dependency> <dependency>    <groupId>net.serenity-bdd</groupId>    <artifactId>serenity-screenplay-webdriver</artifactId>    <version>4.2.34</version> </dependency> Actors An actor represents a user who interacts with the application. Actors have abilities, such as the ability to interact with a web browser. They also perform tasks, interactions, and answer questions to check whether the feature behaves as we expect.   This is how we define an actor and give the actor the ability to interact with a web browser using Selenium WebDriver: final Actor actor = new Actor(“User”).can(BrowseTheWeb.with(getDriver()));   When writing code with Selenium, it can get a little messy; with a lot of code, it can become hard to read or maintain. For example, it can take a lot of time to figure out the best way to interact with a specific button on a page. With Screenplay, we use actors to perform interaction: Selenium example: getDriver().get(“https://testingpage.com/login”); final WebElement username = getDriver().findElement(By.id(“username”)); username.sendKeys(“John-Doe”); final WebElement password = getDriver().findElement(By.id(“password”)); password.sendKeys(“pass123”); final WebElement loginButton = getDriver().findElement(By.id(“login”)); loginButton.click();   In this example, we can see: Selenium focuses on how you find an element and click on it or type into the field. Code repeats. Screenplay example:   actor.attemptsTo(  Open.url(“https://testingpage.com/login”),        SendKeys.of(“John-Doe”).into(By.id(“username”)),        SendKeys.of(“pass123”).into(By.id(“password”)),        Click.on(Button.withText(“Login”)) ); OR You can create a separate CommonFields class where you will store common fields: public static final Target USERNAME = Target.the(“Username field”).located(By.id(“username”)); public static final Target PASSWORD = Target.the(“Password field”).located(By.id(“password”)); public static final Target LOGIN_BUTTON = Target.the(“Login button”).located(By.id(“login”));   And then use it in a test:   actor.attemptsTo(        Open.url(“https://examplepage.com/login”),        SendKeys.of(“John-Doe”).into(CommonFields.USERNAME),        SendKeys.of(“pass123”).into(CommonFields.PASSWORD),        Click.on(CommonFields.LOGIN_BUTTON) ); In this example, an actor performs a sequence of actions, which describes what the user does, not how it is done. It is readable, reusable, and maintainable. If an element changes, you only need to update it in one place. Tasks A task is a high-level action that an actor performs. It consists of smaller interactions like clicking, typing, etc. We can additionally create a task for login: public class LoginTask implements Task {    private final String username;    private final String password;   public LoginTask(final String username, final String password) {        this.username = username;        this.password = password;    }  public static LoginTask usingData(final String username, final String password) {        return new LoginTask(username, password);    }   @Override   public <T extends Actor> void performAs(T actor) {        actor.attemptsTo(                SendKeys.of(username).into(CommonFields.USERNAME),                SendKeys.of(password).into(CommonFields.PASSWORD),                Click.on(CommonFields.LOGIN_BUTTON)        );    } } And then use it in test:   actor.attemptsTo(        Open.url(“https://examplepage.com/login”),        LoginTask.usingData(“John-Doe”, “pass123”) );     In previous examples, we saw how to click on some element or type into the field. Next, we will see more basic interactions: Move mouse Move the mouse on a specific element (for example, you can use it to trigger a tooltip): actor.attemptsTo(MoveMouse.to(CommonFields.LOGIN_BUTTON)); Double click actor.attemptsTo(DoubleClick.on(target)); Right click actor.attemptsTo(RightClick.on(target)); Enter value This will enter a value into a field, first it will wait until the field is enabled, and then clear the field of any current values, before entering the specified value: actor.attemptsTo(Enter.theValue(“John-Doe”).into(CommonFields.USERNAME)); Upload file Files can be placed in a hard-coded location or stored on the classpath, which is a better solution:   actor.attemptsTo(Upload.theFile(Path.of(“test/data/api/files/” + fileName +”.extension”)).to(uploadField)); Questions When an actor wants to get a specific piece of information from the system, it can be done using a Question. Questions are queries about the application’s state. Actors ask questions using the method askFor().   Some of the common Question classes are: Text.of()   final String text = actor.asksFor(Text.of(TARGET_ELEMENT));   This will extract the text of a target element and return the value that you can use for assertion.   When working with table, we can extract data from cells:   final List<String> tableHeaders = actor.asksFor(Text.ofEach(HEADERS)); final List<List<String>> tableRows = actor.asksFor(Text.ofEach(ROWS)); isVisible() boolean isVisible = actor.asksFor(Visibility.of(TARGET_ELEMENT));   This checks whether a UI element is displayed. isDisabled() boolean isDisabled = actor.asksFor(Disabled.of(TARGET_ELEMENT));   This will check whether an element is disabled. Presence.of() boolean isPresent = actor.asksFor(Presence.of(TARGET_ELEMENT)); This checks whether the element is present in the DOM. Conclusion With Serenity Screenplay, you can write clean and maintainable automation tests using Actors, Abilities, Tasks, and Questions. Instead of just writing a bunch of code with Screenplay, your automation code will be easy to read and understand for both QA and developers. It is also important to know that Screenplay doesn’t replace Selenium; they work together. Selenium is the engine that communicates with the browser, and Screenplay is the pattern that makes your tests feel like a story.

In recent years, automation testing has undergone a major transformation from scripting repetitive steps to building intelligent, self-adaptive test systems. One of the most exciting innovations leading to this change is Playwright MCP (Model Context Protocol). MCP acts as a bridge between AI assistants (such as Anthropic’s Claude and GitHub Copilot) and browser automation tools like Playwright. This integration allows developers and QA engineers to generate, run, and refine test scripts through natural language right inside their development environment. Imagine simply typing: “Create a test that logs into our staging site and verifies the dashboard loads correctly,” and seeing a full Playwright test generated and executed in seconds. That’s the core idea behind Playwright MCP.   What Is a Playwright MCP? MCP stands for Model Context Protocol (in the broader AI world) or Multi-Client Protocol in the Playwright integration. In practice, it combines ideas from both, allowing context to be exchanged between AI agents (or scripts) and the browser automation engine.  In essence, Playwright becomes an MCP client that connects to a MCP server. The server acts as a mediator: it exposes tools, data, or services (e.g., prompts, API calls, functions) to the client, and translates commands into browser actions.  Rather than simply driving a browser with static scripts, the AI or agent side can query context (“what elements are present?”, “what is the current DOM tree state?”), generate next steps, and adapt dynamically. Setup & Configuration in VS Code Setting up Playwright MCP varies depending on your preferred development environment.  VS Code integration has received significant attention and appears to be the most stable option for many users. Prerequisites Node.js (v18+), since Playwright and MCP Server run in Node.  Playwright installed (with support for Chromium, Firefox, WebKit) VS Code or VS Code Insiders Edition GitHub Copilot subscription (for the agent functionality) Installation: 1. Install VS Code Insiders (recommended for the latest MCP features): Download from the official VS Code Insiders page, as some MCP features require the latest builds. 2. Add MCP Server via Command Line: # For VS Code Stable code –add-mcp ‘{“name”:”playwright”,”command”:”npx”,”args”:[“@playwright/mcp@latest”]}’ # For VS Code Insiders code-insiders –add-mcp ‘{“name”:”playwright”,”command”:”npx”,”args”:[“@playwright/mcp@latest”]}’ 3. Manual Configuration (Alternative for step 2) Edit your VS Code settings.json file { “mcp”: { “servers”: { “playwright”: { “command”: “npx”, “args”: [“@playwright/mcp@latest”] } } } } 4. Enable GitHub Copilot Agent Mode Open the Copilot chat Select “Agent” mode instead of “Chat” Choose Claude Sonnet as your model if available 5. Test MCP server Test the MCP server with the command: “Use Microsoft Playwright to navigate to www.example.com and take a screenshot.”   Example: Create a simple test using MCP Once configured, you can open your chat assistant inside VS Code and type something like: Prompt: “Run a test that opens the Example.com page, checks the page title, and takes a screenshot of the homepage.” The MCP will generate a Playwright test dynamically: import { test, expect } from ‘@playwright/test’; test(‘Example page title validation’, async ({ page }) => { await page.goto(‘https://example.com’); await expect(page).toHaveTitle(/Example/); await page.screenshot({ path: ‘homepage.png’ }); }); Conclusion Playwright MCP represents the next step in automation evolution, merging AI reasoning with browser control to accelerate quality assurance. By integrating it into VS Code, QA engineers gain a seamless workflow where natural language drives real automation. Whether for debugging, creating new test scenarios, or maintaining large test suites. “Playwright MCP Explained: A Hands-on Guide for Test Automation” Tech Bite was brought to you by Nermin Maslo, Quality Assurance Engineer at Atlantbh. Tech Bites are tips, tricks, snippets or explanations about various programming technologies and paradigms, which can help engineers with their everyday job.  

MCP stands for Model Context Protocol and provides a standardized way to integrate AI applications using LLMs such as OpenAI GPT, Anthropic Claude, Google Gemini, and other custom/self-hosted models into larger systems. MCP servers adhere to a client-server architecture and allow us to precisely define which parts of the system AI can interact with and how, through a client such as Claude Code. Here, we refer to Claude Code as an application that serves as a client. Another example would be Microsoft Copilot. This improves the control over the LLM’s actions towards our system, thus improving security. By utilising an MCP server, run either locally using STDIO or remotely via HTTP, LLMs can access the following in a standardized way: data sources such as API responses and files development tools, such as functions from an API library workflows such as Slack workflows For example, assume functions for fetching data from a database and reporting were written in an API library, along with some other functions. MCP client, in this case Claude, initiates a connection to the MCP server and starts it locally, as instructed in Claude’s configuration file. Functions for fetching data from the database and functions for reporting have special annotation on them, allowing these functions from the API library to be registered on the server as MCP tools. Claude then receives a list of all available MCP tools. Let’s say we want to query the database to retrieve some company data at this point. The MCP server allows us to prompt Claude to query the database for us. LLM autonomously chooses an appropriate MCP tool and forwards a request to it. So the function from the API library is then executed. Once the MCP server receives a response from the API library, LLM processes it and presents it to the user via Claude interface. The steps above describe a local MCP server using STDIO as the means of data transport. If it were a remote MCP server, the only difference would be the fact that the MCP client would connect to an already up-and-running, remote MCP server and use HTTP to transport data. The bidirectional flow of data, as described, is illustrated in Figure 1 below, emphasising that AI applications powered by an LLM, such as Claude Code, never directly communicate with the inner workings and code of the tools. LLM only has access to the prompts, signatures of the registered development tools, requests, and responses, as opposed to having access to potentially sensitive code of the API library. MCP communication between client and server is built on top of JSON RPC, a long-established protocol for structured, remote method calls. This means that everything exchanged in this client-server architecture, ranging from tool discovery and execution to responses, travels as JSON RPC requests or responses. This protocol is precisely what allows the server and the client to be created in their own independent programming languages. A JSON RPC request contains the ID of the request that relates the requests and responses, the method that should be called, such as tools/list, and the parameters for this method as extracted from the prompt. A JSON RPC response similarly contains the ID and the result of the method execution. Detailed steps in Figure 1 explain this data flow in a simplified manner. Figure 1: MCP Data Flow Connection & Setup MCP client initiates a connection to the MCP server and starts it either locally or remotely Tool Registration MCP server requests a list of annotated MCP tools from the API library MCP server retrieves a list of annotated MCP tools from the API library MCP client requests a list of registered MCP tools from the MCP server MCP client receives a list of annotated MCP tools from the API library  LLM Processing 1 MCP client sends the prompt and context (such as method signatures, parameter types, etc.) of all MCP tools. Example prompt: “Generate today’s sales report based on the current sales summary, save it as a report, and then confirm that the file was created successfully.” LLM autonomously picks the right tool(s) and firstly calls get_sales_summary(). Tool Execution MCP client forwards a request to get_sales_summary() MCP tool. MCP server forwards the request to get_sales_summary() function from the API library, and the code is executed. The API library returns the response to the MCP server, such as {“date”:”2025-11-19″,”total_sales”:19954,”region”:”Global”,”top_product”:”AI Chat Subscription”,”growth_pct”:5}  LLM Processing 2 The response is forwarded to the MCP client. MCP client allows the LLM to process the response and formulate what the end user will receive The end user receives the result: “Now I’ll create and submit the sales report.” The steps 7 – 13 starting from the first LLM processing are repeated until the tasks from the original prompt are exhausted, with the final result being: ✅ Report created successfully! The daily sales report for November 19, 2025, has been generated and saved to: /Users/hanapotogija/Desktop/MCP Server/reports/20251119_143613_Daily_Sales_Report_-_November_19,_2025.json Report Summary: Total Sales: $19,954 Growth Rate: 5.5% Top Product: AI Chat Subscription Status: Successfully saved The comprehensive report includes an executive summary, key metrics, performance analysis, market insights, strategic recommendations, and conclusions based on today’s sales performance. Figure 2 shows how the previously described MCP interactions look in Claude. Figure 2: Using MCP server through Claude MCP Benefits To reiterate, MCP provides a standardized way for LLM models to be integrated with existing data, tools, APIs, services, workflows, and so forth, so that no team or individual has to figure out how to use these LLM tools on their own. At its core, MCP is about controlling how much access AI has to the system so that LLMs can operate only on what’s been explicitly exposed to them, protecting the system from unauthorized access. Furthermore, the MCP server poses as an intermediary between the system and the AI, fostering the separation of concerns and ease of integrating diverse tooling. The choice of programming language in which the MCP server is created is not relevant, as long as the protocol defined in the previous section is followed. Similarly, the choice of LLM model is also not relevant, as there are no restrictions on it by the MCP. By providing standardized inputs and outputs, the reliability of these AI workflows is enhanced, making them suitable for AI-driven development environments, automated data pipelines, and workflow orchestration, as MCP tools can be chained easily, independently, and reliably. So, how is using an MCP server to fetch data from a database different from calling the function for querying the database ourselves?  For example, previously, the person needed to know the database schema and SQL to query data. Now, MCP servers open the door for non-technical people to accomplish similar tasks in a human-readable prompt format. Perhaps we need a series of queries, perhaps we want to execute some user flow, or something else entirely. Using MCP servers gives us the flexibility to call exposed development tools in any order we want, without worrying about the underlying code or different APIs. Thus, a solution like this cannot be easily replaced by writing predefined scripts that can be given to stakeholders, management, and the development team. Non-technical stakeholders aren’t the only ones benefiting from using MCP servers. As a quality assurance engineer, I see many benefits to using an MCP server. This includes fast data seeding for complex systems with multiple services, fast bug reporting, and aids testing by completing time-consuming steps without having to write elaborate automation scripts, and more. Implementation Now that you see value in creating your own MCP server, this section will walk you through implementing a simple example MCP server connected to Claude on your own. Figures 1 and 2 in the previous sections showcase this implementation. Dependencies The created MCP server is local, using STDIO transport of data. The chosen programming language is Python, using the FastMCP library. An important prerequisite before trying it out yourself is that the FastMCP library requires a minimum Python version 3.10.x. This guide assumes you are familiar with AI applications powered by LLMs such as ChatGPT, Claude Code, or others. You should have the latest version of the Claude desktop installed. Paste the following line of code in the terminal to install FastMCP, making this the only library dependency outside the standard Python for the implementation. Furthermore, your Python interpreter might be named differently from python3.10. python3.10 -m pip install fastmcp The implementation of this particular MCP server assumes that we have an API library that can fetch data about a company, customers, and sales. We want to expose functions from that API library to the MCP server connected to Claude so that we don’t have to execute them from this API ourselves. API Library First, let us create a simple API library. Create a directory and call it api. Inside the api directory, create an empty __init__.py file, marking this directory as a python package. Here, we will create a pool of functions, from which we want to expose some of those functions to the MCP server. Paste the following code into a new file called data_api.py. import random from datetime import date def get_sales_summary(): “””Simulate fetching aggregated sales data.””” return { “date”: str(date.today()), “total_sales”: random.randint(5000, 25000), “region”: “Global”, “top_product”: “AI Chat Subscription”, “growth_pct”: round(random.uniform(3.5, 12.7), 2), } def get_customer_info(customer_id: int): “””Simulate fetching a single customer’s data.””” customers = { 1: {“name”: “Alice”, “region”: “Europe”, “purchases”: 12}, 2: {“name”: “Bob”, “region”: “North America”, “purchases”: 7}, 3: {“name”: “Carla”, “region”: “Asia”, “purchases”: 15}, } return customers.get(customer_id, {“error”: “Customer not found”}) def list_customers(): “””Simulate fetching a list of all customers.””” return [ {“id”: 1, “name”: “Alice”, “region”: “Europe”}, {“id”: 2, “name”: “Bob”, “region”: “North America”}, {“id”: 3, “name”: “Carla”, “region”: “Asia”}, ] In addition to reading information about the company, we may want to report data from our company elsewhere. Assume this comes from a different API. Create a new file in the api directory called report_api.py. Paste the following code in this file. from datetime import datetime import json import os BASE_DIR = os.path.dirname(os.path.abspath(__file__)) PROJECT_ROOT = os.path.dirname(BASE_DIR) REPORTS_DIR = os.path.join(PROJECT_ROOT, “reports”) os.makedirs(REPORTS_DIR, exist_ok=True) def post_report(title: str, content: str): “””Simulate saving a report to disk inside /reports directory.””” timestamp = datetime.now().strftime(“%Y%m%d_%H%M%S”) safe_title = title.replace(” “, “_”) filename = f”{timestamp}_{safe_title}.json” path = os.path.join(REPORTS_DIR, filename) report_data = { “title”: title, “content”: content, “timestamp”: timestamp } with open(path, “w”, encoding=”utf-8″) as f: json.dump(report_data, f, indent=2) return {“status”: “success”, “path”: path} The pasted code simulates submitting a report by writing the report title, content, and timestamp to an automatically created reports directory inside the root directory of your project. Right here with your code and inside reports directory, you can find your saved reports. Now that the API library is created, we are done with one component described in Figure 2. MCP Server Now it’s time to create the actual MCP server. Create a new file in the main directory and name it server.py. Let us first handle imports and logging. Imports handle dynamic file paths, the FastMCP library, which enables us to build this server easily, and our API libraries. Similarly to submitting reports, storing the server’s logs works by writing to a local file during MCP tool execution. The logs directory is automatically created in the root directory, and you can find the logs of your executions in the   mock_company_server.log file. import logging import sys import os from fastmcp import FastMCP from api import data_api, report_api PROJECT_ROOT = os.path.dirname(os.path.abspath(__file__)) LOG_DIR = os.path.join(PROJECT_ROOT, “logs”) os.makedirs(LOG_DIR, exist_ok=True) LOG_FILE = os.path.join(LOG_DIR, “mock_company_server.log”) logging.basicConfig( level=logging.INFO, format=”%(asctime)s [%(levelname)s] %(message)s”, handlers=[ logging.FileHandler(LOG_FILE), logging.StreamHandler(sys.stderr) ] ) Now, we instantiate the MCP server via the FastMCP class and give it a name. mcp = FastMCP(“MockCompanyDataServer”) At this point, we have sufficient data to register MCP tools. We are going to achieve this by encapsulating functions from previously created API libraries as MCP tools, marked by the @mcp.tool() annotation. Below the MCP server instance, paste the code for the MCP tools: @mcp.tool() def get_sales_summary() -> dict: “””Fetch the latest sales summary from the database.””” logging.info(“Tool: get_sales_summary called”) return data_api.get_sales_summary() @mcp.tool() def get_customer_info(customer_id: int) -> dict: “””Retrieve information for a specific customer.””” logging.info(f”Tool: get_customer_info({customer_id})”) return data_api.get_customer_info(customer_id) @mcp.tool() def list_customers() -> list: “””List all customers in the database.””” logging.info(“Tool: list_customers called”) return data_api.list_customers() @mcp.tool() def post_report(title: str, content: str) -> dict: “””Submit a report based on fetched data.””” logging.info(f”Tool: post_report({title})”) return report_api.post_report(title, content) Every time an MCP tool is called, the previously configured logging is used, where simple data about the tool call is written to the  mock_company_server.log file, and the MCP tool post_report works in a similar fashion. Finally, in order to start the server, paste the following line of code: # ===== Start the MCP Server ===== if __name__ == “__main__”: logging.info(“Starting MockCompanyDataServer Locally”) mcp.run(transport=”stdio”) Configure with Claude Finally, it’s time to configure the MCP server with Claude. Go to Claude settings > Developer tab. Click on Edit config, which will point to claude_desktop_config.json file. This file might be empty at first, but to configure the MCP server to be discoverable to Claude, paste the following: { “preferences”: { “menuBarEnabled”: false }, “mcpServers”: { “mock_company_data”: { “command”: “<system python filepath>”, “args”: [“<project_root>/server.py”], “env”: { “PYTHONPATH”: “<system filepath to this repository>” } } } } Make sure to replace <system python filepath>, <system filepath to the server from this repository>, and <system filepath to this repository> with proper file paths on your machine. Command assumes you will use the system-level Python, args is the file path to the server.py file you created, and PYTHONPATH assumes the file path to the top-level directory that contains both the server and the API library. If you want to try out this MCP server without building it yourself step by step, feel free to check out the GitHub implementation. You may clone the repository and check out README.md for a detailed guide on how to set up this ready-made MCP server on your machine from scratch! Complete code available on GitHub: https://github.com/ATLANTBH/mcp-server-demo.git If you found this useful, check out other Atlantbh blogs!