Building Quality Donkeys

PNSQC Software quality and testing principles are applied to the training of wild donkeys.

by Heather Wilcox,
PNSQC volunteer

When I’m not at work, I’m pursuing my hobbies. I have owned and worked with donkeys for 15 years. About four years ago, I stumbled onto one of the most fun and rewarding experiences I have ever had: taming and training wild donkeys. Yes, there are wild donkeys in this country. Where there has been gold mining, there are wild donkeys. They are managed by the Bureau of Land Management through the same programs used for wild horses, or mustangs.

Populations of wild horses and donkeys must be controlled to prevent overpopulation, so animals are periodically rounded up and placed into holding facilities. The BLM works with organizations to try to get these animals into homes, since it isn’t fair to leave them languishing in government custody.

One of these programs is the Great Burro Turnaround in Eugene, Oregon. Trainers are randomly assigned a wild donkey and given 100 days to tame the donkey and teach it as much as they can. After 100 days, trainers and their donkeys compete to demonstrate what the donkeys have learned and to show their suitability as pets. After the competition, animals are auctioned off to BLM-approved adopters.

I have participated in this competition for three years. In doing so, and in taming other wild donkeys, I have learned a lot about these animals. I have also been surprised at how similar the techniques and strategies I use for taming donkeys are to the processes I use for testing software.

Donkeys have a reputation for being stubborn; however that isn’t really the issue. The problem is that they are smart and will not work unless it makes sense and the work benefits them in some way. The benefit doesn’t have to be pronounced.

Often it is something as simple as “Because my human said so.” Additionally, donkeys refuse to participate in any activity they believe will be harmful or dangerous.

So, as a trainer, your biggest obstacle is often convincing the burro that 1) No, you will not die because of this and 2) Yes, there really is a goodie for you if you get this done. If you can figure out how to do those two things, you can tame and train a donkey. Of course, the figuring out is where the challenge lies and where good QA process becomes valuable.

From a big-picture perspective, the process for taming donkeys is much the same:

• Gain trust.
• Build a relationship.
• Teach the required skills.
• The same is true for testing; we more or less follow the same process.
• Establish what it is the software is supposed to do (i.e., read the specification.
• Build a set of tests around the specified features.
• Run the tests.

But it’s never that simple.

Testing software requires a lot of troubleshooting, rooting about and hoping things behave as expected. This is the same thing that happens with taming donkeys. For example, gaining trust sounds easy. Just go in and explain to the donkey that you are there to help them out, that they’re really going to like people and you’re there to show them how to get along in the wild world of humans. Too bad they don’t speak English. You have to accomplish this task by figuring out how to communicate these concepts nonverbally. For me, that means making every interaction with the animal positive.

Every donkey has a weakness: food, ear itches, booty scratches, brushing — some little action that, when you discover it, helps the donkey discover that maybe people aren’t so bad. This calls for extensive, careful troubleshooting. Donkeys will respond positively to most things, but the trick is knowing when you’ve found their weakness. You have to look carefully for a lip twitch, a moment of relaxed body posture or a little sigh that indicates you have hit something so good the donkey is willing to let down their guard and allow you to see how wonderful that thing is.

Now, re-read the first couple sentences of the previous paragraph. Substitute the word “donkey” with “software”. Replace “weakness” words with technical terminology like “memory leak,” “data loss” and “UI errors.” Suddenly, it’s not about donkeys anymore and it still makes sense.

Normally, when we test software, we do it feature by feature. Each thing is tested in isolation to make sure it conforms to specification. The same is true with donkey training. Each skill is taught separately: Pick up each foot, lead, allow a human to brush you, load into a trailer, etc. But when all the features have been added, we integration-test to make sure the entirety of the system is working as expected. In software, we test the system end to end. With donkeys, we do something similar where we combine the skills to make sure they are working in combination with each other: Pick up a foot with a halter on or allow multiple strangers to approach and touch.

The goal for these donkeys is to be transitioned into civilian homes with people expecting a fully tamed pet and who may or may not have donkey or horse experience. As a trainer, you want to make sure your animal is as safe as possible in that scenario, so when you think you are close to being done with a burro, you start failure testing. With software, we normally fail test as part of our feature testing, but in donkeys this happens later in the process.

However, the concept is the same: Make sure failure scenarios are handled gracefully. For example, horses and donkeys are led using a halter and lead rope. This is much like a collar and leash for a dog.

However, unlike a collar, there are several ways to put a halter on improperly. So I spend time making sure that, even if the new owner puts the halter on upside down and backward (it is possible), the donkey won’t panic. The same is true for picking up feet, brushing and any other maintenance task. There is a right way and a wrong way, but if the owner does it incorrectly, the burro should handle the mistake gracefully. This is exactly the same way you want your software to handle a bad or incorrect input: A graceful error message that informs the user and prevents them from proceeding further until the input is corrected. Periodically testing to make sure the donkey doesn’t get upset in these failure scenarios helps me gauge how close the animal is to being ready for placement in a new home.

It would be easy to go on for pages discussing how software quality practices can be applied to donkey training and vice versa. But I suspect I’ve gotten my point across and I don’t want to bore anyone. However, as a quality engineer, I think the most interesting thing is how often the practices and processes I use in my work are useful and applicable in other parts of my life.