This was originally published on my blog, http://angelariggs.github.io.
Everyone agrees that developers’ work should go through QA in order to ensure a high quality of that work, but how many companies have a dedicated QA engineer to drive that vision forward? It’s kind of like the attitude around test-driven development - it’s definitely a great idea, and people get behind the theory, but it’s often overlooked or an afterthought in practice.
I think there can also be a lack of understanding or thoughtfulness about what the role of QA should be. QA engineers are a huge asset for tech companies by helping ensure and improve the quality of work being produced. My own experience has been a mixed bag. Our SOWs and sprint estimates include time allotments for developers, QA, and PMs. On paper, my estimated time ranges from 0% to 20% per sprint. Sometimes it’s 100%, all placed in the second-to-last sprint for “QA and Hardening”. 20% per sprint is pretty reasonable for most projects, but the other scenarios are not only unreasonable, they send a message that QA is not valued.
Unfortunately, holding the line on high standards is sometimes viewed solely as a blocker to work getting deployed. Even working within a close-knit team that communicates pretty well, it’s not always easy to push back on someone’s work. I used to work with a developer who definitely saw QA as a blocker. He would leave out steps in his PRs, and get visibly annoyed when I had to ask for clarification. When I asked questions, or his ticket didn’t pass QA, his top response was always “worked on my computer.” Other frequent responses included asking if I clicked Save, and refusing to answer questions (“I reverted all features but this one is refusing to revert, is that expected?” was answered with “Don’t you think it would revert if it was supposed to?”). It was extremely demoralizing. When the loudest and most consistent voice about your work thinks you’re incompetent, it makes for a pretty stressful work environment.
Quality assurance is so much more than a reactive role, passing or failing tickets as they queue up. We have to be proactive; not just solving problems, but also finding things before they are a problem. A good QA engineer has to find the balance between advocating for both developers and product owners. If a dev or client says “I don’t think this is right”, QA engineers can give hard data to confirm or clarify, and make recommendations for improvement. We have to test against acceptance criteria, but also think about the client’s or end user’s implicit needs.
I’ve chosen to push back on tickets where the explicit acceptance criteria was met, but the admin experience was lacking, or underlying client needs weren’t met. One example was creating a sortable list for a website’s FAQ section. The original implementation by the developer was a weighted list, where the content admin could select a different weight from a drop-down and it would re-order the FAQ list. Looking solely at the ticket’s acceptance criteria, I could have passed this ticket forward for deploy. Instead, I chose to ask for a different solution - the weight selection didn’t reorder the items in real-time in the back-end; and choosing a weight on an FAQ didn’t force a change to another’s weight, so you had to change all selections if you wanted to change one. I requested a draggable sort, where the admin could rearrange their FAQ list and easily see what the end result would look like. The developer reworked it, passed it back for another round of QA, and it was deployed - and it was a better feature because of my input, and because that input was accepted.
In my role as QA engineer, I look for ways to improve admin and user experience, figure out methods & tools for testing, and communicate needs between competing areas of concern. QA engineers are a bridge to stronger client relationships, building trust between clients & developers, and making sure projects are a source of pride.
How does QA play a role at your team or company? How have you iterated to improve QA and the role of your QA engineers?
Top comments (0)