# T.J. Maher Stories for Software QA Engineers shifting from manual to automated testing. This is one page of public article previews, not the complete archive. Follow Next page to continue. Summaries are not the original full articles. ## The thoroughness of Tom Johnson's free Documenting API's course on OpenAPI 3.0 and Swagger UI DevFeed: [The thoroughness of Tom Johnson's free Documenting API's course on OpenAPI 3.0 and Swagger UI]() Original publisher: [Read original article]() Author: T.J. Maher (noreply@blogger.com) Published: 2026-09-09T21:17:32Z Content type: article Language: en Sources: [T.J. Maher]() Topics: [OpenAPI Specification](), [Documentation](), [REST API](), [Swagger](), [Testing](), [Postman](), [JavaScript](), [JSON](), [Authentication](), [cURL](), [Chrome](), [Open Source]() Tags: [api](), [api-documentation](), [authentication](), [chrome](), [chrome-extension](), [curl](), [documentation](), [github](), [javascript](), [json](), [openapi](), [pdf](), [postman](), [rest-api](), [swagger](), [testing]() ### AI overview The article reviews Tom Johnson's free "Documenting APIs: A guide for technical writers and engineers" course. It describes the course's 17 chapters, practical API-learning exercises, coverage of REST APIs, OpenAPI, Swagger UI, testing and publishing API documentation, and a PDF edition exceeding 900 pages. ### Source excerpt While researching information for my job about the Swagger UI and how it can be used for testing, I came across this free course, called Documenting APIs: A guide for technical writers and engineers at https://idratherbewriting.com/learnapidoc/docapis_overview.html written by Tom Johnson, a technical writer based in Seattle who works for Google. The course looks intense, containing 17 chapters talking about Introduction to REST APIs, using APIs like a developer, Documenting API endpoints, the Open API spec, Testing API docs, Publishing API docs, and more. From the Course Introduction: "You'll first learn about API documentation by using a simple weather API to put a weather forecast on your site. [...] As you use the API, you'll learn about endpoints, parameters, data types, authentication, curl, JSON, the command line, Chrome's Developer Console, JavaScript, and more. The idea is that rather than learning about these concepts independent of any context, you learn them by immersing yourself in a real scenario while using an API. Immersion in real scenarios makes these tools and technologies more meaningful. "We'll then transition into standards, tools, and specifications for REST APIs. You'll learn about the required sections in API documentation, analyze examples of REST API documentation from various companies, learn how to join an open-source project to get experience, and more. "[...] We'll also dive into specifications such as the OpenAPI specification and Swagger UI (which provides tooling for the OpenAPI specification). Additionally, you'll learn how to document native library APIs and generate Javadoc". Tom Johnson offers a PDF version of this free course... over 900 pages, with more always being added. It also offers many workshop-like activities you could put in an actual itinerary. You would need for the course: Chrome, since it provides "a Javascript Console that works well for inspecting JSON", the JSON Formatter Chrome extension, Postman, a GitHub acco ## Testing the Swagger Petstore: Manually Testing An API Using Swagger UI DevFeed: [Testing the Swagger Petstore: Manually Testing An API Using Swagger UI]() Original publisher: [Read original article]() Author: T.J. Maher (noreply@blogger.com) Published: 2026-09-07T16:43:41Z Content type: tutorial Language: en Sources: [T.J. Maher]() Topics: [Swagger](), [Testing](), [API](), [OpenAPI Specification]() Tags: [api](), [auth](), [authentication](), [authorization](), [http](), [openapi](), [payload](), [schema](), [swagger](), [testing](), [ui]() ### AI overview A practical guide to manually testing the Swagger Petstore API through Swagger UI. It covers happy-path, negative, boundary and edge-case, authentication and authorization, and contract and schema validation tests using the browser-based "Try it out" feature. ### Source excerpt With the last post, Testing the Swagger Petstore: Reviewing API Documentation Formatted in OpenAPI 3.0 with Swagger UI we started exploring an API with Swagger UI, such as the Swagger Petstore at https://petstore3.swagger.io/ Here, we will start exploring how to test an API using the Swagger UI. The tests we can run are: Happy Path Testing, checking the Positive Scenarios Negative Testing, reviewing the Invalid Inputs & Error Handling Boundary & Edge Case Testing, checking how the API handles the extreme limits of allowed input ranges Authentication & Authorization Testing Contract and schema validation We can see in the Swagger PetStore there are three tag groups: Pet, Store, and User. Because this is a Swagger UI doc, we can perform manual testing using only the "Try it out" feature in Swagger UI. No external tools needed! Live HTTP requests can be executed directly from your browser. Types of Testing for the API Here are a few types of testing and examples you can do in Swagger UI Happy path Functional Testing Pet POST /pet: add a new pet with a complete, valid payload. Verify 200 and that the response echoes the submitted fields. PUT /pet: update the pet you just created. Verify the change persists on a follow-up GET. GET /pet/{petId}: retrieve the pet by the ID returned from the POST. GET /pet/findByStatus: query with each valid status value (available, pending, sold) individually. GET /pet/findByTags: query with a tag that exists on a pet you created. POST /pet/{petId} (form data): update name/status via form fields instead of JSON body. POST /pet/{petId}/uploadImage: upload a valid image file, verify response message and metadata. DELETE /pet/{petId}: delete a pet you created, then confirm GET on that ID now fails. Store POST /store/order: place an order with valid petId, quantity, shipDate, status. GET /store/order/{orderId}: retrieve the order just placed. GET /store/inventory: verify it returns a status-to-count map without needing auth. DELETE /store/orde ## Testing the Swagger Petstore: Reviewing API Documentation Formatted in OpenAPI 3.0 with Swagger UI DevFeed: [Testing the Swagger Petstore: Reviewing API Documentation Formatted in OpenAPI 3.0 with Swagger UI]() Original publisher: [Read original article]() Author: T.J. Maher (noreply@blogger.com) Published: 2026-09-05T03:09:27Z Content type: article Language: en Sources: [T.J. Maher]() Topics: [OpenAPI Specification](), [Swagger](), [API](), [Documentation](), [Testing]() Tags: [api](), [api-documentation](), [openapi](), [swagger](), [testing]() ### AI overview This article reviews the Swagger Petstore test site and its API documentation formatted with OpenAPI 3.0 and Swagger UI. It also provides background on Swagger's origins, its acquisition by SmartBear, and the distinction between the OpenAPI Specification and SmartBear's Swagger toolset. ### Source excerpt For this next project, we will be examining the test site Swagger Petstore - OpenAPI 3.0 at https://petstore3.swagger.io/ https://petstore3.swagger.io/ If we wanted to really dive deep into creating API documentation, we could use: I'dRatherBeWriting's Free Documenting APIs course, showing an Introduction to REST APIs, using APIs like a developer, Documenting API endpoints, the Open API spec, Testing API docs, Publishing API docs, and more... ... But that goes too deep for this blog post. Before we begin, let's get into some background information. What is Swagger? According to OpenAPISpec.com's article, Who Created Swagger?, Swagger was created in 2010 by Tony Tam, the CTO of Wordnik, an online dictionary company that leveraged so many APIs, it was difficult for the six person engineering team to manage and scale them, writing API-clients and documentation by hand. After a 3 AM conversation, they thought... what if the API documentation could describe itself? There already was WADL, the XML-based Web Application Description Language. The name was coined after a joke they made, "Why WADL when you can Swagger?" Swagger went from being an internal fix for a company became to an open-source project other companies relied on. Swagger was acquired by SmartBear Software in 2015 from the renamed Wordnik, Reverb Technologies. According to OpenAPISpec's What Is the History of the SmartBear Swagger Acquisition Tony Tam also joined SmartBear as the VP of Products. Smartbear donated the Swagger Specification to a new group, the OpenAPI Initiative, sponsored by the Linux Foundation. I love SmartBear! They have hosted my old software testing Meetup, the now defunct Ministry of Testing - Boston many, many times. Since then: "OpenAPI" is the OpenAPI Specification as seen on GitHub "Swagger" is SmartBear's toolset such as Swagger UI, Swagger Editor, Swagger Codegen, and SwaggerHub (soon to be Swagger Studio). OpenAPI Initiative: Bridging Systems and Subcultures: A Swagger Origin Sto ## Publishing Playwright HTML reports on GitLab Pages DevFeed: [Publishing Playwright HTML reports on GitLab Pages]() Original publisher: [Read original article]() Author: T.J. Maher (noreply@blogger.com) Published: 2026-08-29T23:56:10Z Content type: tutorial Language: en Sources: [T.J. Maher]() Topics: [GitLab](), [Playwright](), [CI/CD](), [CI/CD Pipeline](), [Publishing]() Tags: [bun-create-playwright](), [ci-cd](), [ci-cd-pipeline](), [github-pages](), [gitlab](), [gitlab-ci](), [playwright]() ### AI overview This tutorial explains how to add a deploy stage to a GitLab CI/CD pipeline for a Bun-based Playwright project. The stage publishes generated Playwright HTML reports, including screenshots and videos, to GitLab Pages so they can be viewed online. ### Source excerpt We've added a lot to our demo project, bun--create-playwright. We've explored setting up a Playwright framework using bun, a new package manager bundled into Claude Code. We've added typechecking, and formatting and linting. We've set up a CI/ CD pipeline for our tests using GitLab, one with three stages: Quality: We check that the formatting, linting and typechecking is correct for any changes we attempt to push to the code base. Test: We run the smoke and then the regression tests to make sure that everything still works. Report: We bundle an archive of the Playwright generated HTML report, with screenshots and videos if things fail. For this post, we will add a new stage to this GitLab pipeline: Deploy: Where we will deploy the HTML report to GitLab Pages, so we can view it online. What is GitLab Pages? GitLab Pages is a built-in feature of GitLab that allows you to publish static websites directly from a repository in GitLab. Similar to GitHub Pages, it is commonly used to host project documentation, personal blogs, portfolios, or corporate landing pages for free. From the GitLab Docs / Pages: "To use GitLab Pages, you must create a project in GitLab to upload your website's files to. These projects can be either public, internal, or private. "By default, GitLab deploys your website from a specific folder called public in your repository. You can also set a custom folder to be deployed with Pages. When you create a new project in GitLab, a repository becomes available automatically. "To deploy your site, GitLab uses its built-in tool called GitLab CI/CD to build your site and publish it to the GitLab Pages server. The sequence of scripts that GitLab CI/CD runs to accomplish this task is created from a file named .gitlab-ci.yml, which you can create and modify. A user-defined job with pages: true property in the configuration file makes GitLab aware that you're deploying a GitLab Pages website. "You can either use the GitLab default domain for GitLab Pages websit ## Examining the artifacts job of a Playwright GitLab CI / CD pipeline DevFeed: [Examining the artifacts job of a Playwright GitLab CI / CD pipeline]() Original publisher: [Read original article]() Author: T.J. Maher (noreply@blogger.com) Published: 2026-08-29T23:19:22Z Content type: tutorial Language: en Sources: [T.J. Maher]() Topics: [Playwright](), [GitLab](), [CI/CD Pipeline](), [CI/CD](), [test]() Tags: [bun-create-playwright](), [ci-cd](), [ci-cd-pipeline](), [gitlab](), [playwright](), [screenshots](), [test](), [trace](), [videos]() ### AI overview This tutorial examines how a Playwright GitLab CI/CD pipeline stores and exposes test artifacts. It explains the playwright-report, test-results, and reports/junit folders and describes generated HTML and JUnit reports, screenshots, videos, and trace reports. ### Source excerpt You may have noticed that in the GitLab CI / CD Pipeline for our Playwright project, in the .gitlab-ci.yml file, after our scripts has run, in the Test stage, there is a subsection called "artifacts" with certain paths to something called "playwright-report", "test-results", and "reports". The Playwright -> Artifacts -> Reports stage playwright: extends: .bun_playwright stage: test timeout: 30 minutes ... ... artifacts: when: always paths: - playwright-report/ - test-results/ - reports/ reports: junit: reports/junit/results.xml expire_in: 30 days https://gitlab.com/tjmaher/bun-create-playwright/-/blob/main/.gitlab-ci.yml Every time Playwright tests run, it generates proof of the test execution: screenshots capturing the state of the UI when a test failed, video recordings of an entire browser session, HTML and JUnit XML test reports, trace reports showing action logs, network requests. These artifacts, when the tests run locally, are placed by the Playwright Test runner in generated folders, playwright-report and test-results, along with a folder called reports/junit. With this post, we will be examining how this artifacts stage of the GitLab CI/ CD pipeline produces downloadable artifacts we can examine. Playwright-Report: A Playwright Test folderThe Playwright Test runner creates a folder called "playwright-report", if it doesn't already exist, and an HTML file called index.html documenting the completed test run. From Playwright.dev / Test Reporters: "Playwright Test comes with a few built-in reporters for different needs and ability to provide custom reporters. [...] All built-in reporters show detailed information about failures, and mostly differ in verbosity for successful runs. [...] HTML reporter produces a self-contained folder that contains report for the test run that can be served as a web page". The HTML Report is the one that automatically opens after you run your tests locally, or if you are using the node package manager: npx playwright show-report ## How Developers Can Test Their Feature Branch Against Various Playwright Configurations Before Creating a Merge Request in GitLab CI/CD DevFeed: [How Developers Can Test Their Feature Branch Against Various Playwright Configurations Before Creating a Merge Request in GitLab CI/CD]() Original publisher: [Read original article]() Author: T.J. Maher (noreply@blogger.com) Published: 2026-08-28T20:18:08Z Content type: tutorial Language: en Sources: [T.J. Maher]() Topics: [GitLab](), [CI/CD](), [Playwright](), [YAML](), [Development]() Tags: [bun-create-playwright](), [chromium](), [ci-cd](), [firefox](), [gitlab](), [gitlab-ci](), [playwright](), [tests](), [yaml]() ### AI overview This tutorial shows how to configure a GitLab CI/CD pipeline so developers can test a feature branch before creating a merge request. It uses spec inputs in a YAML configuration to let users choose the branch, Playwright test suite, and browser, including Chromium, Firefox, WebKit, or all browsers. ### Source excerpt Developers need the option to test out their feature branch before merging it into main. In the last section, we set up a GitLab CI/CD Pipeline in our bun-create-playwright project to check every GitLab Merge Request. Now, we will be giving developers option to create a new pipeline where they can choose: Which feature branch to test against. Which test suite to execute (LoginPage tests? Secure Area? Or all of them?) Which Playwright browser to use: Chromium, Firefox, WebKit, or all. All these features can be set up using our .gitlab-ci.yaml file! Go to to bun-create-playwright, view the Pipelines section, and select the New Pipeline button. Run a New Bun-Create-Playwright Pipeline If you go to the Run new pipeline page at https://gitlab.com/tjmaher/bun-create-playwright/-/pipelines/new you can see the following default values I've set: https://gitlab.com/tjmaher/bun-create-playwright/-/pipelines/new By default: Branch name is "main", TEST_SUITE is "all", BROWSER is "all". ... But all these values can be set, with the developer choosing the options laid out in the .gitlab-ci.yaml file. Collect User Data With Spec Inputs We are going to be adding to the GitLab Pipeline we built in our last post Setting up a CI/ CD pipeline with GitLab: Quality, Test and Report. First, we are going to add a "spec" section to the header of the YAML file to define the behavior of a pipeline, and within that spec header, we will ask the person who triggered a new pipeline to set user defined inputs for the pipeline. spec: inputs: browser: description: "Browser project to run against." default: "all" options: ["all", "chromium", "firefox", "webkit"] suite: description: "Select full regression suite, or a single spec" default: "all" options: ["all", "login.spec.ts", "secure-area.spec.ts"] This is where we declare the "browser" and "suite" variables that appear when a user creates a new pipeline. We've given them a choice to run their feature branch code against: Browser: All, Chromium, Fir ## Setting up a CI/ CD pipeline with GitLab: Quality, Test and Report DevFeed: [Setting up a CI/ CD pipeline with GitLab: Quality, Test and Report]() Original publisher: [Read original article]() Author: T.J. Maher (noreply@blogger.com) Published: 2026-08-25T02:28:52Z Content type: tutorial Language: en Sources: [T.J. Maher]() Topics: [CI/CD Pipeline](), [GitLab](), [Testing](), [Playwright](), [pull-requests](), [TypeScript]() Tags: [bun-create-playwright](), [ci-cd](), [ci-cd-pipeline](), [code-reviews](), [gitlab](), [playwright](), [test](), [testing](), [typescript](), [workflows]() ### AI overview A tutorial on setting up a three-stage GitLab CI/CD pipeline for merge requests. The pipeline runs code-quality checks, smoke and regression tests, and produces a downloadable report, with stages executed sequentially and jobs within each stage running in parallel. ### Source excerpt So far, we have reviewed how to review code with ES Lint + Prettier and Typecheck, how to set up and run smoke tests, how to run all Playwright + TypeScript tests, and reviewed the HTML report of results. In this post, we are going to set up a three stage GitLab CI/ CD pipeline that will run against every merge request: Quality (lint, typecheck, prettier) --> Test ( smoke + regression ) --> Report ( Downloadable ) I haven't used GitLab since when I worked at ThreatStack back in 2020. ( See my blog entry Getting to Know GitLab and How They Test the UI ) GitLab reads .gitlab-ci.yml from the repository root and turns it into a pipeline, a set of jobs, grouped into stages, running whenever you push a change to a repository. Stages run one after another, and jobs within a stage run in parallel. If one stage fails, the stages after it are skipped. This begs the question: What is GitLab? What is CI/ CD? Or a pipeline? Or a merge request? What is GitLab? GitLab began in 2011 as a side project by Ukrainian programmer Dmytro Zaporozhets, built to help developers work together on code more easily. Over time, it grew into a large open-source DevOps platform. More than just storing code, it handles code reviews, CI/CD (continuous integration and continuous delivery), and package registries. A company called GitLab Inc. was eventually created to turn the project into a commercial product. What makes GitLab different from tools that only host Git repositories (like a basic Git server) is that it bundles the entire software delivery process into one application. This includes: Merge requests - GitLab's term for proposing and reviewing code changes before they're merged into the main codebase (similar to a "pull request" in GitHub) Issue tracking - a built-in system for logging bugs, tasks, and feature requests Pipelines - automated workflows that build, test, and deploy code whenever changes are pushed So instead of stitching together separate tools for version control, testing, an ## How to Configure Playwright Test to run smoke tests, headed tests, and debug versions through scripts in package.json DevFeed: [How to Configure Playwright Test to run smoke tests, headed tests, and debug versions through scripts in package.json]() Original publisher: [Read original article]() Author: T.J. Maher (noreply@blogger.com) Published: 2026-08-20T02:13:32Z Content type: tutorial Language: en Sources: [T.J. Maher]() Topics: [Playwright](), [Script](), [Bun](), [Smoke Tests](), [test](), [Package manager]() Tags: [bun](), [bun-create-playwright](), [commands](), [gitlab](), [how-to](), [install](), [playwright](), [test](), [tests]() ### AI overview A tutorial on configuring Playwright Test commands in package.json scripts. It demonstrates shortcuts for headed, traced, Chromium, Firefox, WebKit, smoke, debugging, reporting, linting, formatting, and type-checking workflows, and explains using Bun and bunx to run commands. ### Source excerpt Earlier, we went over how we could create scripts in the package.json file of our Playwright framework to add typechecking, linting, and formatting your code with prettier. Want to see the entire bun-create-playwright project? It is on tinyurl.com/bun-create-playwright! With this post, we will explore how the built-in test runner for Playwright Test can run headed tests, debug versions of tests, and smoke tests. ... and shortcuts for all of these can be set up in the scripts in your package.json! If you are using "bun" as a package manager, as we are in bun-create-playwright, just type out "bun run", a space and then the shortcut such as: bun run test package.json "scripts": { "test": "playwright test", "test:headed": "playwright test --headed", "test:trace": "playwright test --trace on", "test:chromium": "playwright test --project=chromium", "test:firefox": "playwright test --project=firefox", "test:webkit": "playwright test --project=webkit", "test:smoke": "playwright test --project=chromium --grep '@smoke'", "test:flaky": "playwright test --project=chromium --repeat-each=20", "test:ui": "playwright test --ui", "test:debug": "playwright test --debug", "test:failed": "playwright test --last-failed", "test:login": "playwright test tests/login.spec.ts", "test:secure-area": "playwright test tests/secure-area.spec.ts", "report:list": "playwright test --reporter=list", "report:line": "playwright test --reporter=line", "report:dot": "playwright test --reporter=dot", "report:blob": "playwright test --reporter=blob", "report": "playwright show-report", "codegen": "playwright codegen", "lint": "eslint .", "lint:ci": "eslint . --max-warnings 0", "lint:fix": "eslint . --fix", "format": "prettier --write .", "format:check": "prettier --check .", "format:debug": "prettier --check . --log-level debug", "format:diff": "prettier --list-different", "typecheck": "tsc --noEmit" }, bun-create-playwright / package.json Do you need to really set up shortcuts like these? Certainly not! B ## Implementing Page Objects in Playwright DevFeed: [Implementing Page Objects in Playwright]() Original publisher: [Read original article]() Author: T.J. Maher (noreply@blogger.com) Published: 2026-08-16T22:04:38Z Content type: tutorial Language: en Sources: [T.J. Maher]() Topics: [Playwright](), [selectors](), [test](), [Development]() Tags: [bun](), [bun-create-playwright](), [code](), [gitlab](), [jest](), [page-object](), [playwright](), [selectors](), [test](), [tests]() ### AI overview A tutorial on using Playwright page objects to organize web application tests, centralize selectors, reduce repetition, and simplify maintenance. It compares Playwright Test and Library approaches and demonstrates setting up a login-page object. ### Source excerpt Picture a login screen, such as The-Internet / Login. On this LoginPage, there is: a heading: Login Page a user name textbox with the label, "Username" a password textbox with the label, "Password" a login button, with the role of a button, and the name of "Login" a flash message that appears if you enter invalid credentials such as "NotAUser" and "NotAPassword". If you successfully log in with "tomsmith" and "SuperSecretPassword!, there is a SecureArea: a heading: "Secure Area" a flash message "You logged into a secure area!" a Logout button. Sure, you could interact with each web element in your test... but what if the username text box locator changes? You would have to update multiple tests every time the element changed. ... Instead, you could place it in a Page Object, something that Playwright handles well! "A page object represents a part of your web application. An e-commerce web application might have a home page, a listings page and a checkout page. Each of them can be represented by page object models. "Page objects simplify authoring by creating a higher-level API which suits your application and simplify maintenance by capturing element selectors in one place and create reusable code to avoid repetition". Using Playwright's Built-In Test Runner? Or Something Else? You may have noticed in https://playwright.dev/docs/pom that there are two different styles of page objects. One for "Test". One for "Library". Test: If you are writing actual Playwright test suites, and Playwright's built in test runner, use the Test section as a guide when creating page objects. Library: If you are integrating Playwright into an existing test framework such as Jest or Cucumber and just want browser automation, instead of having pre-built page fixtures, etc, you can use this format. Setting Up Page Objects Let's review a page object I created for the main login page on my GitLab account for the bun-create-typescript project, tests/pages/LoginPage.ts. The first thing we do is ## How Playwright Frameworks get configured with playwright.config.ts DevFeed: [How Playwright Frameworks get configured with playwright.config.ts]() Original publisher: [Read original article]() Author: T.J. Maher (noreply@blogger.com) Published: 2026-08-15T02:30:20Z Content type: tutorial Language: en Sources: [T.J. Maher]() Topics: [Playwright](), [Testing](), [CI/CD](), [browsers](), [Framework]() Tags: [browsers](), [bun](), [bun-create-playwright](), [ci-cd](), [config](), [playwright](), [testing]() ### AI overview This tutorial examines the playwright.config.ts file generated by `bun create playwright`. It explains default test settings, browser projects for Chromium, Firefox, and WebKit, mobile and branded browser configurations, and how retries differ between local runs and CI/CD pipelines. ### Source excerpt When we installed bun, a new package manager owned by Anthropic, then ran "bun create playwright", a new automation framework was stood up, along with sample tests, and a Playwright configuration file. In this post, we will be examining the file generated: playwright.config.ts. Personally, I find the pre-generated file very hard to scan... there are so many options and documentation in the comments, it is difficult for me to focus on the code. Let's examine just the code generated below. If you need to see the whole file, you can see it here: https://playwright.dev/docs/test-configuration Playwright.dev / Configuration mentions, "Playwright has many options to configure how your tests are run. You can specify these options in the configuration file". What is Configured By Default? import { defineConfig, devices } from '@playwright/test'; export default defineConfig({ testDir: './tests', fullyParallel: true, forbidOnly: !!process.env.CI, retries: process.env.CI ? 2 : 0, workers: process.env.CI ? 1 : undefined, reporter: 'html', // baseURL: 'http://localhost:3000', /* Collect trace when retrying the failed test. See https://playwright.dev/docs/trace-viewer */ trace: 'on-first-retry', }, /* Configure projects for major browsers */ projects: [ { name: 'chromium', use: { ...devices['Desktop Chrome'] }, }, { name: 'firefox', use: { ...devices['Desktop Firefox'] }, }, { name: 'webkit', use: { ...devices['Desktop Safari'] }, }, }); I know what you are thinking ... What the heck is process.env.CI ? 2 : 0? This is know as a ternary operator. It is a shorthand for: "If A then B, else C". You can run tests two ways: Locally, on your local machine, or through a CI / CD Pipeline like Jenkins, GitHub Actions, or GitLab. If you are running tests on CI / CD, the process.env.CI would automatically get set. Since A is true, the value of retries would be "2". If you are running tests locally, the process.env.CI would NOT get set. Since A is false, the value "0" would be selected. CI / ## Running Tests with Playwright Test Explorer and Generating Tests with Codegen DevFeed: [Running Tests with Playwright Test Explorer and Generating Tests with Codegen]() Original publisher: [Read original article]() Author: T.J. Maher (noreply@blogger.com) Published: 2026-08-11T03:00:47Z Content type: tutorial Language: en Sources: [T.J. Maher]() Topics: [Playwright](), [Testing](), [Visual Studio Code](), [browser]() Tags: [browsers](), [bun-create-playwright](), [debugging](), [playwright](), [testing](), [vscode]() ### AI overview A tutorial on using Playwright Test Explorer in VS Code to discover, run, and debug tests across Chromium, Firefox, and WebKit, and on using Playwright's CodeGen to generate test drafts with locators and assertions from browser interactions. ### Source excerpt Finding the best locator for a web element can be a hassle: Right clicking on an element in Google Chrome. Inspecting the element. Going to Chrome Developer Tools. Try to decide what to do if there isn't a clear test id. Playwright comes with a built in code generator where it can built out a rough draft of a test while you interact with a website. "Playwright will look at your page and figure out the best locator, prioritizing role, text and test id locators. If the generator finds multiple elements matching the locator, it will improve the locator to make it resilient that uniquely identify the target element", according to Playwright.dev / Test Generator. Do you have the Integrated Development Environment (IDE) by Microsoft, VS Code? You can get it at the Visual Studio Marketplace. Playwright Test Explorer Playwright.dev / Getting Started VS Code: https://playwright.dev/docs/getting-started-vscode After installation, you will see a beaker icon in your VS Code left navigation menu. Selecting that, you can see your tests, such as the default ones Playwright automatically adds when it is installed: Here you can see that Test Explorer has discovered the test suite example.spec.ts, along with two tests it created: has title: Verifies that if you go to playwright.dev, that it has a link titled "Get Started". get started link: Verifies at playwright.dev that after clicking on Get Started link, the heading says "Installation". Selecting the green arrow button will open up three browser windows: Chromium, Firefox, and a WebKit browser created by Playwright, mimicking Safari. It will run a total of six tests. But wait! There's more! You can: Run a single test. Run all tests at different levels. Run on multiple browsers. Show a browser. You can also debug your tests: Set breakpoints by clicking on the gutter next to a line number Right clicking the test and select "Debug test". Running your test will pause at your breakpoint, allowing you to step through your code. You can ## Checking code with lint, formatting it with prettier DevFeed: [Checking code with lint, formatting it with prettier]() Original publisher: [Read original article]() Author: T.J. Maher (noreply@blogger.com) Published: 2026-08-10T23:23:45Z Content type: tutorial Language: en Sources: [T.J. Maher]() Topics: [ESLint](), [Prettier](), [Playwright](), [Programming]() Tags: [bun](), [bun-create-playwright](), [eslint](), [formatting](), [linter](), [playwright](), [typescript]() ### AI overview This tutorial explains how to add ESLint for static analysis and Prettier for consistent code formatting in a Playwright project. It also discusses eslint-plugin-playwright and using eslint-config-prettier to reduce conflicts between ESLint and Prettier. ### Source excerpt Now that we've installed bun, Anthropic's package manager, scaffolded a Playwright framework and closely examined the results, and added typechecking with TypeScript's compiler, it's time to add ways to check the code with lint, and reformat the code with prettier. We will be using: ESLint, as the static-analysis tool to review the code without running it. Little bits of fluff -- like syntax errors, structural bugs, anti-patterns, and code style violations -- can collect on your code, so it helps to run a linter to help catch it all, such as ESLint. There is also a linter, eslint-plugin-playwright, for Playwright tests. Prettier enforces a consistent code style across your entire codebase. Because ESLint and Prettier can conflict, we will be using Prettier's eslint-config-prettier, which turns off all rules that are unnecessary or might conflict with ESLint. What is a Linter? According to the Wikiwand entry for Lint, "Stephen C. Johnson, a computer scientist at Bell Labs, came up with the term 'lint' in 1978 while debugging the yacc grammar he was writing for C and dealing with portability issues stemming from porting Unix to a 32-bit machine. The term was borrowed from lint, the tiny bits of fiber and fluff shed by clothing, as the command he wrote would act like a lint trap in a clothes dryer, capturing waste fibers while leaving whole fabrics intact. The lint program was released outside of Bell Labs in Unix V7, in 1979. "In his 1978 paper, Johnson explained his reasons for creating a new program to detect errors: '...the general notion of having two programs is a good one' because they concentrate on different things, thereby allowing the programmer to 'concentrate at one stage of the programming process solely on the algorithms, data structures, and correctness of the program, and then later retrofit, with the aid of lint, the desirable properties of universality and portability' " What is ESLint? Website: https://eslint.org/ GitHub: https://github.com/eslint/e ## Add Type Checking and TSConfig to Bun-Create-Playwright DevFeed: [Add Type Checking and TSConfig to Bun-Create-Playwright]() Original publisher: [Read original article]() Author: T.J. Maher (noreply@blogger.com) Published: 2026-08-08T03:10:43Z Content type: tutorial Language: en Sources: [T.J. Maher]() Topics: [Bun](), [TypeScript](), [Playwright](), [Compiler](), [Code](), [Command-line interface]() Tags: [bun](), [bun-create-playwright](), [code](), [compiler](), [playwright](), [terminal](), [typescript]() ### AI overview This tutorial adds TypeScript type checking and tsconfig configuration to a Bun-Create-Playwright project. It explains why Playwright should be run alongside the TypeScript compiler and demonstrates using tsc --noEmit to check code without emitting output files. ### Source excerpt Now that we have installed bun, Anthropic's package manager, and scaffolded a Playwright framework and closely examined the results, we are going to explore with our Bun-Create-Playwright project ways to check if our code is correct. The first method we will be exploring is typechecking. Why Typechecking? As the Playwright.dev / Node.js Introduction mentions: "[...] Playwright does not check the types and will run tests even if there are non-critical TypeScript compilation errors. We recommend you run TypeScript compiler alongside Playwright. "[...] Note that Playwright only supports the following tsconfig options: allowJs, baseUrl, paths, references and extends. "[...] By default, Playwright will look up a closest tsconfig for each imported file by going up the directory structure and looking for tsconfig.json or jsconfig.json. This way, you can create a tests/tsconfig.json file that will be used only for your tests and Playwright will pick it up automatically".Before we go further down this road... What is Type Checking? According to Type Checking in TypeScript: A Beginners Guide, every piece of data in TypeScript is given a "type", and this "type" determines what properties the data has, and what methods are available to it. The types can be things like a Number, String, Enum, Boolean, Array, Object, Type assertions, or others. Since all data in TypeScript is given a type, it means that the TypeScript compiler, tsc, can check every property to make sure it is being used correctly. It makes sure that the expected properties exist and that the methods and functions are all compatible. And best of all, you can run these checks in your IDE as you are writing the code! To run typechecking against our code, all we have to do is execute from the Terminal: tsc --noEmit Since we are just kicking the tires of our code to see what happens, we don't need to emit "compiler output files like JavaScript source code, source-maps or declarations. This makes room for another tool ## Scaffold and Run Playwright Tests with Bun DevFeed: [Scaffold and Run Playwright Tests with Bun]() Original publisher: [Read original article]() Author: T.J. Maher (noreply@blogger.com) Published: 2026-08-06T17:37:06Z Content type: tutorial Language: en Sources: [T.J. Maher]() Topics: [Playwright](), [Bun](), [Node.js](), [TypeScript](), [Windows]() Tags: [bun](), [bun-create-playwright](), [playwright](), [test](), [typescript](), [windows]() ### AI overview A tutorial on creating a TypeScript Playwright project with Bun, installing its browsers on Windows, configuring a Bun lockfile and test script, and running the included tests. It notes that Playwright's test runner remains a Node.js program and documents an additional Bun and Playwright installation step for a Windows bug. ### Source excerpt We covered in the last blog post how to install bun, a new package manager. In this blog post, we will look into using bun to install a new Playwright framework. Create the Playwright Framework Once I installed bun on my Windows PC and was up and running I created a new folder, "bun-create-playwright". I opened up that folder in VS Code, along with a new PowerShell terminal. In that terminal I entered: bun create playwright This activated the interactive Playwright installer that Playwright comes with. I selected I wanted it to create for me a TypeScript project, placing the tests in the default folder, tests, but I decided not to add a GitHub Actions workflow. I wanted to experiment with using GitLab. I chose it to set up and install all the browsers for me... which it did... using NPX, part of Node. Wait a second, when it comes to our Playwright framework, doesn't bun replace node? No. Bun might be a JavaScript runtime, a package manager, and a bundler shipped as a single software tool, but in our case we are simply using it as a package manager in our Playwright framework. Bun works alongside Node.js in the Playwright project. We still use Playwright's test runner, a Node.js program. Bun handles installations and run tasks. Alert: Windows Bug! Initially, that wasn't enough to install Playwright's internal browsers. There is a bug with bun + Playwright Windows where we also need to: bun add --dev @playwright/test bunx playwright install That was enough for the browsers to install. Create the Bun Lock File After the browsers are installed, we need to install bun in our project, to create from the package.json a bun installation. Run in the Terminal: bun install Review the newly created file bun.lock.file in the root directory of the project. Delete the package-lock.json file. Add the test script to the Package.json If you look in the package.json file, you can see that the scripts code block is currently empty. "scripts": {} Inside this code block, we will be addin ## Introducing bun, a new package manager and JavaScript runtime environment DevFeed: [Introducing bun, a new package manager and JavaScript runtime environment]() Original publisher: [Read original article]() Author: T.J. Maher (noreply@blogger.com) Published: 2026-08-06T01:58:25Z Content type: article Language: en Sources: [T.J. Maher]() Topics: [Bun](), [Package manager](), [JavaScript](), [Playwright](), [Node.js]() Tags: [bun](), [bun-create-playwright](), [getting-started](), [installation](), [javascript](), [node-js](), [playwright](), [test-automation](), [typescript]() ### AI overview This article examines Bun as a JavaScript package manager and runtime, including its use with Playwright projects. It explains how Bun compares with npm, Yarn, and pnpm, and discusses its integrated tooling and claimed performance advantages. ### Source excerpt New job? New toolset to explore! In this post I'll be investigating a new JavaScript package manager and runtime environment called bun.sh. You may have noticed on Playwright.Dev's Getting Started / Installation section there are three different ways to install a ui or api test automation framework with the latest version of Playwright: npm init playwright@latest yarn create playwright pnpm create playwright For this blog post I'll be investigating a fourth way, the new toolset they just started using at work, bun.sh. bun create playwright What is npm, yarn, pnpm, and bun? These are called package managers. What is a package? Developing a project, you don't have to figure out how to code everything yourself. You can include in your projects outside libraries, or "packages" of code from from the public JavaScript registry npmjs.com. The problem is that these packages then need to be downloaded, installed, managed, and updated whenever they are updated. JavaScript projects can use a package manager, such as bun, to help this process. When putting together a Playwright automation framework based around JavaScript and TypeScript, Playwright uses the Node.js JavaScript runtime environment, to run its test runner, execute automation scripts, and manage its browser instances.(See Nodejs.org / About ) There is a division of labor: Node.js runs these internal functions like running tests. NPM, Yarn, PNPM, and now Bun handle the packages. Why are there so many package managers? Each has its own specialization. The original NPM is bundled already with Node.js. Yarn is a Facebook toolset that was created when NPM was found to work too slow. PNPM was created to be smaller and therefore faster. And bun was built for quick startup and installation speed, good especially if you have a CI/ CD pipeline that has a LOT of packages to install each time the tests run. NPM, released in 2010, is the Node Package Manager for Node.js, a JavaScript Runtime Environment. According to NodeJS.org ## Presentation on Building React Native Test Automation with Detox and TypeScript DevFeed: [Presentation on Building React Native Test Automation with Detox and TypeScript]() Original publisher: [Read original article]() Author: T.J. Maher (noreply@blogger.com) Published: 2026-06-30T00:51:55Z Content type: article Language: en Sources: [T.J. Maher]() Topics: [Mobile Testing](), [React](), [TypeScript](), [CI/CD](), [Mobile](), [GitHub Actions](), [Vibe coding]() Tags: [ci-cd](), [github-action](), [mobile](), [mobile-test-automation](), [mobile-testing](), [react-native](), [testing](), [typescript](), [vibe-coding]() ### AI overview The article promotes T.J. Maher's presentation for the Sydney Testers Meetup on building automated tests for React Native applications with Wix's open-source Detox framework and TypeScript. ### Source excerpt If I presentation to the Sydney Testers Meetup in Australia, from my home in the Massachusetts, through Zoom, does that make me an international speaker? [ Vote in the New Poll, on LinkedIn ] There is still time to sign up for the event at: https://www.meetup.com/sydney-testers/events/315166776 "T.J. Maher, the former organiser at Ministry of Testing Boston, blogger and speaker, will be presenting from the US on using the Detox framework to create effective test automation frameworks for React Native applications. "Building a React Mobile Automated Test Framework using Detox + TypeScript by T.J. Maher "Writing automated tests for a React Native mobile application is notoriously difficult. Mobile components display on the page, but are not fully loaded. Lengthy animations and slow-loading components take a while to finish. Timing issues cause your automated tests to error out giving the appearance of flaky tests. "T.J. Maher will be sharing his experience tackling these problems using the open-source mobile testing framework, Wix's Detox, designed specifically for testing React Native applications. * "Setting up a mobile test automation framework. * "Vibe-coding a toy React Mobile Login page app to test against ( tinyurl.com/detox-demo ). * "How to reduce timing issues and flakiness in automated tests. * "Refactoring code into tests, page objects & base pages, separating out credentials and message strings for easier maintainability. * "Setting up automated tests in CI / CD for iOS simulators and Android emulators with GitHub Action Workflows. * "How developers can test their code before they push it into the main branch. "About T. J. Maher: --------------------- "A former organizer of the now defunct Ministry of Testing - Boston, T.J. Maher is a Senior Software Development Engineer in Test (SDET), based in the Boston/South Shore area of Massachusetts, with a decade of experience building web + mobile test automation frameworks. His recent work includes architecting ## T.J. Maher Elected to the Board of Directors of the Software Quality Group of New England DevFeed: [T.J. Maher Elected to the Board of Directors of the Software Quality Group of New England]() Original publisher: [Read original article]() Author: T.J. Maher (noreply@blogger.com) Published: 2026-06-17T23:26:28Z Content type: opinion Language: en Sources: [T.J. Maher]() Topics: [sqgne](), [Testing](), [Software Engineering]() Tags: [community](), [development](), [qa](), [quality](), [sqgne](), [testing]() ### AI overview T.J. Maher announces election to the volunteer board of directors of the Software Quality Group of New England, an all-volunteer nonprofit community focused on software quality. The article also mentions Maher's monthly SDET Lean Coffee discussion group. ### Source excerpt I've been elected to be on the Board of Directors of the Software Quality Group of New England (sqgne.org) on the volunteer leadership committee! The Software Quality Group of New England (SQGNE) is an all-volunteer, nonprofit professional community in New England dedicated to software quality. Since its founding, SQGNE has brought together QA engineers, SDETs, and software quality professionals for monthly educational presentations, discussions, and networking -- covering everything from testing techniques and process improvement to the latest tools and industry trends. I also have founded and moderate an online monthly SDET Lean Coffee discussion group, bringing together software development engineers in test, quality engineers, and automation practitioners to exchange ideas, challenges, and emerging practices. After our hiatus during the summer, we will be meeting monthly up in Burlington, MA. Check us out! Happy Testing! -T.J. Maher Software Engineer in Test BlueSky | YouTube | LinkedIn | Articles ## Testing and AI Workshop by James Bach of Rapid Software Testing - Notes DevFeed: [Testing and AI Workshop by James Bach of Rapid Software Testing - Notes]() Original publisher: [Read original article]() Author: T.J. Maher (noreply@blogger.com) Published: 2026-06-12T18:10:14Z Content type: opinion Language: en Sources: [T.J. Maher]() Topics: [Testing](), [Software Testing](), [Artificial Intelligence](), [ChatGPT]() Tags: [agentic](), [ai](), [chatgpt](), [james-bach](), [notes](), [rapid-software-testing](), [rst](), [software-testing](), [testing]() ### AI overview A personal account of James Bach's Testing and AI Workshop, describing its AI-assisted testing demonstrations, hands-on exercise, and review session. The author enjoyed the class but had limited time to complete the practical exercise because of family responsibilities. ### Source excerpt Last week, I saw that there was a new half day workshop by one of the creators of Rapid Software Testing, James Bach, Testing and AI Workshop, and that they were offering a 50% discount for anyone who was unemployed, so I just had to attend. Visit James Bach's Satisfice.com Download Page to download PDFs on topics such as Responsible Work (May 2026), AI Writing Policy (April 2026), Heuristic Test Strategy Model (December 2024), Rapid Software Testing Explored Class Appendices (December 2024) Why Testers? (Oct 2024) and ChatGPT Sucks at Being a Testing Expert (August 2023) YouTube Channel: Rapid Software Testing Check out James Bach's Classes at https://www.satisfice.com/classes (50% discount if unemployed) The next Testing and AI Workshop will be July 6, 2026 "In each session, the instructors will first perform a live 'testopsy.' This is a demonstration of AI-assisted testing (using both assistive and agentic modes of AI) on a real product, accompanied by an analysis and explanation of what happened during the demo. During this part of the workshop, you may ask questions or offer critique. "Next the instructors will challenge you to perform a similar process or solve a similar problem with the help of AI. You will have two hours. You will be able to work alone or in groups, as you like. "Finally, the instructors will review and critique your work, if you choose to share it. At the end of the event, you will get to keep the videos". I really enjoyed the class! It involved an hour-and-a-half webinar, where James Bach walks people though how he uses AI, a few hours where you can work on your own project for the course, then another hour-and-a-half webinar where course attendees could review what they came up with to analyze a site. My only problem with the course was that my rambunctious seven year old was home sick, and I wasn't able to dedicate a few hours to come up with how to use AI to test a website, since I was busy making lunch and chatting with my kiddo. What ## New Position Unlocked: Senior SDET at AAA Life Insurance, starting Monday, June 15th, 2026! DevFeed: [New Position Unlocked: Senior SDET at AAA Life Insurance, starting Monday, June 15th, 2026!]() Original publisher: [Read original article]() Author: T.J. Maher (noreply@blogger.com) Published: 2026-06-04T02:16:39Z Content type: opinion Language: en Sources: [T.J. Maher]() Topics: [Software Testing](), [Mobile]() Tags: [2026](), [aaa-life](), [automation](), [community](), [leadership](), [linkedin](), [mobile](), [programming](), [software-testing](), [sqgne](), [testing]() ### AI overview The author announces starting a Senior SDET position at AAA Life Insurance Company on June 15, 2026, after an extended job search. The article also announces the author's nomination as a volunteer director of the Software Quality Group of New England and describes recent community activities, including a talk on building a mobile automation test framework. ### Source excerpt I have two announcements: I've accepted a job offer as a Senior SDET role at AAA Life Insurance Company, and will be starting Monday, June 15th! And I have been nominated to be one of the volunteer Directors on the leadership board of the Software Quality Group of New England. Man, the job market is brutal! It took me four months of job searching in 2025 to find SELF Id when MassMutual outsourced its technology department. And it took me four months of near constant job searching in 2026 to find AAA Life when I was caught up in the second round of SELF's layoffs in the end of January. After throwing countless resumes into the void, submitting post after post on LinkedIn, experimenting with countless automation frameworks and programming projects on tjmaher.com, and spamming my entire LinkedIn Network (sorry about that!), and everyone I have worked with in the past twenty years as a software tester, desperately looking for job leads, it was a staffing firm working for AAA Life who found me. Thank you, Refactor Talent! Rewriting my LinkedIn Resume to make sure that I was using proper keywords in my "About" section of my LinkedIn Profile seems to have done the trick! I'd also like to announce that I found another awesome software testing community to be a part of: The Software Quality Group of New England, a local non-profit meeting monthly in Burlington, MA. Come join us! And we are always looking for in-person speakers. I've been missing being part of a software testing community! I was Meetup Organizer for the now defunct Ministry of Testing - Boston group from 2016 to 2024, loving every minute I was trying to find speakers, sponsors and hosts. I made so many great connections during my tenure. It's sad the Meetup group was shut down by the Ministry of Testing UK a few months ago, but I am glad to be part of a new software testing group! In the past month as a new member of the SQGNE, I have: * Given a talk to the group on building a mobile automation test framework ## SDET Lean Coffee #1: With AI, what is useful testing and what is workslop? SQGNE, June 2, 2026 DevFeed: [SDET Lean Coffee #1: With AI, what is useful testing and what is workslop? SQGNE, June 2, 2026]() Original publisher: [Read original article]() Author: T.J. Maher (noreply@blogger.com) Published: 2026-06-02T20:35:29Z Content type: opinion Language: en Sources: [T.J. Maher]() Topics: [Testing](), [Agile](), [sqgne](), [Development]() Tags: [agents](), [agile](), [agile-testing](), [ai](), [sqgne](), [team](), [teams](), [testing](), [work]() ### AI overview A report on the first SDET Lean Coffee organized by the Software Quality Group of New England. Attendees discussed useful testing practices with AI, AI-generated workslop, AI workflows, the testing of AI agents, and the pressures faced by software testers. The article also explains the Lean Coffee meeting format and announces the next session. ### Source excerpt With AI, what is useful when it comes to testing and what is workslop? How do you create workflows in AI? With AI producing massive amounts of code, how can a tester keep up? These are some of the topics attendees decided to talk about in our first ever SDET Lean Coffee, as part of the Software Quality Group of New England ( sqgne.org ). We exchanged war stories, horror stories, shared insights, and provided a bit of group therapy as we talked about the stress involved being the main support role of the software development team. A surprise guest was Lisa Crispin (LisaCrispin.com), author of "Agile Testing: A Practical Guide for Testers and Agile Teams". Lisa has been working with DORA, Google Cloud's DevOps Research and Assessment division. Recently, Lisa gave a talk teaming up with the "Beyond Quality" podcast, sharing what she has been doing "AI, testing, and the DORA AI Capabilities Model" at Lisa's site at https://lisacrispin.com/2026/04/20/ai-testing-and-the-dora-ai-capabilities-model/ discussing: The Dora AI Capabilitues Model How we need to test AI agents since AI agents can degrade over time What is a "Lean Coffee"?"Lean Coffee is a structured, but agenda-less meeting. Participants gather, build an agenda, and begin talking. Conversations are directed and productive because the agenda for the meeting was democratically generated". This format arose over fifteen years ago, when "Jim Benson and Jeremy Lightsmith wanted to start a group that would discuss Lean techniques in knowledge work - but didn't want to start a whole new cumbersome organization with steering committees, speakers, and such. They wanted a group that did not rely on anything other than people showing up and wanting to learn or create", according to LeanCoffee.org. When Is The Next SDET Lean Coffee? SDET Lean Coffees for the SQGNE will (usually) be held the first Tuesday of each month at 12:00 pm to 1:00 pm EDT. Interested in attending the next session Tuesday, July 7th? Register at the Soft ## Come join us at the next SQGNE Meeting! Open-Source Malware: Defending Your Software Supply Chain From Evolving Threats - June 17, 2026 DevFeed: [Come join us at the next SQGNE Meeting! Open-Source Malware: Defending Your Software Supply Chain From Evolving Threats - June 17, 2026]() Original publisher: [Read original article]() Author: T.J. Maher (noreply@blogger.com) Published: 2026-06-02T02:34:08Z Content type: news Language: en Sources: [T.J. Maher]() Topics: [open-source-security](), [supply-chain-security](), [Malware](), [npm](), [PyPI](), [GitHub](), [software composition analysis](), [Security]() Tags: [github](), [malware](), [npm](), [open-source](), [pypi](), [sca](), [security](), [software-supply-chain](), [sqgne](), [supply-chain](), [supply-chain-attacks]() ### AI overview The Software Quality Group of New England will host a June 17, 2026 meeting featuring Bryan Whyte of Sonatype on open-source malware and software supply chain defense. The session will cover threats targeting npm, PyPI, GitHub, and development pipelines; differences between open-source malware and traditional malware or vulnerabilities; and common tactics used in software supply chain attacks. ### Source excerpt "Open-Source Malware: Defending Your Software Supply Chain From Evolving Threats" will be the topic of the next Software Quality Group of New England (sqgne.org) meeting. Speaker: Bryan Whyte, CISSP Director, Solutions Engineering @Sonatype Date: June 17, 2026 @ 6:00 pm Join us on Zoom or in person at Burlington, MA ( Register Here ) "Bryan Whyte breaks down the latest wave of open source malware, explains how these threats diverge from traditional vulnerabilities, and shares actionable steps for organizations to defend mission-critical software. "As organizations deepen their reliance on open-source software, evolving security threats are reshaping the landscape at an unprecedented pace. "Threat actors are now increasingly targeting development pipelines and trusted ecosystems like npm to orchestrate supply chain attacks with significant downstream impact. Incidents such as the 2025 Shai-Hulud npm campaign, the XZ Utils backdoor, and the widespread compromise of over 23,000 GitHub repositories illustrate how open-source malware has quickly become a critical, top-tier threat built to evade legacy scanning and exploit trust woven into modern delivery pipelines. "--The shifting tactics of threat actors targeting npm, PyPi, GitHub, and development pipelines "--Key differences between open-source malware and traditional malware or vulnerabilities "--The most prevalent malware types and tactics driving today's software supply chain attacks "After spending 20 years in software development, Bryan started his journey into Application Security in 2015 with the AppScan tool suite for Static, Dynamic and Mobile Application Security Testing. In 2018, he expanded his Cybersecurity proficiency, earning the Certified Information Systems Security Professional (CISSP). In 2019, he was excited to join Sonatype due to the explosive growth of open-source software, which has made Software Composition Analysis (SCA) a critical aspect of Application Security". See you there! Happy Testing ## Speaker Available for a React Native Mobile Testing Framework Talk DevFeed: [Speaker Available for a React Native Mobile Testing Framework Talk]() Original publisher: [Read original article]() Author: T.J. Maher (noreply@blogger.com) Published: 2026-05-30T00:22:04Z Content type: article Language: en Sources: [T.J. Maher]() Topics: [Mobile Testing](), [React Native](), [TypeScript](), [Automation]() Tags: [automation](), [meetup](), [mobile-testing](), [react-native](), [testing](), [typescript]() ### AI overview The author is seeking opportunities to volunteer a presentation on building a React mobile automated test framework using Detox and TypeScript for software testing meetups. ### Source excerpt Are any software testing Meetups looking for a speaker? I have a talk, all ready to go! After surviving the first round of layoffs last December, I scrambled to organize my research notes on building a mobile automation framework into a presentation. I managed to finish it days before I was hit by the second round of layoffs at the end of this January. So far, I have given my presentation, Building a React Mobile Automated Test Framework Using Detox + TypeScript to: TestGuild.com Automation Guild 2026 via Zoom (4/6/2026) Software Quality Group of New England ( SQGNE ) @ SCRUM.org, Burlington, MA - https://tinyurl.com/detox-demo-sqgne (5/20/2026) Sydney Testers Meetup via Zoom (scheduled on 6/30/2026) Two Questions: If I give a talk to a software testing Meetup in Australia via Zoom, even though I never left my home office in Massachusetts, would I be considered an "International Speaker"? Does anyone else want me to volunteer to speak at their software testing meetup? The SQGNE season is ending for the summer, so I will have some time available. Happy Testing! -T.J. Maher Software Engineer in Test BlueSky | YouTube | LinkedIn | Articles ## Practicing Playwright: API Testing, Intercepting Network Requests, and Mocking APIs DevFeed: [Practicing Playwright: API Testing, Intercepting Network Requests, and Mocking APIs]() Original publisher: [Read original article]() Author: T.J. Maher (noreply@blogger.com) Published: 2026-05-28T02:20:30Z Content type: tutorial Language: en Sources: [T.J. Maher]() Topics: [Playwright](), [Testing](), [API](), [Mocking](), [Network]() Tags: [api](), [api-testing](), [browser](), [guide](), [mocking](), [network](), [playwright](), [testing]() ### AI overview A practical tutorial on Playwright API testing using page.route to intercept, modify, abort, fetch, and mock network requests. It examines tests for the PracticeSoftwareTesting.com shopping cart and shows how API data can support UI assertions. ### Source excerpt How would you intercept a network request and use the data for assertions? Mock a network request using those assertions? And make sure that all data is loaded in the UI before making your assertions, and that all tests can pass when run? We will be walking through Butch Mayhew's code that answers all of these questions, part of his LinkedIn Learning course: Playwright Essential Training. We will be examining the shopping cart test site PracticeSoftwareTesting.com and looking at code on Butch's companion GitHub site on how to mock out the API and use them in the UI tests. Playwright has a lot of features when it comes to API testing. You can intercept network requests, aborting, modifying, and mocking network requests. You can also simulate a slow network. This is all done through the Playwright methods: page.route. A route is the specific path or URL a client uses to request data or trigger a function on a server. GET /product would be an API call that gets everything from the address string called products, which then retrieves all products from the API endpoint called "products". The endpoint is "products" and the route is the name that accesses the endpoint. The Playwright API has a method called route, which allows Playwright to monitor and modify browser network traffic. Playwright.dev / Docs / Network: https://playwright.dev/docs/network Playwright and page.route: https://playwright.dev/docs/api/class-route Playwright Mocking API Guide: https://playwright.dev/docs/mock Adding page.route to your test allows you to do things such as: abort the route request with route.abort(), simulating various error codes such as accessdenied, addressunreachable, blockedbyclient, blockedbyresponse, connection aborted, connectionclosed, timedout, etc. continue sending the route's request with optional overrides such as changing the request URL, the headers, the method such as GET or POST, and the post data of the request. fetch the request without yet fulfilling it, so the res ## Practicing Playwright: Visual Testing With Playwright DevFeed: [Practicing Playwright: Visual Testing With Playwright]() Original publisher: [Read original article]() Author: T.J. Maher (noreply@blogger.com) Published: 2026-05-21T12:46:54Z Content type: tutorial Language: en Sources: [T.J. Maher]() Topics: [Playwright](), [Testing](), [Docker](), [ci](), [WebKit](), [Chrome](), [Firefox]() Tags: [chrome](), [ci](), [docker](), [firefox](), [playwright](), [snapshots](), [software-testing](), [testing](), [visual-testing]() ### AI overview This tutorial demonstrates Playwright visual testing by capturing screenshots of pages or elements, comparing them with baseline snapshots, and using masking to exclude changing content. It also discusses browser and operating-system differences, repository size, and running visual tests in a standardized CI environment. ### Source excerpt If you want to do some basic visual checking to see if there has been any deviation from your baseline of images, you can use Playwright. It's built in! Playwright can take a snapshot of a web element, a visible viewport, or a full page, and save it in your Git repository as a baseline, failing the test if the image, page, or viewport does not match up. Caution: From what I have been reading, this can quickly cause your code repository to balloon in size, since Chrome, Firefox, and WebKit would each store its own golden screenshot in your repo. Also, images on Mac, Windows, and Linux all appear different pixel-by-pixel. If using a CI platform, it might be best to run visual tests only on a standard Playwright Docker image, to generate and compare snapshots. According to TestQuality, "Once a suite passes 50-100 visual tests, teams need a layer that tracks run history, surfaces flaky-test patterns across cycles, and routes confirmed defects into the team's tracker -- none of which lives inside the test runner itself"... I wonder if you can store images in an Amazon S3 bucket and hook that up as a virtual drive? ... no matter. That will be a blog post for another time... Right now, we will be walking through Butch Mayhew's code he wrote for his LinkedIn Learning course, Learning Playwright, found on his companion GitHub site. While the test is in a certain state you can a screenshot of the page or certain elements of the page and save them as a snapshot. The snapshots an be used as a baseline images to compare your current site against. This baseline can be periodically updated as the site evolves. How does this happen? With Playwright's .toHaveScreenshot( ) to take a screenshot and the mask method that you want to leave out of the comparisons between the expected and actual screenshots. toHaveScreenshot(name): Playwright.dev / Page Assertions Our Test Site: PracticeSoftwareTesting.com Butch has a series of tests for the test site Practice Software Testing ( practicesof [Next page]()