A patient walks into a doctor’s office and sneezes, just once. The doctor immediately scribbles out a prescription for hay fever medicine and sends the patient on his way.
It’s a preposterous story, right? Who tries to solve a problem without taking the time to understand the background issues and the impact of the obstacle? Who tries to fix an issue without first establishing the desired outcomes? If your answer to these questions is “nobody,” then welcome to software development, where understanding the root cause and modes of discontent often takes a distant second place to producing a solution.
How prevalent is this problem? Based on stories I see on LinkedIn and conversations I’ve had with others in the software development industry (not just testers), it’s far from uncommon. I’ve worked at various software vendors and a consultancy, and it’s a problem I’ve encountered in each. Early in my IT career, I worked as a Business Analyst, and clients weren’t any better at this. I was consistently provided background documentation that dictated specific solutions (which were often unique to the client rather than the platform) and barely mentioned the underlying problems.
I could be pragmatic and just say, “Hey, I’ll test what I’m given and take it from there,” or I could be honest and say that “building in quality” is more than a throwaway line for me. I genuinely believe in the value of that goal, and I know that achieving it is not easy. It requires dedication, focus, and people willing to change habits, persist, and collaborate. It needs people who are willing to fail (because, at times, you will), examine the failure, and then draw lessons to move forward. So, if I strongly believe in “building in quality,” then it seems a massive waste of time not to start with problem definition. I want to understand the problem. I want to understand who it impacts, how it impacts, and when it impacts. I want to know if there are levels of impact and if there is one problem or multiple problems. In my experience, when you delve into the definition and analysis of a problem, it tends to reveal a series of smaller issues. That’s important because it provides options and flexibility when considering solutions. This is all critical information for my testing, as it allows me to flex my testing through ideas that look for problems. It allows me to think deeply about gaps and enhances my contributions when reviewing things like UX designs and participating in solution or change discussions.
As much as I want this as a tester, it’s not solely a testing problem. It’s bigger than that. Misunderstanding or misidentifying the problem is a waste of time and money. It’s also a fast track to customer disillusionment and loss, which becomes a financial and credibility concern. Treating the problem lightly is a risk you take at your own peril.
At a recent company, one of the first things I noticed upon starting was the distinct lack of problem definition in the work tickets. I saw solutions, minimally documented by the person requesting the work, but no evidence of attempts to refine and define the underlying problem. I raised this with my team, and it concerned us all. We set about defining what we wanted to know before considering solutions. Our guidelines were flexible enough to allow for context variation (which our work had plenty of) but solid enough for us to reject solutioning when the problem statement was insufficient. The outcomes were noticeable:
- There was a significant increase in collaboration around work requests within the team and with those requesting the work.
- We reduced instances of “solving the wrong problem” because collaboration with the change requester helped us identify the real problem, which often differed significantly from what was documented in the ticket.
- We closed several work requests after discussing the problem with the requester and advising that a solution already existed.
- We stopped coding for problems that didn’t exist.