Quality Assurance is somewhat of an unsung hero in the tech world. It’s also something that everyone has a little experience with.
When you first learn to write, you are told to write a first draft and have someone else look at it for you. When they proofread it and hand it back to you with suggestions or notes, that’s QA. If you ask someone to check your work in math class, that’s QA. You are asking someone to assure you of the quality of your work, hence Quality Assurance. Doximity constantly reminds me of how important the job of a QA Engineer is -- and how valued each one of us is. Working at Doximity has helped me to identify three major goals for a QA Engineer to always strive for.
My first goal as a QA Engineer is to break everything I possibly can.
That’s the rule I personally live by when I’m testing a new project. Sure, navigating the easy path where everything works is necessary, but if that was all that was needed, then there would be no need for QA. The best part about it is sitting down with a new pull request (the actual code I deploy to a testing environment) and just banging away at it with a hammer, figuratively of course. Pretty soon the bugs start to appear and I have a list of issues to report to the developer. This is not limited just to new projects. This first goal is also a part of exploratory testing. If I have a few minutes in between projects, or even when I have free time on the weekends, I will hunt for bugs on our website and note any down.
Even if they look minor, I will always make a note of the issues and bring them to the Engineering team as soon as I can.
When I first started working in QA at Doximity, I was worried I was wasting someone’s time when I brought them every bug I found. During my first year, an engineer and I were working with an old version of Internet Explorer. This version was no longer supported by Microsoft, but quite a few of our users continued to use it. I came to the engineer I was working with a list of bugs I found performing common tasks on our website. The engineer, who started around the same time as me, was devastated by all of them. He spent quite a few hours resolving each and every one. But I did what I had to do -- break things and show them the shattered pieces afterward!
My second goal as a QA Engineer is to effectively explain how I break everything I possibly can.
What good is it if you go to someone and say, “This is broken” and then walk away? I used to work in a call center on the Help Desk team before I moved to QA. I very quickly learned there that in order to resolve an issue, I needed to know how to recreate it perfectly. Someone would call in or send an email that just said, “It is not working,” and that was it. I had to ask them questions to find out what was broken, how it was broken, and where it was broken. It caused major delays in getting an issue fixed. This is a reason why someone who works on a help desk can make such a great QA Engineer; they know they how important it is to walk someone through the steps they took to reach an issue.
When I go back to the engineers with a list of bugs I found in a new PR (aggregated list of code changes), I give them the exact steps to recreate them. Oftentimes, this goes a long way to show a really weird issue. Having these steps to reproduce a bug helps the engineer identify when and how the issue happened, and helps them pinpoint where it’s happening in the code. This greatly speeds up a fix and helps keep PRs moving towards production. And, believe me, I find a LOT of weird issues in QA -- enough that I have heard the phrase, “Andrew, this will only happen to YOU” more than once.
I have even been jokingly accused of tampering with code with the reason being, “How else could this have happened?” This happens because developing versus testing are two vastly different thought processes. I work with one engineer in particular whose chat log shows the phrase: “Can you come help me reproduce this bug?” in nearly every conversation with me. Even though I take care to document each one, some bugs are still strange enough that he will need to see them happen in real time.
My third and final goal as a QA Engineer is to make sure everything I am testing works
What I mean by this is once I finish all of my testing and have found every bug I think there is (and there are always more), I have to make sure it works.
- Run through that happy path
- Go through the one that created all the original bugs
- See if the new fixes caused new bugs to appear.
Just make sure it all works from every angle I can approach it from before I approve it. Then, finally, let them know it is ready to go! Once deployed, a QA Engineer needs to repeat this third goal one more time, just to make sure everything looks fine on production as well.
And guess what? Even then, you’re going to discover new bugs on production. Just recently, I was working on a new project and found everything was working perfectly. You could navigate from page to page, you could add new colleagues, everything was great. The code was deployed, I was able to add a new user as a colleague, but then I found that if I attempted to visit a profile… I was redirected to the homepage.
I thought to myself, “Surely, I must have clicked on something else by mistake” and repeated the steps multiple times. But, each time I ran into the same result. I immediately contacted the engineer I had been working with and reported the issue to them, and we found another change had gone out not too long before which caused this to happen. Thankfully, my last round of testing identified the issue, and we were able to fix it quickly.
These are just three goals I find very important for a QA Engineer to reach for, and they are the first three I found myself working towards immediately after I started working at Doximity. Even when there is a major change in how I test or there is a process change at the company, these three are still a major part of my personal process. They have greatly assisted me in gaining the trust and respect I have as a key member of the QA team, and they are the three pieces of advice I pass on to others whenever I am asked about my job.
Be sure to follow @doximity_tech if you'd like to be notified about new blog posts.
