Interview With Elizabeth Zagroba
Elizabeth Zagroba is Quality Lead at Mendix in The Netherlands. She discovers and fills in the gaps in exploratory testing by coordinating an ensemble (mob) testing practice, actively listening, and setting out to prove that when “it should just work” it actually does.
She’s the go-to person for thinking critically about what’s being built, creating a common understanding, supporting colleagues outside the prescribed management structure, and writing API tests and English effectively. She injects what she learns from books, conferences, and meetups into her daily work, and spreads her knowledge through the workshops and Agile guild she facilitates.
Her goal is to build enough skills in individuals and teams to make herself redundant. She’s currently serving as a co-organizer for the Friends of Good Software Conference (FroGS Conf) and program committee member for Agile Testing Days.
Your conference talk, “Doubt builds trust” is one of the most memorable ones I’ve ever seen. What advice do you have for people who may struggle to express uncertainty or say they don’t know?
Thank you, it’s great to hear that the message stuck with you. You don’t have to literally say “I don’t know.” My advice is: Show your work. Noticing when you’re not sure about something, decide to seek an additional reference point or do more exploratory testing, and share the information you’ve gathered so your peers can be involved in the decision.
It’s the difference between “204 responses don’t have a response body” and “it says here on httpstatuses.com that 204 responses don’t have a response body." It’s the difference between reporting “I finished testing, we can release it.” and “I looked at Sjoerd’s branch on the test environment with an admin user.” at standup.
Telling the slightly deeper story lets your team ask “Was Sjoerd’s branch the right one, should we look at the rebased version on the development branch?” or “Did you try a regular user in addition to the admin user?”
I’m also curious if someone who struggles to say “I don’t know” is in an environment where it’s possible (or even better, rewarded) to admit doubt. If their environment doesn’t foster this kind of thinking, I’d begin to wonder why that is and dig in there instead.
You moved to the Netherlands a few years ago from the US. Did you notice any communication style differences upon the move?
The biggest communication difference was: people spoke Dutch to each other at the office!
I anticipated this.
But I didn’t anticipate how much of my testing work was fueled by eavesdropping. It was my superpower. I’d know about progress and changes on my team and neighboring teams that I would have never been told directly.
By March of 2020, I was finally at the point where I could understand enough Dutch to know if the conversation was relevant enough for me to butt in and switch to English. Our company hasn’t required people to come back to the office, so eavesdropping is not an option for me anymore.
Smaller (or private) Slack channels help but don’t replace it. I took on a role a few months ago as a quality lead supporting seven teams. I’ve taken to crashing their standups to get the kind of unofficial detail I need.
I found your article How To Interview Like A Tester on MOT, offered an interesting perspective for candidates.What advice do you have for people who are applying for roles, to help asssess if the company would be a good fit for them?
I’d recommend taking an inventory of what you find valuable and motivating in a company before you apply to them. I can imagine different people might be motivated to work for somewhere with a mission they support, a product they use everyday, a technology you’re looking to learn, or a group of people you’re looking to learn from.
I can also imagine someone motivated by the salary, the health care package (in America especially, where your health insurance is tied to your job), everyone coming to the office once a week, never having to come to the office. You’ve got to find the right mix of value and motivation for you.
You’re a quality lead at Mendix, where you are in charge of “infusing quality” into your teams.
What does that look like? What advice do you have for others hoping to do the same thing?
I am still trying to figure out how to summarise it, because every week has looked different. The job description I wrote before I started says I’ll help “teams find the sweet spot in the middle of speed in the short-term and growth for the long-term, while keeping quality attributes in mind.”
Sometimes that’s helping onboard or off board an employee, running The Four Hour Tester series of workshops, getting everybody to agree what a “beta” release is, mapping out a user journey, breaking down a test strategy into small enough pieces that the first one is pick-up-able, holding a retro about a customer issue, facilitating an ensemble testing session and following up on the bugs we found.
I keep a Trello board for my own focus, and make what I’m up to visible with short summaries at larger department meetings. I have an explicit mandate to perform these kinds of activities, but I did a lot of similar activities in previous roles and at previous companies before. For others hoping for a similar role, stay somewhere long enough that people trust your skills, or have someone that people trust advocate on your behalf.
I saw you, Maaret and Alex recently completed Alan Richardson’s API challenges.
What prompted you to do it? And what was your biggest takeaway from it?
I am still a bit in awe of being included in Maaret and Alex’s endeavor on those challenges. Past Elizabeth would be very impressed that she’s writing code with those successful people she saw on stage just a few years ago. Maaret was the motivating force, pulling first Alex, then shortly after me in.
My biggest takeaway was that structure matters: naming the tests to match the challenge names, having a method to check what we’d completed, keeping everyone involved in the decision-making of the ensemble by continually asking or declaring what the next step was. The skills of mine that I tend to view more “project management” than “technical” are just as important to completing the assignment and sharing knowledge effectively.