Pax Noyes

Hi, I’m Pax. I’ve spent more than a decade in software quality, and I’ve experienced this profession from a lot of different angles. I’ve been a hands-on tester, built automation, worked as an SDET, worked with AI and AI-assisted development, developed quality strategy, and led and managed QA teams. I’ve also worked with teams all over the world and across Engineering, Product, Customer Success, and leadership.

My career in QA started because someone took a chance on me. I’ve never forgotten that. As I’ve grown into leadership, one of the things I care most about is doing the same for other people: seeing potential, creating opportunities, and investing the time to help people grow into them.

I’m also pretty opinionated about quality. I don’t think QA owns it. I don’t think more automation automatically means better testing. And I don’t think we should keep doing something just because that’s how we’ve always done it. I believe good testing starts with understanding the user, the risk, and the problem we’re actually trying to solve. Sometimes the most valuable thing a tester can do isn’t find a bug. It’s ask the question that keeps the team from building it in the first place.

I’m especially interested in where our profession goes next, including how we use AI thoughtfully rather than adopting it simply because we can. The tools will keep changing, but curiosity, critical thinking, communication, and understanding risk aren’t becoming less important.

I’d bring both a hands-on quality perspective and a people-leadership perspective to AST. I don’t expect to have all the answers. I’m willing to ask questions, challenge assumptions, experiment, be wrong, and change my mind when the evidence says I should.

WHY QUALITY? In 2 paragraphs give us an overview of your philosophy on Quality and how you approach testing in support of achieving quality outcomes… Please provide (non-confidential) real world examples:

Quality, to me, is ultimately about trust. Users don’t care how many tests we ran, what our automation percentage is, or whether a ticket technically met its acceptance criteria. They care whether the product works when they need it and whether they can trust it. I also don’t believe there is one universally correct way to achieve quality. Context and risk matter. A testing strategy that makes sense for a financial transaction might be completely unnecessary for a low-risk internal tool. “Automate everything” isn’t a strategy any more than “test everything” is. I want to understand the user, the system, the risk, and what failure actually costs us, then decide where testing gives us the most useful information.

I’ve experienced quality from a lot of different perspectives throughout my career. I’ve done hands-on manual and exploratory testing, API testing, built automation, worked as an SDET, developed test and quality strategies, and led and managed QA teams. I’ve also been the only SDET supporting multiple engineering teams and had to figure out where my time could create the most confidence instead of trying to test everything. Those experiences have reinforced something I believe strongly: quality is a team responsibility, but shared responsibility doesn’t make QA less important. It lets skilled quality professionals contribute at a much higher level. Sometimes our biggest contribution is finding the bug. Sometimes it’s building the automated check that protects us from seeing it again. And sometimes it’s asking the question early enough that the team never builds the bug in the first place.

This board role will require 10 - 20 hours per month of often self driven activities and the ideal candidate is someone who is willing to own an initiative and drive it through to completion... Is this something you are willing to commit to, and in your most honest moment, what will keep you motivated when the work gets hard and progress feels slow?

Yes. I wouldn’t accept the nomination if I wasn’t willing to do the work that comes with it.

I’m comfortable owning something where there isn’t already a checklist telling me exactly what to do next. A lot of my career has involved walking into ambiguity, figuring out what the actual problem is, getting the right people involved, and building the process or system that was missing. Management has only reinforced that because sometimes leadership means making progress when there isn’t an obvious answer and helping other people stay connected to why we’re doing the work in the first place.

What keeps me motivated when progress is slow is knowing why the work matters and being able to see that we’re learning or moving something forward. I’m not particularly motivated by maintaining a process just because the process exists. I’m very motivated by solving a real problem for people.

I also don’t need every idea I own to succeed. If something isn’t working, I want us to recognize that, understand why, and change direction rather than continuing to pour energy into it because we’ve already invested time. I’m persistent, but I don’t think persistence and stubbornness are the same thing.

It's 2030. AST just won 'Global Nonprofit of the Year' for transforming testing careers worldwide. What three bold moves did we make between 2025-2030 that nobody saw coming?

