I am working on earning my SDET title - and have made some progress. I'm slowly catching up on the manual tests that we need and starting some automation. One thing that is slowing me down is there are no records of requirements for many of the features of the application, so I'm diving into legacy code, teasing out what should happen "if". Some of them are obvious - if you try and log in with a correct account, you should be given access at that level. But very few are this simple, and planning for tests and time with people who have helped the system grow into the way it is has been a challenge all by itself. The first automation I wrote checks the log in page - a simple task. There had been recent changes, but the tests have finally been code-reviewed to be placed into the pipeline. Still reeling from this, I started the next series of tests. These were more challenging: the page that any user would open after logging in. I have been discovering Playwright, and te
https://www.pexels.com/photo/white-and-brown-cat-lying-beside-a-laptop-and-toys-5468268/ Photo by Karolina Grabowska from Pexels Working with developer- focused tools can be a challenge for some testers: we may know what the words mean, but haven't used those skills recently enough to make the tasks simple. Or we may not have ever used them, other than at a quick glance to make sure that what we are getting matches what it should be sending. And some give results that require us to go find another team member to help interpret the results. Being a more-independent tester has always been one of my goals - being able to use the tools that are common in the team, and be able to do at least basic tasks that support my tests with them. Our team used Postman for many of the API tasks that we had, so exploring this tool was a natural fit. There are alternatives it there, both graphical and command line, so feel free to explore! The items that you can do, and tools that help