Test Automation Engineer

About me

I am a test engineer who has transitioned from manual to creating automation frameworks for various complex web based content management systems. I have worked in a number of different industries across various platform types and environments, from embedded systems to more frontend focused websites.

Checkout my github here: https://github.com/jfp1992 it shows my python development periodically from the start (project ‘compare monolith options’) to the more current testing appium project.

Here is a downloadable zip of various testing examples with code: https://drive.google.com/file/d/11QkVgUtKOjTKVNxn83L5Z43a4V4yAyOH/view?usp=sharing

Primary Tech Stack – Most experience with

Python

I chose python because I found it to be the most compatible with CI/CD and is the most accessible when it comes to learning the language, producing tests and creating tooling.

Playwright

Playwright is microsofts fork of google’s puppeteer. I have found it to be extremely reliable and due to the trace viewer it removes the need for traditional detailed bug reports when issues are found via automation; that is why it is my first choice.

Git

I chose git because – just kidding. As with any software project, version control is important. I have used a few platforms: Bitbucket, gitlab, github and azure devops.

Selenium

I started with selenium, it is powerful although is showing it’s age. Writing reliable web automations are a challege and there is a strong need for a wrapper and many other tools to get selenium to behave properly. Issue visibility has to be programmed in.


Secondary Languages

For the following languages below, I setup their respective environments and created 6 tests for a login form (which I originally created in python with playwright) to evaluate the other supported languages for playwright.

TypeScript

The setup and running of TypeScript/JavasScript tests was pretty straight forward. The main downside for me was having to add the await keyword before each command and the additional syntax overhead which adds time to test creation. However, the learning curve doesn’t appear to be much more than it would be with python.

C#

The environment for C# was easy to setup; due to the heavier syntax, public and private variables and the statically type nature of the language, it was a bit more of a challenge. Running the tests with NUnit was straight forward.

Java

I found the Java language to be more of a challenge in comparison to C# due to everything being a class albeit minor. The tests were almost a copy and paste from C# with minor syntax tweaks. It was probably my least favourite to work with in terms of setting up, coding and running tests, but was still interesting.

Secondary Tools

Appium

I have spent a day learning how to setup a virtual android device and connect to it with the Appium server subseqeuently 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

Cypress

Due to many companies requesting cypress experience, I decided to convert over a front-end web tech test I did for an application, from playwright to cypress. I found it quite difficult to work with for the page object model as it looks for the element before appending any actions to the attribute. It was also quite poor when it came to chaining locators and the performance was also lacking.