Follow-up: Which of these moves would you personally champion, and how would you convince skeptics on the board?

First, AST became a place where the industry doesn’t just talk about how testing is changing, but actually experiments with it. Working testers, engineers, product people, researchers, and leaders collaborate on real problems involving AI-assisted development, automation, exploratory testing, observability, quality ownership, and whatever comes next. More importantly, we publish what didn’t work too. I think our profession learns just as much from failed experiments as successful ones, but we’re much worse at talking about them.

Second, AST built a real career ecosystem for testers instead of trying to define one ideal career path. Someone should be able to enter AST as a new tester and still find meaningful opportunities ten or fifteen years later when they’re an SDET, specialist, manager, consultant, or quality leader. That means connecting mentorship, practical projects, technical education, leadership development, speaking opportunities, research, and career opportunities rather than treating them as separate things.

Third, AST stopped having the quality conversation mostly with quality people. Some of the best conversations I’ve had about testing have been with other testers, but the people making decisions about product strategy, architecture, engineering practices, staffing, and when QA gets involved aren’t always in those conversations. If we believe quality is shared ownership, AST should be one of the places bringing those groups together.

I’d personally champion the career ecosystem because I’ve experienced that career from several sides. I’ve been the hands-on tester, the SDET building automation, the person establishing quality practices, and the person leading and managing people doing this work. “Where do I go from here?” doesn’t have one answer in testing, and I don’t think it should.

I also wouldn’t try to convince skeptical board members that my idea was right. I’d try to convince them it was worth testing. Start small. Define what we’re trying to change and how we’ll know whether it worked. Give it enough time to produce useful information, then look at the evidence together. If I’m wrong, I want to know that too. Defending someone’s idea should never become more important than solving the problem the idea was supposed to address.

What's one thing AST is doing right now that we should stop doing immediately, even if it's popular? And what's one bold experiment we should try, even if it might fail spectacularly?

I’d stop putting so much of the highest-value professional development behind someone’s ability to pay for it personally or have an employer willing to pay for it.

I understand AST has to be financially sustainable, and I don’t think everything should be free. AST already has a free membership tier, regional pricing, scholarships, and other efforts to make participation more accessible. But some of the people who could benefit most from mentorship, deeper technical education, leadership development, and professional connections are also the least likely to have an employer paying for professional development. They’re the people trying to get their first testing job, navigating a layoff, moving from manual testing into more technical work, or simply trying to figure out where they fit as our profession changes.

For the experiment, I’d flip the question from “What can we give people for free?” to “What becomes more valuable when more people participate?” Mentorship, peer learning, collaborative projects, and community problem-solving all become stronger with participation. I’d pick one of those experiences, open it globally for a year, and intentionally remove as many barriers to participation as possible.

Then I’d measure it. Who showed up? Who stayed? Did people build meaningful professional relationships? Did someone find a mentor, become a mentor, get their first testing job, move into automation, or become a first-time speaker? Did participants eventually become paying members, volunteers, instructors, speakers, or leaders within AST?

Maybe it fails spectacularly. Maybe we discover that cost wasn’t the barrier at all. But then we’ve learned something useful, and I’d rather run an experiment and discover we were wrong than keep operating on an assumption because it’s familiar.

What is your history with AST? Describe why you are interested in serving on the AST Board and what personal / professional strengths make you an ideal board member for the organization?

Follow Up: Are there any particular initiatives or areas you are especially interested in driving / leading?

My history with AST has mostly been as a casual participant and follower. How involved I’ve been in the broader testing community has varied depending on what life allowed at the time. I’ve continued learning from the community and following the conversations happening within it, even during seasons when I didn’t have the capacity to be more actively involved.

I’m at a point now where I’d like to contribute more directly. I’ve spent more than a decade working in quality, and my perspective has changed as my career has grown from hands-on testing into automation, SDET work, quality strategy, and now leading and managing teams. I think I have something useful to contribute, but I also see serving on the board as an opportunity to learn from people whose experiences and perspectives are different from mine.

