The first real item of work I was given when I started working at Content Bloom was a series of user acceptance testing [UAT] and ad-hoc quality assurance [QA] tests to perform. I knew this was a way for CB to test my abilities as a co-op student and potential employee, so I wanted to make sure I did everything right.
QA has a broad spectrum of tests, requirements, and formats. It really comes down to finding which ones work best for your project, but I couldn’t decide which to choose from.
I decided to get some feedback and consult with my co-workers. Their input allowed me to workshop quite a bit and this refined my QA process. I definitely can’t speak about QA as a seasoned professional, but I do have some advice for those of you who are just breaking into the QA world. Here are some helpful tips I wish I had known before getting started.
1) Know the Differences Between QA and Testing
To put it simply, QA is an umbrella term to describe a broad set of processes that can be divided into two parts: part 1, quality control [QC] and part 2, testing. Quality control is the process of assuring that the product meets the user-story requirements and testing is the process of evaluating the code for bugs. These sound a bit similar, so to wrap my head around it I like to look at it this way: QC ensures a user has the ability to make an account and Testing makes sure that when a user tries to make an account, the page doesn’t crash. They go hand-in-hand, but there is an important distinction.
2) Document Everything
Report everything that catches your attention. At first, I didn’t feel too confident in my reports and didn’t know if I was getting it right. When I was doing my first set of tests, I kept wondering if I was missing anything major that needed to be reported. Ironically, I was simultaneously worried about picking out things that were not issues or too minor to cause concern. I’ve learned that the best way to combat this is to report anything that looks off or seems even the slightest bit wrong.
If you’re 99% sure that a text box is 2 pixels to the left of where every other element is aligned, report it. If it is sent up the chain through the development process, you’ve done your job as a tester. Chances are some issues are a lower priority but still something the devs want to correct. It’s best to be as thorough as you can be. Informing the devs and describing and documenting every little thing that is broken isn’t a bad thing, as long as your reporting is done in a useful and intelligent manner.
3) Select a QA Format that Fits the Project
I wasn’t given a super strict format for my first QA report. For the most part, I had control over how the report would look and which information would go into it. There was a lot of trial and error. Displaying the test results correctly in a clean, informative, and readable format took a lot of work. Looking back on that process I think the things to consider are readability, level of detail, and ability to help locate and solve the issue.
4) Know your Audience
The level of detail in your report should be proportionate to the audience you’re targeting. If the report is for technical individuals, chances are they don’t want to read unnecessary details. For these technical audiences, a quick and to-the-point synopsis is the way to go because they already understand the process and terminology.
If your audience isn’t technical, include as many useful details as you can, but try to avoid heavy terminology. A non-tech audience benefits most when a technical problem is translated into everyday terms.
5) Make the Process Easy on your Audience
The capacity a report has for locating and solving issues largely comes from readability and level of detail. It’s important to include things like URLs, screenshots, and steps to reproduce an issue. These smaller situational inclusions will really amplify your report’s usefulness.
6) Stay Organized and Don’t Get Distracted
Another issue I had to overcome was how repetitive QA can be at times. I would occasionally lose my place mid-task because something else would momentarily catch my attention. Losing your spot can cause a number of problems; accidentally skipping over a test, performing a test but not recording the result, repeating a test, etc. The risk of distraction is especially high if all the tests are very similar. If you want to be productive, set up a quiet workspace so you can stay focused throughout the testing process.
7) Test your QA Methodologies
Did you know that repetitiveness in QA is beneficial? Doing something many times over allows you to test whether your process is good or not. The more you test and take new findings into account, the better the process.
If you’ve run into an issue and switching methods halfway through the process is your simplest solution, definitely do so. However, if you’ve discovered a new method very late into the testing process, switching methodologies could be damaging to your work. Instead, make a note for the next time you are testing to remind yourself to incorporate the new method.
QA is kind of funny in the sense that when you perform QA you often end up finding the “bugs” in your own QA strategy, which is great because it will turn you into a confident expert tester in no time.
