Critical Lessons from My First Month in QA

Quality Assurance is a crucial part of the software development process. But as a novice, it can seem daunting and unclear. After all, QA is responsible for ensuring the product is ready for the masses. What if I miss something? Where do I even begin with my testing? These were questions that plagued me at first. It took a month, but eventually I found myself growing more confident in my testing abilities and the impact I could make on Hudl’s products.

Here are the biggest takeaways from my first month working in QA.

Consider All User Feedback (But Take It With a Grain of Salt)

If Hudl made a change every time a coach had an idea, our software would be a giant mess. Does that mean we don’t listen to coaches and users? Of course not! No matter how connected we are with the products we build, most of us are not coaches. Feedback is a fantastic way to see what we are doing well, as well as areas we can improve.

As a software tester, you should interact with users whenever possible. The more you understand what users need and want, the more alert you can be while testing. One of our QA mottos is: ​“Test like a coach.”

Be Prepared to Multitask

A day spent testing software includes many short periods of downtime – waiting for code to build, an app to load, a deploy to finish, or clar­i­fi­ca­tion to come from a developer. It all adds up. Initially, I viewed these as occu­pa­tion­al hazards, and spent that time twiddling my thumbs. What a waste!

The great thing about QA is that you are paid to make sure that everything works perfectly. This downtime lends the perfect opportunity to deep dive into that issue you were seeing on the Android app, or clarify the test document you used last week. Especially when you’re working on mobile apps, you can always look for other devices to test on.

Responsibility Isn’t About ​“Who”, But Rather About ​“What”

At Hudl, QA facilitates our deployment process. So, we’re the ones who ultimately push code to our users. No matter how thorough my testing, there will always be times where something goes wrong when we push a new feature. Pointing fingers, saying ​“it was the developers fault!” does nothing to solve the problem.

The blame could easily be turned back on me, since I tested the code before release. No matter how the issue arose, focus on fixing it and improving the testing process. Take a few minutes after something has failed to brainstorm testing procedures that would catch a similar issue in the future.

Question the Developers

During my first few weeks, I felt bad when I had to tell a developer that the cool new feature he added was breaking something else. I would hesitate to mention that his fix didn’t actually do anything. Don’t be afraid to question the developers and speak up when you find an issue or curiosity. Not only will this help you understand the way the product should function, but it will also help the developers clarify their coding.

If you see anything that is confusing, or that could be an issue, let them know. Developers welcome this because it improves the product.

Your Main Focus Should Not Be Finding Bugs and Errors

Wait, what?! I thought that’s what I was being paid to do? Technically, that is what QA does. But it should never be your main focus. I learned early on that I am really the front line between the developers and actual users. If I were to go through the app everyday, just looking for things that are broken, I’m sure it would work nearly flawlessly.

However, that does not mean that it would work well.

Instead, Focus on Thinking and Testing Like a User

Play with the product like a coach, or a teacher, or a [insert someone from your target audience here] would; don’t just check features off of a list. You will still be using all parts of the software, which means you’ll still find plenty of bugs. The only thing that changes is your mindset. The benefit, however, is that you start to find things that are more than just code issues.

• “Hmmm, this really doesn’t seem like a natural place for this button.”
• “When would a coach ever actually use that statistic?”
• “Those instruc­tions don’t make any sense.”
• “Why can I click over there in some situations but not others?”

Quality Assurance is a process that’s different for every company. It’s also a little different for each individual tester, and that’s a good thing. If you can get your mindset right, testing can become much more than just verifying that stuff works. Test like a user, and everything else will fall into place. The sooner you embrace this, the better feedback you can provide, and the stronger the con­tri­bu­tion you can make.

I’d love to hear about what others learned during their first few months and years in QA. How have those lessons changed your testing?