Test Automation Engineer
About me
I’m a test engineer with extensive experience building and maintaining automation for complex web-based systems. I started in manual testing and moved into designing and developing automation frameworks, with a focus on reliability, maintainability, and CI/CD integration.
I’ve worked across multiple industries and platform types, from embedded systems through to modern, frontend-heavy web applications. That range has shaped how I approach quality: understand the system first, then build automation that fits the architecture rather than forcing tools onto it.
My role today is primarily hands-on. I spend most of my time building and improving automation frameworks, increasing coverage in meaningful areas, and making test suites stable enough to be trusted in delivery pipelines. While I’ve supported and guided others, my main focus has always been doing the work and raising the technical standard of automation within the teams I’m part of.
Primary Tech Stack – Most experience with
Python
Python has been my main language for automation for years. It’s straightforward, readable, and easy to scale from small test suites to larger frameworks.
It works well in CI/CD environments and has a strong ecosystem for building supporting tools alongside tests. I use it not just for writing automation, but also for creating utilities, improving workflows, and structuring frameworks in a way that’s easy to maintain long term.
TypeScript
TypeScript integrates cleanly with Playwright. Setup is simple, and it makes sense for teams already working heavily in frontend code.
The async/await model adds some verbosity, but overall it’s predictable and easy to work with. Strong typing helps in larger projects.
Playwright
Playwright is my go-to framework for browser automation. It’s reliable out of the box and handles a lot of the common automation pain points without needing heavy custom wrappers.
The trace viewer is a big advantage over old tools like selenium, it shows exactly what happened during a run, including DOM state and network activity. That level of visibility makes debugging faster and cuts down on back-and-forth when something fails.
It supports modern web apps well, handles multiple browsers cleanly, and makes parallel execution simple. For most web projects, it covers everything I need without extra complexity.
Git
As with any software project, version control is important. I have used a few platforms: Bitbucket, gitlab, github and azure devops.
Secondary Languages
C#
I’d be comfortable writing test automation in C# however dot net isn’t what I’d recommend for frontend test automation
Java
As with C# I’d be comfortable writing test automation in Java, however it would be my last choice over the 4 supported languages for playwright
Secondary Tools
Appium
I have spent some time learning how to setup a virtual android device and connect to it with the Appium server subsequently using the Appium inspector tool. As it uses the selenium web driver, the test creation and coding aspect is the same. The code can be found here: https://github.com/jfp1992/Testing_Appium for a chess app that is heavy on the menu animations and due to the chess board being one component there is a fun work around for that too, so pieces can move.