Try to Provide the Solutions, as Well as Finding the Problems: 99 Ways Workshop #61

Modeling data and interactions can help
testers get a better understanding of
the inner workings of systems,
and help them see potential solutions
to problems.

The Software Testing Club recently put out an eBook called "99 Things You Can Do to Become a Better Tester". Some of them are really general and vague. Some of them are remarkably specific.

My goal for the next few weeks is to take the "99 Things" book and see if I can put my own personal spin on each of them, and make a personal workshop out of each of the suggestions. 

Suggestion #61: Try to provide the solutions as well as finding the problems. -  Geekonomicon

Bugs, issues, anomalies, some other euphemism for a system that isn't working the way someone feels it should. Call them what we want to, the end result is the same. The system doesn't work the way that we envisioned (or how the customers would want). Issues range from low impact, but embarrassing ("how could you mis-spell that authorization agreement text?") to really catastrophic ("what do you mean my hitting Refresh causes all images to be deleted?!").

The issue we often face is that, we can show what's happening, we can say that we had a stack trace when I ran this command, but not be able to explain where the issue interacts with other components, or know where in memory the error took place. We could just shrug and say "well, we'll let the developer figure that out"… but what avenues could we consider if we were more knowledgeable about the system, and where these complex issues take place?

There are methods that we can use that will help us make more sense of the systems we work with, and in return, give us a little more edge when it comes to explaining problems, and what could be potential solutions to problems.

Workshop #61: Take the time to build a mental model for issues. Examine and put together your view of the system, and follow the system as you work through scenarios. Examine systems through both structural and behavioral models. Determine where the connection points are and which ones are weaker than others. Understand your system so that you can give clear advice as to what should be fixed, and why.

What follows is a scenario "based on true events". To protect the privacy of others and not implicate anyone or any situation directly, some aspects of this interaction narrative have been changed. Nevertheless the core example, and the resulting modeling for experiments are real.

I remember being told that a long running activity my kids were involved in was going to be moved to a new location. More that that, it was going to be moved several towns away. I felt a little bit of frustration with this information, but I figured "what can I do about it? I guess that's just the way it is". However, that didn't sit well with my wife, who was considerably more frustrated about the change. As I heard her explain what was happening, I stopped and thought "what do we actually know about this proposal?" When we got home, I puled out a notebook and started writing down questions:

- Where do we need to drive? 

- What time of day will the event be happening? 

- What issues might we face? 

- Are there traffic implications? If so, is there an alternate route(s)?

- How long are they going to be at the activity? 

- Will the activity put pressures on our kids arriving to or departing from school on time?

- What other activities and aspects of my kids lives did we need to keep in mind?

- What would my time commitment be if I were to be the one driving to and from this activity?

- What if I were to have my son do the driving? Are there restrictions I need to be aware of?

With these thoughts, I then sketched out some sample routes, examined maps, schedules, distances and average times for transit between our home and the new location. I also considered traffic patterns for that time of day, proximity to other places and things that could be done while we waited, and we examined local laws and regulations regarding teenaged restricted licenses. 

Over time and by compiling the questions, and answering them to the best of our ability, we determined the following:

- The new location, even at the shortest distance we could drive, would be about twenty miles round trip. 

- Based on mileage, roughly a gallon of gas would be consumed minimum with each trip. 

- By extending out five days a week, for about eight months a year (they would have days away for school holidays, etc.), we realized that we would spend about $1,000 during the school year to accommodate the location change.

- Multiply that by about 20 participants, and that becomes a significant monetary hit for a group of people.

What else should we consider? Well, my son is old enough to drive, so that would be cool. Except he has a restricted license. That means that he cannot drive with anyone else in the vehicle until he has had his restricted license for a year. That means, if we were to have him and his sisters participate in this activity each day, it would not be legally possible for him to drive both of them. Sure, I could look the other way and say "I don't see anything", but what does that teach my kids? More to the point, what happens if my son gets pulled over with his sisters in the car, and they realize he has a restricted license and is violating the law? Yeah, not something I want to risk. That means we either tie up two cars to drive there and back (impractical), or we have an adult drive them both there and back. With the adult driver, now we have to  commit their schedule to this endeavor.

There are other things that we also considered, but this is example enough for the time being.

What was interesting about looking at this scenario and making a model of all of the steps, we were able to gather a lot more information and determine a lot of potential issues with the new plan. While we could have just said "we don't want to drive farther, we liked the activity in its old location", instead, we were able to show the data and the economic, time and legal ramifications of the change. 

We presented the data, and compared the costs in time and money, so that we could compare it to the benefits of the new location.

- We were saving money by choosing the new location, but were we saving enough money to justify the additional expenses for the greater travel distance?
- Were we going to make for a situation where work schedules for adults were going to be impacted? - - Based on the time requirements and the travel commitment, did we have enough vehicles and enough people willing to commit to drive enough people each day to balance out the monetary expenses and the time commitments?
- Based on these points of connection, were there other solutions we could consider?

Bottom Line:

Data modeling need not be seen as some dry and boring topic. In truth, every one of us creates models of various activities. By learning the details of what we do, and being more systematic with what we examine, we can do more than just present problems. Often, we can see where the disconnect is and propose solutions, too.