Peeking Behind the Scenes: Benefits to Transitioning from Helpdesk to Quality Assurance

I have always been a person who loves puzzles: jigsaw, matching, crossword, sudoku, you name it. If it makes me think, I’m in! When I was presented with the opportunity to become a Quality Assurance tester (QA) I was ecstatic. And the transition process was one that I was eager to hop into.? Mainly because I didn’t need to learn everything from scratch coming from the helpdesk and I had a broad understanding of how our users think.

I joined the helpdesk team for our system back in 2019, but before that I was a regular user of the interface since 2015. For four years I was an active user and would touch several pieces of the functionality, not knowing that one day I would be assisting with the implementation of changes or fixes to it. At that time, I had my complaints about the interface and so did my colleagues. I remember thinking how much easier a process could be if only there were a “Close All” button here, or an “Auto populate” option there. There were times when the functionality I hoped for did exist, but as a new user, I was not aware of the process to get there. I kept those tips and tricks in my back pocket for future reference and carried on. On slow days, I would click around with my limited access and see what else the system was used for just to kill time. But at that time, I was only a user, and as they say, it was what it was.

Once the monotony of that position hit and I was ready for a change, I was presented with the opportunity to join the helpdesk for the interface I had used for the last four years. I jumped at the opportunity because not only would it be a change to my daily work routine, but it would be for a system in which I was already experienced. When I got started, my new manager (who was once my old manager) gave me the run down of what most of my tickets would look like: terminating active user sessions and resetting passwords. She knew what functionality I already knew about with my previous experience, and she showed me the pieces I had never touched before. To say I was overwhelmed was an understatement. Here I was thinking I had a huge grasp on the entire system only to find out that what I knew was just a small chunk of a huge process. But I put on my big girl pants and committed as much as I could to memory.

Over the next two years, I would reset passwords and terminate sessions, but every now and then, there would be a user who would email or call in because they found themselves in a doozy of a situation. With the help of our handy dandy staging environment, I would dive in to see if I could reproduce the issue. Of course, there were some that I could not figure out for the life of me and had to escalate. But the ones that I could figure out, I would have a personal victory party. Every time I thought, “This has to be the craziest scenario I have ever seen,” another user would reach out with an even crazier one! I grew to enjoy those scenarios because they felt like my own little mysteries waiting to be solved. Over time, I began to develop a feel for the way our users would interact with the system on their own and shift my answers to their inquiries based on their logic.

Two years passed and once again I was starting to feel that itch for a change. Not to mention, we were also in a full-blown pandemic and my work days narrowed down to unlocking accounts and staring contests with my dog. After reaching out to the higher ups, we began to discuss what a change within the company looked like for me. I went back to my love of puzzles and figuring out the root to the bizarre scenarios. Together, we settled on software testing. And just like that, with the perfect QA to shadow, my journey began!

Upon my introduction into this role, the phrase “we’re trying to break the system” was drilled into my head. While there were other tried and true methods that the QA team already had to go about this, I had my experience with users finding bugs and messing with the system in odd ways that allowed me to “break the system” in different ways. If we were fixing a bug one way and received a set of steps to reproduce that bug, I could recall the times our users would get to that page in some strange way and use those as extra scenarios. If they passed, then hooray! If it did break, I would add that to the victory party list.

In typical Agile fashion, our Dev team will pass user stories along to the QA team. When I find an issue and speak with the developer who worked on my ticket, we realize that the issue was found because the way we thought about the issue was completely different. They thought about it by looking at the code and manipulating data from the back end. I was looking at it through the eyes of a user on the interface clicking buttons and navigating through pages in the way I’ve done and seen. Often these will be caught before they are passed onto me. However, in those moments when we have that disconnect, that previous user experience comes in handy.

Another process that is a part of the agile pipeline is backlog refinement, where our business analysts present the new defects and change requests and the QAs and developers can chime in with our questions and thoughts. Occasionally, I will chime in with a “Question: but what if insert bizarre scenario I remember from helpdesk happens?” Sometimes, these scenarios are already covered (which is a testament to our amazing BAs), and other times it may spark a conversation because no one thought of it as a possibility. And with our users, absolutely anything is a possibility.

In the IT field, many who want to get their foot in the door will begin with some sort of tech support or helpdesk role. For beginners, this is a great opportunity for learning as much as possible. Not only does it involve understanding user interaction; it also fosters a relationship with the technical team members. This relationship allows a space where information is openly shared and guidance is willingly provided. In these instances, what may have started as a simple question about button placement can turn into an in-depth look at the code behind it all or different testing methods surrounding an entire page. Before you know it, those relationships and lessons can torpedo into a brand new interest and career path. However, those interactions and lessons learned at the time should not be taken for granted, as they can be invaluable in the future. ??

While I never saw myself becoming a QA, I am very glad I was given the chance to try as I have grown to love it! It keeps me away from the monotony that I dread and allows me to really think about different processes while I tap into those hidden gems from my helpdesk days. As of late, I have been learning to view each professional experience as a learning experience. In the moment, what may seem particularly mundane may just be the underrated factor that can propel you forward in the best way possible.