New Playwright Course: Playwright Essential Training by Butch Mayhew

Butch Mayhew, Playwright Ambassador and author of the LinkedIn Learning course, Learning Playwright, has just released a companion course, Playwright Essential Training: Abstractions, Fixtures and Complex Scenarios. 

Where Learning Playwright covered how to install Playwright, create simple functional, AI, and visual tests, how to maintain tests and how to scale them, Playwright Essential Training dives a lot deeper. It goes over topics such as:

• How do you set up page objects in Playwright?
• What does test data management look like?
• How do you mock out test data?
• How do you deal with tricky components such as alerts, dialog boxes, and multiple windows?

Thank you very much, Butch! Looking forward to taking the course!

Happy Testing!

Practicing Playwright:

• Part One: Time to Practice Playwright!
• Part Two: New Playwright Course: Playwright Essential Training by Butch Mayhew
• Part Three: Hands on Automated Testing with Playwright by Butch Mayhew is the start of a wonderful conversation with the Playwright community!
• Part Four: What happens when you pair Playwright with something other than TypeScript?
• Part Five: Logging in by Storing and Using an Authentication Cookie in Your Automated Tests
• Part Six: How to Detect Broken Images On Your Site
• Part Seven: Dynamically Creating Test Data with a DataFactory
• Part Eight: Visual Testing With Playwright
• Part Nine: API Testing, Intercepting Network Requests, and Mocking APIs
• Source Code: https://github.com/tjmaher/practicing-playwright

-T.J. Maher
Software Engineer in Test

BlueSky | YouTube | LinkedIn | Articles

Time to Practice Playwright!

Back job searching again? Time to learn a new automation toolset!

Thank you, Butch Mayhew for your course, Learning Playwright on LinkedIn Learning.

Playwright was launched back in January 2020, by Google Puppeteer developers who took what they learned to build a new automation framework for Microsoft. According to the Playwright Doc, "Getting Started", "Playwright Test was created specifically to accommodate the needs of end-to-end testing. Playwright supports all modern rendering engines including Chromium, WebKit, and Firefox. Test on Windows, Linux, and macOS, locally or on CI, headless or headed with native mobile emulation of Google Chrome for Android and Mobile Safari".

Related Links:

• GitHub: https://github.com/microsoft/playwright
• NPM: https://www.npmjs.com/package/playwright
• Documentation: https://playwright.dev/docs/intro 

So far, I am halfway though Learning Playwright. I am really loving how the course has it's own GitHub repo, with each chapter has its own branch. Students can practice building out a Playwright framework, chapter by chapter, typing out the code themselves -- the best way to learn. And if the student feels like skipping that exercise they can just pull the next branch lesson to their local machine.

Butch included a Resources File which walks through things like:

• Learning Playwright
• Node Prebuilt Installer
• Installing VS Code
• Playwright Test for VS Code

The Resources File also covers: Updating The Playwright Config, Configuring Browsers, Exploring The Test Runner Command Line Interface, Exploring the VS Code Extension, Exploring Playwright UI Mode, Generating Tests With Codegen, Overview of Assertions in Playwright, Handling Cookie Authentication in Playwright, Visual Testing in Playwright, API Testing in Playwright. It also covers using  Playwright Screenshots, Videos, and Reporters, the Playwright Trace Viewer, and Scaling Playwright Tests.

Butch, a Playwright Ambassador, also has a related site, Playwright Solutions. 

Four years ago, it was Ruby that was in demand, an easier language for manual testers to pick up. I was able to go from an SDET position using Ruby + Capybara to an SDET position using Ruby + Watir. Now, it seems everyone is looking for Playwright + TypeScript... which I do not have any experience in.

Looks like I need to take a few more courses, then practice putting together some Playwright frameworks, blogging here about my Adventures in Automation.

Happy Testing!

Practicing Playwright:

• Part One: Time to Practice Playwright!
• Part Two: New Playwright Course: Playwright Essential Training by Butch Mayhew
• Part Three: Hands on Automated Testing with Playwright by Butch Mayhew is the start of a wonderful conversation with the Playwright community!
• Part Four: What happens when you pair Playwright with something other than TypeScript?
• Part Five: Logging in by Storing and Using an Authentication Cookie in Your Automated Tests
• Part Six: How to Detect Broken Images On Your Site
• Part Seven: Dynamically Creating Test Data with a DataFactory
• Part Eight: Visual Testing With Playwright
• Part Nine: API Testing, Intercepting Network Requests, and Mocking APIs
• Source Code: https://github.com/tjmaher/practicing-playwright

-T.J. Maher
Software Engineer in Test

BlueSky | YouTube | LinkedIn | Articles

