Hao Nguyen
Because quality assurance (QA) is all about creating a seamless application experience across any number of devices, it’s most successful when no one notices it. The craft and expertise behind the work of QA professionals, as a result, can sometimes feel hidden. Charlotte Fouque, Caktus’ QA Analyst, sheds light onto what exactly quality assurance is and the intricacies of doing it well.
How did you get into QA?
I came to QA because I speak French. I was doing language quality assurance testing, testing translations in social games. So I continued into software QA after that. I am very organized outside of work. I use Kanban in my personal life. It’s part of a natural impetus to create order out of chaos.
What is quality assurance?
QA for a web project means testing across selected devices and browsers to make sure the site works as intended. We hold the development team to their own definition of quality. Whatever they or the organization has set as their quality threshold, QA ensures that is being met.
QA also serves as a user advocate. We have to think about whether the application feels good, feels enjoyable for users. Things don’t always line up between design intentions and technical implementation, and we have to be able to call out anything that doesn’t make sense. QA will make sure that the user is getting the best experience possible.
When does QA play a role in software development?
At Caktus, QA is involved from the beginning. We’re involved in estimates before a contract is signed. And we’re involved from every step on a project from the very first sprint, to development, and release.
What’s a typical day of QA for you?
In a typical day, I attend all the scrum meetings in the morning for the teams I’m working with. I have a testing plan that adds on only whatever stories or group of tasks the teams are working on in that sprint. I write the test cases, or reproducible steps to test a feature, in the morning. A test case, for example, could be that the close button on the popup needs to highlight when a mouse hovers over it. This test case would go into a test matrix that contains intersections of all devices and browsers. There’s a pass/fail for each test matrix field, or each device to each browser. Then in the afternoon, I usually follow the testing plan— cross browser, cross device testing.
But no two days are ever the same in an Agile environment, and it’s never boring!
How do you highlight potential bugs and issues for the development team?
If I find an issue, I will submit a ticket that contains all the relevant information for the developer to reproduce and debug it. I try to be as concise as possible (no developer wants to have to read paragraphs of text to figure out what the problem is!) Basically, I try to be as helpful as I can be in answering any questions they have or helping them track down where the issue is occurring. I want the bug fixed just as much as they want to fix it.
I sometimes sit down with the team, or we bounce ideas off each other on how to make a feature better. In my role, I put myself in the user’s shoes in a way that’s hard for a developer that’s too close to the project. I talk to development teams about bugs from the user’s perspective rather than a developer’s. If a user came across this or that bug, would they think there’s something obviously wrong? How would a user behave to get around the issue? Would a user consider it a workflow blocker and leave the site? Sometimes developers don’t see this because they’re deep in the code; they might not have the distance to consider how the user is navigating the site or getting to that particular bug.
What makes someone a good quality assurance professional?
A good tester is able to pay attention to details and willing to drill down. If I see something wrong in something I’m testing, I have to pursue it, try to find steps to reproduce the issue, check to see if it’s happening across devices and browsers, and then follow up with the developers. It requires a lot of patience.
We have to be able to find various small disparate issues but also larger overarching problems. For example, I’ll often find little bugs like links not highlighting but I also find bigger issues with user flow or ways to navigate the website. Someone that’s doing QA has to be able to find all sorts of issues from large to small to difficult to define problems. It takes a good QA person to not only find that range of problems, but to also be able to articulate them in precise, intelligible bug reports.
There are also different types of testing, and experienced QA people will have their own style. I like to test methodically, ensuring I hit everything I set in the test plan. Some people are better at exploratory testing, like clicking on things randomly; unusual user behaviors might uncover the software behaving in unexpected ways.
What’s the best part of QAing?
I find it really satisfying to pick apart features or entire websites, find little issues, follow up on them, and see them resolved quickly. It’s very rewarding to see a project come together, getting better and better every day.
What’s the most challenging part of QAing?
The most difficult part is that my imperative is to find bugs and get them fixed. But nothing is perfect - there will always be unresolved bugs that make it to release, and coming to terms with that is really hard! At what point is it good enough before you can say “ship it”? It’s important to have open lines of communication with the project manager or product owner so that they are aware of the existing issues and can prioritize them along with the rest of the development work.
What is your favorite QA tool?
The most recent one that I found has been really revolutionary for me: Ghostlab. Ghostlab does synchronized browser testing so I can look at the same application and interactions on as many browser windows and devices as I can see in front of me at the same time. It saves me tons of time and I really love it!
If someone were starting a QA process from scratch and they were part of an agile company, what advice would you give them?
I would say that the best way to approach that situation is to try to integrate the QA process with the existing development process. For example, at Caktus, we use scrum. QA actively participates in scrum as part of the development team. This is absolutely key. Developers would usually already have a verification and review step where they review each other’s code. QA comes in the step afterwards. They are part of the workflow and part of the success criteria for each task. Every task that goes through QA upholds the acceptance criteria or Definition of Done for the team.
A good QA person has to be able to work within the team along with the developers. QA should not work in opposition to developers, but as part of development. We can’t just throw issues over the wall to developers and call it not our problem anymore - it’s essential to remember that our common goal is to build the best product possible.