I’m interested in serving because I think testing is at a really interesting point right now. AI is changing how software gets built. Automation continues to change what organizations expect from testers. Roles and titles are changing. At the same time, we’re still having some of the same conversations about whether QA owns quality and when testers should be involved that we’ve been having for years. I don’t want testers simply reacting to those changes. I want us helping shape what comes next.

One of my strengths is that I’m comfortable challenging the way we’ve always done something while still being willing to do the work required to build something better. I’ve been the person executing the tests, the person building the automation, the only SDET trying to support multiple teams, and the person responsible for leading and developing other people. Managing teams has also changed how I think about quality. A good quality strategy can’t depend on one exceptionally motivated QA person holding everything together. It has to be something a team can understand, maintain, and improve.

I’m especially interested in helping testers navigate where our profession goes next, practical education around modern quality engineering, mentorship and career development, and creating stronger connections between testing and the broader engineering and product communities. If we believe quality is shared ownership, we need more of those conversations to include the people we’re sharing that ownership with.

When you step down from this board, what do you want your Wikipedia entry to say about your contribution to AST and the testing profession? What impact are you personally committed to creating?

I don’t particularly care whether I ever have a Wikipedia entry. I’d rather someone say, “She helped make this profession better for the people who came after her.”

I haven’t forgotten that my career in QA started because someone took a chance on me. They saw something in me before I had the experience or the title to prove I could do it, and that decision changed the direction of my career. I want to spend my time doing the same for other people. Whether that’s through managing and developing people on my own teams, mentoring someone trying to find their place in testing, or helping create opportunities through AST, I want to be someone who opens doors for people and then invests in them once they’re through.

I also want to help move QA away from being viewed as the last checkpoint before software goes out the door. I want testers to have a voice earlier, where our ability to question assumptions, understand risk, advocate for users, and think about failure can influence what gets built instead of only finding problems afterward. Shared ownership of quality doesn’t make QA less valuable. It gives us the opportunity to contribute at a much higher level.

And I want people growing in this profession to know there isn’t one correct path. Not everyone needs to become an automation engineer. Not everyone needs to become a manager. We need great exploratory testers, technical quality engineers, strategists, leaders, specialists, educators, and people who will create roles we haven’t named yet.

If I’m remembered for anything, I’d like it to be that I helped people see what they were capable of, gave them opportunities to prove it, and left the profession a little better than I found it.

You're on a board committee with members from Japan, Brazil, Nigeria, Germany, and the US. The group is stuck on a decision because cultural communication styles are clashing and creating misunderstandings. What is your strategy for facilitating breakthrough and building genuine consensus?

Follow-up: Provide an example of how you've successfully worked across significant cultural or professional differences.

I’ve worked with teams all over the world throughout my career, so working across different cultures, communication styles, and professional perspectives isn’t new to me. One of the biggest things I’ve learned is that I can’t assume the way I understood something is the way someone intended it.

I work hard to listen first and understand where I might be misunderstanding. I’m also not afraid to ask questions that might make me “look dumb.” I’d much rather ask someone to explain what they mean, clarify an assumption, or tell me why they see something differently than pretend I understand and discover later that we were having two completely different conversations. I’ve found that being willing to say, “I might be misunderstanding you, can you explain what you mean?” often gives other people permission to do the same.

When a group is struggling to reach consensus, I don’t start by trying to get everyone to agree. I start by making sure we’re actually disagreeing about the same thing. What decision are we making? What assumptions are we each bringing to it? What constraints are real? What outcome is each person trying to protect? I’ve worked across QA, Engineering, Product, Customer Success, leadership, and globally distributed teams, and sometimes what looks like disagreement is really a difference in context, terminology, priorities, or communication style.

I also don’t think consensus should mean the loudest or most confident person eventually wins. As a manager, part of my responsibility is making room for people who process or communicate differently. Sometimes that means asking someone directly for their perspective. Sometimes it means giving people time to think and respond in writing instead of expecting everyone to do their best thinking in a meeting.

I don’t expect differences to disappear, and I don’t think they should. My goal is to create enough understanding that we can disagree honestly, ask questions without being embarrassed by them, make a decision together, and make sure people understand why we made it.