In 2012 I learned a lesson I'll never forget.
I was working at The FT and actively struggling to test our integration with a content delivery network (CDN). It looked like we would have to do a lot of checking via the front end in the browser. Open a page in one browser, check the contents, then open the same page from another but served from a different environment and see if they were the same.
Not the most exciting prospect in the world!
Until one day, I met with one of the solution architects. He used to do his work on one of those old netbook things! But he'd installed Linux on his. He was a total legend!
When I told him what we needed to test and how laborious and lame it sounded, he came up with a brilliant idea!
He said he could use his little netbook thingy to create a bash script. This script would use curl to grab the contents of a page from prod, then grab the same page from our test environment, pipe the contents of each request into a couple of files, diff the files, then pipe the instances where they were different into yet another file.
Then all we'd have to do is eyeball the contents to see what caused the difference.
What's the point of the story?
I want you to remember that test automation doesn't always have to mean testing in the front end of a web page using a tool like Selenium or Cypress!
Get clear on what you need to learn about your product, then leverage the experience of your teammates to come up with the most effective approach rather than reaching for the same familiar tools.
Think "Automation in Testing" rather than "Test automation".