Heads-up: For the next few weeks, Dev Tester articles will be slightly different from my regular posts while I focus on End-to-End Testing with TestCafe book updates and other projects. These shorter articles intend to be a bit more thought-provoking and opinionated than usual. I'll return to more detailed and longer posts soon!

I recently stumbled upon a Reddit thread that made me think about how I interact with my team, especially when faced with a software bug. Debugging any software failure, particularly those sneaky bugs that are almost impossible to reproduce, can be a stressful time for any developer or tester.

As mentioned by the poster of the Reddit thread, I've noticed some people try to take a step back after they feel like they're spinning in place for a long time. One of the questions often asked at this time is, "What are we trying to test here?" It's a noble attempt at trying to gain some perspective after working on something for so long that we probably forgot what we're trying to solve.

However, the problem with that question is that it's incredibly vague and open-ended. It leads to equally ambiguous and unhelpful answers from most people you suddenly ask. You shouldn't get surprised if others on your team respond to this question with something like, "Um... we're trying to test this issue that's causing problems?"

Asking the right questions that lead to solutions

In my experience, these types of questions lead nowhere and waste everyone's time. But that doesn't mean you should refrain from asking any questions. You can ask better questions to get your team to look at the problem from different perspectives and guide them to a place where they probably hadn't looked at yet.

Here are a few questions that can work great for you and your team:

What do you think the problem is, and why?

This question works well for a couple of reasons. You're asking someone to articulate the problem in their own words. It slows down their thinking process at a time when they're likely rushing through trying to fix the problem and allow them to spot potential gaps. It also can help increase their own understanding of the problem because they have to explain it to someone else. Teaching is one of the best ways to learn anything.

What have you discovered so far in your debugging process?

While this question helps you avoid attempting something that someone else already tried, you can also use it to get them thinking deeply about what they did. It's not uncommon to explain something you did, only to discover in the middle of your explanation that you missed a step or could have tried something slightly different.

What attempts have you discarded, and why?

Again, this can help avoid duplicate work. However, this question serves a similar purpose to the previous ones covered above. It allows someone to explain why they abandoned some of their attempts, which causes them to become more critical of their own thoughts. It also gives others a chance to chime in with potential reasons to try again with a minor change in the previously-attempted process.

Do you have any leads to follow that you haven't tried yet?

Like other questions in this article, this question gets people thinking more intensely about potential solutions rattling inside their heads. But the real gold mine in asking this question is that it gives them permission to acknowledge "crazy" solutions that they were afraid to mention for fear of getting laughed at or thought would never work. More often than not, these types of solutions are the out-of-the-box thinking you need to fix the issue at hand.

Shift your focus to get what you need

These questions aren't meant to be a "holy grail", guaranteed to solve all your debugging issues. You and your team might not get far even with these types of questions. No matter what other questions you throw out to solve any issue with your testing, the key is to focus less on the problem and more on potential solutions.

Our brains are conditioned to filter out the things we're not seeking at any given time. This function allows us to focus on what we are looking at and not get overwhelmed by every little thing. So when you ask a question like "What are we trying to test here?" it places your mind squarely on the problem and not potential solutions.

Instead of overthinking the problem, this article's questions guide you and your team to think more about reaching solutions. It can be the difference to get your team's attention primed at reaching your goal instead of getting stuck figuring out an issue. Make sure you take time guiding everyone's thoughts and conversations towards solutions, not problems.

What questions do you ask when helping your team debug a particularly tricky issue?