Test It Like Genghis Khan

I recently read the book Genghis Khan and the Making of the Modern World to glean its insights into management and quality assurance in particular. As you would expect, I found a lot of good advice from the life of a man who drove natives into moats to fill them. Here are three:

  • Prepare the environment.
    When Mongol reconnaissance groups were looking around at the edge of the largest contiguous empire the world has ever known, they would find places they were going to invade next year. Then they would burn the agriculture nearby and they would raze the villages in the manner of Genghis Khan. That way, next year or the year after, when the main of the Mongol forces would come riding through, the formerly developed land would be good pastures for the horses.

    This is not a call for adequate planning at the project level. The best plans evaporate in the heart of testing. It’s about looking ahead and making sure you have the resources to feed your horses when the time comes. Make sure you have the appropriate browsers installed and your VMs in a row before the projects start. Get a good basic idea in place for how you approach generic applications trampled into your people’s minds so that when they cross the river, they know what to do and where the forage is.

  • Bring to bear different technologies and knowledge bases to devastating effect.
    The Mongols ruled a vast swath of Asia, the Middle East, and eastern Europe. They had a great diverse number of peoples upon whose knowledge they drew to great effect, using war machines and techniques learned in Asia to attack cities in Russia with something they’d never seen before. The Mongols also used scholars from all across the world to administer and maintain the vast trade lanes they created. If Genghis Khan had stuck to what he knew, fighting on horseback and herding, the Mongols would have remained a localized group of tribes doing what they always did.

    I think job ads that look for industry- or tool-centric knowledge automatically limit the teams that hire people who’ve walked the same happy paths (and unhappy paths) the existing team has always walked. Personally, I like a diverse team drawn from software covering many different industries for the insights into how software often fails in those other systems that might apply to the software in your industry that your company produces.

  • When load testing, look for the indirect approaches to add load.
    Before Genghis Khan would attack a walled city, he would burn nearby hamlets and villages and farms and would drive the refugees before him to seek refuge in those cities. The influx of hungry and thirsty refugees would deplete the stored food and the cisterns. Their presence would tax the patience of the city dwellers and the powers-that-were who tried to keep order.

    By an indirect assault of adding a burden, Genghis found and exploited weakness.

    When you’re planning your load tests and performance assaults, don’t just focus on the normal pathways into the application. No doubt those gates and drawbridges are well defended. Don’t forget to look for other mechanisms that indirectly impair the performance of your application. A Web service or API that only one client will use (for now). A component that only contributes infrequently, but importantly. Don’t forget to make those small parts of your application wail, too, to see if their problems can cause big problems for your application.

I’m definitely heeding my own advice in going to history books for management lessons in QA, but all the material you learn and all you take in becomes grist for the creative mill. Or the destructive mill. Whichever sinks your boat.

Comments are closed.

wordpress visitors