The Art of Curiosity and Asking Questions

Learning to Swim

At the start of my career, I didn’t know what software quality or testing was. I studied International Business and Mandarin Chinese at university, uncertain of what my career would look like. After graduation, I worked various contract roles and at a bar until landing a contract at a financial company that turned into a permanent role.

The role was a customer service and data processing role—not necessarily a dream job, but it provided the opportunity to learn about something I was very unfamiliar with. And I did just that—I dove into learning how the product worked, why we did things certain ways, everything I could learn in my role. After some time, I ran out of things to learn.

Luckily, I had a really good manager who saw something in me and developed an open environment for me to share that I wasn’t feeling fulfilled in my current role. She noticed I tended to ask a lot of “Why” questions when we had new feature releases or when I learned about some of the duplication we had to do in some of our data processing.

It turns out that my natural inclination towards asking questions and drive to understand how things work made me well-suited to a job I had never heard of until she recommended it to me—software quality. I interviewed for an open QA role and made the internal transfer, a pivotal moment in my career.

Ever since that moment, I’ve loved the field. Beyond that, I have continued to build on the natural way I think—developing my expertise and knowledge while continuing to grow my natural propensity towards systems thinking and curiosity.

Testing the Waters

As I have developed in my career, I have become increasingly aware of the value of curiosity, inquiry, and finding the language to communicate both.

While I believe that all questions are valuable—the pursuit of knowledge is valuable—there is an art to asking questions that drive holistic quality for software projects.

So, how do we practice curiosity and asking questions?

I take a systems-thinking approach to almost every problem or feature I examine. This has become somewhat second-nature to me at this point, but it started with asking those “why” questions. Some very generic examples:

Why does this feature work this way?

Why did we decide on doing this process versus another process?

Why was this aspect of the project more important than another aspect?

I wasn’t necessarily following a specific method, although I was loosely implementing systems thinking—I was exploring why software was built the way that it was. Why the teams I worked with made specific choices about what features to implement, what to prioritize, what tech stacks to use, etc.

These all came from a drive to understand not only what pieces made up the technical systems I was supporting, but also why we made those decisions. As a tester—a quality expert—the ability to dive deep into how the software is built, how things are connected, and why it is built that way has enabled me to support my teams in a multitude of ways. From process changes to observability to test automation design to exploratory testing and more, I’ve been able to drive holistic quality and develop my own skills through that work. All of the skills I’ve developed have come from a desire to fully understand the whole system and build better products and experiences.

Diving in Deep

Beyond the frequent “why” and “how” questions I ask, I have several go-tos that are applicable in most scenarios, at least from my experience:

What problem are we trying to solve?

What are the potential future use cases for this feature?

How can we make this feature flexible to future changes?

These questions frequently shift the conversation to be less focused on the explicit changes being made, and instead place the focus on understanding the context of the decision, its potential impact on the current and future experience, and the long-term stability of the product.

So, what can you explore in your work?

Let your curiosity lead you—explore the complex connections of software systems and ask all the questions that enable you to expand your understanding of the systems you work in.

I’ll be doing the same—always asking questions, falling down curiosity-driven rabbit holes, and always seeking to understand.

Sidney Karoffa is a QA engineer & systems designer focused on engineering enablement. Passionate about UX, test innovation, & process optimization. Strong believer in democratizing technology & knowledge.

Learn more about Sidney and her work on LinkedIn.