Daisy Liu knows how to prioritize. The QA Engineer on Mozilla’s Firefox Lite team understands she’ll never have enough resources or time to tackle every single challenge on a given day. To stay focused, she weighs every decision against its potential impact on users. Below she shares more about the importance of Firefox Lite, the benefit close collaboration, and a few hints of projects to come.
What do you do at Mozilla?
I’m a QA engineer on the Firefox Lite team. Firefox Lite is a browser we designed for people who have very low bandwidth or pay a lot for data, like many of our users in Southeast Asia. You can use it to load a web page without all of its high-res images, for example. I work primarily on Android, and I’m responsible for our automation testing and release process, including building out tooling to support the Dev team.
How do you and your team decide which innovations to prioritize?
Day to day, I prioritize my work based on the team’s immediate needs—to innovate, we need our systems to be sound. I collaborate with our Dev, Business Intelligence, and Product Management teams to make sure I’m working on the most critical pain points.
In terms of the team’s innovations, the work is a data-driven process. Last year, for example, we embedded several new verticals in the browser: games, shopping, travel, and news. To encourage users to try them out, we offered incentives like discounts. But before we decided which features to keep long-term, we gathered a few months of data to see what people actually found helpful—and ultimately, we decided to focus on news and games.
New features are always a balance. We only have so many engineers, and we want to be thoughtful about how we use our resources. But you have to give things time to work, too, and make sure you keep iterating and exploring.
What does collaboration look like, within the Taipei office and beyond?
The QA team works closely with our PMs and engineers to figure out our priorities—if there’s a crash, for example, we’ll identify the root cause and make sure we understand the impact, then meet to decide what action we should take. I also collaborate a lot with the devs to build out infrastructure and make sure our testing is scalable across different features. And there are members of the Data team in the loop, too; once a PM has a spec ready, they’ll get a data engineer involved to determine which metrics to track.
We have all of those roles represented here in Taipei, so unlike a lot of Mozillians, we usually don’t work from home. Of course right now, we’re staying home to stay safe, but I’m looking forward to getting back to the office. It’s nice to be able to have daily standups face-to-face and to go directly to a teammate when you need to have a quick discussion or get some feedback. Being co-located helps us work with other functions like Marketing, too; if they hear I’m going to release something, they’ll come by and offer to update the screenshots on the Google Play Store, or if we’re getting ready to release a feature in additional countries, they’ll ask if they should translate the listing. They’re very proactive, which I really appreciate.
As far as collaboration beyond Taipei, we do work with teams in the U.S. It takes a little planning to navigate around the time difference, but it’s usually as simple as scheduling a video call. QA also communicates a lot with people in other countries, to make sure testing for an area is complete before we turn on new features. We also have Slack channels with some external communities; if we release a feature in India or Indonesia, for example, we’ll tag the people there to let them know, and they’re always really enthusiastic about trying it out and giving us feedback.
Tell us more about the team culture.
I feel like we’re all free to really speak up and contribute—if you have a new idea or think we can improve the user experience in some way, people are happy to discuss it. The automation work I do is a good example. I’d worked in QA for several years before I came here, and I think that experience helped me see things from an engineer’s point of view and imagine what would be helpful to them. So when I joined Mozilla, I recognized that with the number of people we have, engineers probably weren’t going to have time to handle testing automation and the release process on their own—but if I took it on, it could save them a lot of repetitive work. It’s an investment that benefits all of us, because we can spend more of our time working together and making the product better.
What are you excited about in the year ahead?
There are so many possibilities! We’re setting up Mozilla’s first “innovation studio” here in Taipei, which we’re all very proud of. The first projects will be focused on internet security—things like using blockchain for identification—so some of the people in our office are starting to work on that. We’re also looking at using AI for audio analysis, so our users can speak rather than type, regardless of their accent. And there are some new upcoming partnerships I’m excited about, too.
To me, the first question when we’re deciding what to do next is always, “Is it worth it?” With every project, we have to think about who it will help and how much, what success would look like, and how we’d get there. Then, once we’ve decided that a new idea will really benefit our users, I can put my whole heart into it.