Test Guild: Building a Career in QA with Judy Mosley

I absolutely loved this week's episode of Joe Colantonio's Test Guild, Building a Career in QA with Judy Mosley.  

This week, Joe interviews Judy Mosley, a QA Engineer of seven years who shares the fun and excitement of testing, discovering the field after attending a web development bootcamp. Anyone who is a tester should listen to it.

I also love her blog, "Failure is Feedback", where she elaborates on her story with the entry "Quality Insight: Why 🫵 Should Share Your Career Journey".

... It's so hard keeping up with a blog. It was easier when I was at ThreatStack, writing official articles on the company website about how I was testing software there. While at MassMutual, I was putting my energy writing internal Confluence documentation on how to to install and run the framework I was building, and less on this blog.  

Thank you so much, Judy for sharing your story!

So, are you a software tester? Have a blog of yours to share? Leave a link in the comments below!


Happy Testing!

-T.J. Maher
Software Engineer in Test

BlueSky | YouTube | LinkedIn | Articles

When building out automation frameworks, keep the stakeholders in mind

When building out an automation framework, I always try to keep the wants and needs of the stakeholders in mind.

Business analysts want to know if we have tested the product against the business requirements.

QA Managers want easy-to-read reports that spell out what is passing and what is failing at a glance.

Developers may want to check for sporadic errors that randomly pop up.

Testers want to have regression tests automated so they can focus on testing the new features... and may want a library of building blocks so they can put together their own tests.

A prioritized backlog of automation JIRA tasks keeps everything on track, and end-of-sprint demos gives the dev team a chance to chart the progress and tweak what they see.

Being embedded in a development team, I can build and customize an automation framework, one two-week Agile sprint at a time.

Happy Testing!

-T.J. Maher
Software Engineer in Test

BlueSky | YouTube | LinkedIn | Articles

How automation recaptures the magic of testing

There is something magical that first time a software tester explores a web application.

A head full of questions, they fire up their favorite browser and try to figure out how how the app works. How the app behaves when you enter unacceptable parameters. How the app performs under stress. And they will happily take notes about their discoveries as they test their own assumptions how it should work until their curiosity is satiated.

Every subsequent time they view that same app, some of that magic is lost. The unfamiliar becomes the familiar becomes the routine which becomes boredom.

That is where I come in. "My job is to make your job easier", I always say to our test lead, John Jurek.

What is imperative that needs to work before we begin testing? Make that a smoke test.

What test script is so mind-numbingly boring to manually execute? Let's add that to the backlog of regression tests to write.

Sure, it might be fun to run a test once or twice, but once you run a test seeing how one part of a feature behaves in Chrome, Firefox, Safari, Microsoft Edge, and all the little mobile widths a responsive web application can have, the fun slowly disappears.

Keep the testers focused on testing new features. Farm out to the automated tests the rest. That helps keep the magic of testing alive.

... And once you have an automated framework stood up that fits the needs of the development team, you can start training the testers on writing their own automation to investigate the web app.

Happy Testing!

-T.J. Maher
Software Engineer in Test

BlueSky | YouTube | LinkedIn | Articles

Need a SDET with 10 years experience for a Remote / Hybrid position in Boston?

My development team and I at MassMutual were all just given notice that our last day would be July 11, 2025. Anybody looking for a Software Developer in Test with ten years of experience? 

I've been trying to sum up what I have been doing for almost four years at MassMutual. How does this sound?

MassMutual - Boston                                    Sept 2021 - July 11, 2025

• Shaped automated test suite to the wants and needs of the stakeholders on the Payment Experience team. Drafted UI + API positive and negative tests written against reviewed business requirements of new Billing & Payments features being developed that sprint. New and existing smoke and regression tests were executed in the developers feature branch, testing their code before it was ever deployed to the DEV or QA environment. 
• Designed browser tests in Cucumber GIVEN / WHEN / THEN format so user data was reset to the correct state using MassMutual APIs before the browser ever opened: Pending payments cleared, Premium and Loan AutoPays turned off, and Billing & Payment API was 200 OK. 
• Created UI and API tests in Ruby, Watir, Applitools, to be run on the DEV + QA environments through Jenkins jobs running daily smoke test and weekly regression tests. BrowserStack + LambdaTest, Chrome, Firefox, Safari, MS Edge, Chrome Mobile, Android and iOS. 
• Triaged daily smoke test run to determine the health of the environment before testing.
• Mentored manual testers in writing automation code, tailoring the README and Confluence documentation to their learning needs, whether setting up their local environment running the smoke + regression suite, or how to use the automation steps drafted in Cucumber/ Gherkin.

Happy Testing!

-T.J. Maher
Software Engineer in Test

Twitter | YouTube | LinkedIn | Articles

