A little over a year ago, I was looking to leave my previous position at a large consulting agency. At the time, I was working as a business analyst and was wearing a few too many hats. I was looking to transition away from the waterfall-heavy role and more into a design-based role, such as a UX Designer. I stumbled upon a job posting at a smaller, family owned company in Old Town Alexandria, 10 minutes from where I grew up. The role was titled “Quality Assurance/User Experience Specialist”, and I thought it sounded like a great way to transition into a UX-based career. Obviously QA and UX are very different, but I think that they compliment each other nicely and thought it was clever that they were combined into one role. However, the “QA” portion of the role intimidated me. While I had previously been responsible for testing I had never been in charge of coming up with a test plan or writing any automated test scripts. I applied, interviewed, and (thankfully) got the job! I started at Element 84 on a project as the first and only dedicated QA resource, and wanted to share some things I’ve learned along the way:
The True Definition of Quality
When I started working in the QA world, I assumed that the goal was to be perfect. I thought 0 bugs and 0 downtime, all while being perfectly on schedule, was the expectation of my client and of my management team. For a long time, any time I inevitably missed a bug, I would take it extremely personally. I would get really down on myself for making a mistake, which discouraged me from continuing to try and catch bugs. When I was working on a presentation, I found a definition of quality that helped me better understand what a person in my role was trying to achieve:
The purpose of QA/quality is not to be perfect, but to reinforce confidence in the product.
This definition struck a chord with me because reinforcing confidence in our product is achievable, while perfection is not. In fact, I felt that despite missing the occasional bug, our testing system was quite effective and contributed to the overall quality of our product even earlier in the process than I’d imagined. Our clients seemed to be put at ease with the introduction of a full time QA resource. Sure, there was room for improvement and I still have a lot more to learn about the world of quality assurance, but knowing that I wasn’t expected to be perfect took a lot of pressure off and reinforced my confidence as a tester.
QA is everyone’s responsibility
It was intimidating to be the only person on the project (and at the company) responsible for quality assurance. I dealt with a good amount of imposter syndrome because of not having anyone to learn under and having to hit the ground running. Luckily, not having anyone else who did QA didn’t mean you’re the only one who pays attention to quality. My entire project team has helped out in one way or another to positively influence the overall quality of the project. For us, that means gathering good requirements right off the bat and keeping lines of communication open with our client so that we could always clarify requirements. It also meant having design reviews internally and externally so that the experience could be ironed out before a single line of code had been written. Our developers helped by performing thorough code reviews on all stories and bug fixes, as well as sharing their development best practices with the team. All of this would have to happen before feature and regression testing even started.
It was definitely a worry of mine that some members of the team would hear “you have a new person in charge of testing and quality” and they would react with “well then I guess I don’t need to be as thorough”. Anyone working in a QA role should not be seen as the “safety net” for the project—it’s everyone’s responsibility to keep quality in mind as they work to meet deadlines and create new features.
It’s important to advocate for QA
Sometimes I get the feeling that when people hear the schedule “X number of weeks for development and Y number of weeks of QA”, they really hear “X Number of weeks for development and all of QA’s weeks for a little bit of bonus time!” I’ve found that it’s important to stand up for the value of testing and quality assurance, both externally and internally. Internally, it’s important to make sure you have enough time to complete a full test of a new feature by communicating your estimates to your project manager and development team. It also means raising ideas you have about general improvements you see that could be made to the product, even if they aren’t directly related to the feature you’re currently focused on. Externally, it’s important to quantify the value of the work you’re doing. Quality can seem pretty intangible at times, so it’s important to have metrics to be able to point to that show the results you’re getting. Some examples include the number of bugs that were found in production, how long it takes to complete a regression test for a release, and the coverage of unit and automated tests. Having access to metrics like these will give your clients a better sense of your process and reinforce their confidence in the product.
Individual QA roles are important on modern software products as a check on the incremental testing and QA that happens at the developer level. It’s important to remember, however, that QA should be a team goal and not an individual responsibility.