Skip to main content

Posts

Redefining my Role

Confession: I am a nice person. I'm the one that will check on people - and be concerned if someone is acting off. Or donate money to make sure the potluck I can't attend has everything it needs. This has had an effect on my career: I was less willing to point out 'in public' errors in the code or things that just felt off to me while testing. And this stopped me from being the best tester I could be. Trying to be kind to someone that was having a rough patch, or simply not wanting to expose them to a potential attack was both me trying to get things correct, but care for them. I've decided to embrace this aspect of myself, and shift my focus. Being 'nice' to the product, or company must include being the voice for both end users and the team. Finding things that will be difficult for them, confusing, or flat-out wrong is a major part of my job. And this was also one reason I don't 'delight', at first, when something doesn't work as expected:
Recent posts

Drop-down values for injection

cover_image: https://www.pexels.com/photo/flat-lay-photography-of-gold-iphone-on-opened-notebook-beside-pen-583847/ canonical_url:  --- Photo by Jessica Lewis 🦋 thepaintedsquare   Learning in public is grand, and when you have a team that is willing to help with something that seems simple, but you fall into overthink for the wrong items, it can really help to type out your thoughts, actions, and what the program does to frustrate you. And in this case, getting a value I could see in the debugger was the issue The automation needs to check for page elements – and the drop-down selector triggers potentially different elements. Plus, depending on the user logged in, there may well be different options available in that drop-down. Then, I can get the options available for the user on the drop down, get their values, cycle through them, and verify each set of elements on the page. My test account for this has four options on the drop-down, so I budgeted a couple of hours to get each step

Compare HTML in Playwright .NET

Photo by Miguel Á. Padriñán: https://www.pexels.com/photo/four-letter-tiles-1591061/ Photo by Miguel Á. Padriñán: https://www.pexels.com/photo/four-letter-tiles-1591061/ Photo by Miguel Á. Padriñán: https://www.pexels.com/photo/four-letter-tiles-1591061/ Photo by Miguel Á. Padriñán: https://www.pexels.com/photo/four-letter-tiles-1591061/ Photo by Miguel Á. Padriñán: https://www.pexels.com/photo/four-letter-tiles-1591061/ Photo by Miguel Á. Padriñán: https://www.pexels.com/photo/four-letter-tiles-1591061/ Automating checking text (and its HTML) can be a challenge if you aren't comfortable with the language and framework you are using. Having a limited time for learning and exploring is its own challenge. One of my tasks for automating a smoke test for our project was to verify the text in each environment, with each specific set-up having its own welcoming message. And, I admit, I wasn't quite sure where to start. I knew what I needed, and found out where to fetch it. But gett

Bitten By Async

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

30 Days of Postman - for Testers!

  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

Getting to Explore: WSL2!

https://www.pexels.com/photo/black-and-white-laptop-2740956/ Photo by Prateek Katyal from Pexels   Working on a graphical interface system is a delight, but every once in a while, I want to return to the command line style of computing - it's fast, and can have impressive results for a system. Even before Windows came up with a full subsystem, having a virtual machine and a Linux terminal for using some things wasn't uncommon.Thankfully, the Windows Subsystem for Linux (WSL) now exists, and is mature enough to handle most things. And once I experienced this style of computing, and the knowledge that most things were as simple to do with command-line terminals, I want to go back to the command line often.  But being invited to see how much use replay.io would be for a tester helped make this choice easy. Not only did I get a chance to return to a method I enjoy, but a new tool that could help communication between team members. And, now that I think about it, with stakeholder

Where Is It? Part 1 - Inputs

Photo by Pixabay from Pexels     I am job-searching, and running into some coding challenges. Most of them are simple - some seem to want one-line solutions that require two cups of coffee and a half-hour to figure out what they want. Others are far above where my skills lie, and these I give a try for, and learn. And then there are the ones that offer, seemingly randomly, a challenge - within my skills (or at least my research skills) - that could be used as part of a larger project that I want to work on. This was the case last week, when I tried for a position that was a bit above what I felt I could do comfortably. The challenge was to let someone enter items, and then give back their location. In a language I am just familiar enough to be a danger to myself in. Happily, and thinking forward about how I could use this as a part of a larger program that would  use something like this to interact with the user. And also, this is command line, and thinking of how to set this up to