Stepping down from being a Meetup Organizer of Ministry of Testing - Boston

Today is a hard day. I just stepped down from being a Meetup Organizer of the Ministry of Testing - Boston. Life has been so busy the past year, I haven't even been able to host even a virtual Lunchtime Discussion.

I first encountered Conrad Holloman's Greater Boston QA and Testing Meetup when he hosted a Meetup event back in 2016 when Fitbit - Boston, where I was a budding automation developer. Before I knew it, I was organizing events, volunteering to be on discussion panels, and giving presentations to the group. When Conrad moved the Meetup under the Ministry of Testing banner at the end of that year, he encouraged me to take over as organizer.

As Meetup Organizer, I have had so much fun recruiting speakers such as Angie Jones, Seb Rose, Matt Wynne, Lisa Crispin, Moshe Milman, Eran Kinsbruner. Thank you so much, SmartBear and Mabl for always hosting us!

Everything came to a halt due to Covid. I tried switching to virtual Meetup events in 2022 for this group, but that came to a halt when my kiddo was diagnosed with ADHD + Autism. All of my time and energy from that time forward has went to my family, shuttling my son to new schools and doctor appointments, and it hasn't let up.

I have really enjoyed being a Meetup Organizer! It has been a thrilling ride!

-T.J. Maher

MassMutual Boston, Software Engineer in Test
Meetup Organizer, Ministry of Testing - Boston

Twitter | YouTube | LinkedIn | Articles

The Cheezy Internet: Composing tests using Cucumber and Gherkin

This is fourth in a series of blog posts. Care to go back to the beginning?

Following along with Jeff "Cheezy" Morgan's eBook, "Cucumber and Cheese: A Tester's Workshop" (2017), after setting up a development environment, we started creating in Ruby + Watir the basic building blocks for an automated test framework, as we saw in the last Adventures in Automation blog entry. 

Instead of going into great detail testing against the complex test site Jeff uses in Chapter 4: Cucumbers and Puppies of is book, with Sally's Puppy Adoption Agency, we are using the simpler test site, The-Internet https://the-internet.herokuapp.com/login, by Dave Haeffner. 

This blog post will explore scaffolding a site and composing acceptance tests using Cucumber and Gherkin. 

Scaffolding a Site Using TestGen

It's always a challenge for me when creating a new project to figure out where everything should go. What should the folder and file structure be? Luckily, Jeff Morgan created a Ruby gem called "testgen" which solves all of these problems. 

• Change the directory to the src folder in your home directory: cd ~/src
• Pick a name for your project, such as "cheezy_internet"
• Install Jeff Morgan's Ruby gem testgen on your local machine: gem install testgen 
• Use the Ruby gem testgen to create a new file hierarchy: testgen project cheezy_internet 

The Cheezy Internet: Writing Ruby + Watir tests for The-Internet

This is third in a series of blog posts. Care to go back to the beginning?

Last blog entry, based on Jeff "Cheezy" Morgan's LeanPub book, "Cucumbers and Cheese: A Tester's Workshop", we set up our local machine, wrote and executed our first Watir program. 

Based on his book, we are going to attempt to sketch out and write our first test against Dave Haeffner's sample login page on The-Internet at https://the-internet.herokuapp.com/login.

The-Internet / Login Page

Drafting a Test 

A sample test for The-Internet / Login could be:

• Go to https://the-internet.herokuapp.com/login
• Enter tomsmith into the username textbox.
• Enter SuperSecretPassword! into the password textbox. 
• Press the Login button. 
• If the Secure Area page does not show "'Welcome to the Secure Area", fail the test.

The Cheezy Internet: Installing Ruby + Watir + Chromedriver + VS Code on Windows 10

This is second in a series of blog posts. Care to go back to the beginning?

For this exercise, we will be setting up a Windows 10 box for use as a development machine.

Macbooks are amazing machines. I love coding on them. Using the Mac Terminal in Homebrew. Dressing them up with decals, such as the glasses-and-tie decal my wife bought for my very first work laptop back at Fitbit-Boston.

Love dressing up the Apple logo!

I definitely would not recommend using your work machine, if you have one, for anything but work and work-related activities. 

The problem is that when it comes to non-work related programming activities, it can leave for me, well, less glamourous and sparkly alternatives.  

My home computer always has been a Windows Desktop, a big ole workhorse to store the family photos and videos, ancient video games like the original StarCraft, old blog posts, articles, and essays. But they can be so hard to set up sometimes with the toolsets I need to put together an automation framework. 

Based on the information in Jeff "Cheezy" Morgan's LeanPub book, "Cucumbers and Cheese: A Tester's Workshop" (2017), we will start setting up our local machine.