Testing With Sun Tzu - Chapter 2

Now that you have enjoyed Chapter 1 – Laying Plans, we come to Chapter 2 – Waging War; which strangely is not really about war itself, but what it takes to do it.  I may make some allusions to certain current political situations, but if so and they offend you my apologies, I am just trying to draw parallels and any judgments made are my own.

As this part starts out there is a distinct drawing of men per chariot, this is done to give a method by which to structure the army, the structure was determined within Chapter 1.  What this gives is a method by which you know the breakdown, and how it fits into the framework that was determined early on.  In a project you have a strategy and a framework that will be what you work with; then you flesh it out with numbers and actual details, basically going from the general to the specific.  In writing out a general SWAG (simple wild assed guess) on how much time a certain component may take to test, to then determining the steps taken to do the work, and how much time each of those steps will take.  There is also a requirement that the soldiers must have enough provisions to carry them a thousand LI; a LI is generally 2.78 per mile today, so you have to not only make sure of your details but that you also have the stuff to get you there.  Sun Zi went into detail on what it takes to get an army somewhere, including expenditures on the home front, he was nothing if not detailed.

That stuff will vary by culture, whether its coffee, tea, Mountain Dew, Lucozade, chai or whatever Code Monkeys like these days.

Sun Zi also realized that a long term battle can cause equipment failures as well, “if victory is long in coming, then men's weapons will grow dull and their ardor will be damped.”  Just as in a project, the longer it goes on the more tiring it can be and oftentimes the more people will just want it to be over.  I’ve been on long projects, some extending immediately after release to a maintenance mode, right when you also need to be preparing for the next project, and this can be difficult.  Planned right it can go well, but again this is where you either plan properly and you can succeed or you plan badly and you fail, having the milestones in the project to know where you are going, and whether or not you are on your way to victory (a good release) or defeat (you’ll be spending the next few weeks working late nights and weekends).  To stay sharp and on focus with the project means making sure you know your own limits, as well as keep on top of anything that will push you off track, don’t rush through the project but don’t drag it on either, it’s a delicate balance that takes experience to realize and understand. 

 “Again, if the campaign is protracted, the resources of the State will not be equal to the strain.”  Here is one I am going to make a dangerous parallel on.  War is an exhaustion of resources, of all kinds, so you want to use them effectively.  In a project if there are to be Unit Tests and Automated Tests make them effective, not just to have them, but make sure you are going to get use out of the Tests not have them in your bag of tricks and use them as resume fodder.  If there is a GUI that needs tests get it done, no need for fancy stuff just because some new tool came out and it would look cool to know, unless doing that cool thing will also save you time on the project, if you get no efficiency from the work it may not be worth doing.  Now being American I can look at the current situation in Iraq, notwithstanding my own views, taking a look at the timeline there were definitely things that went wrong with planning there.  But just as important, as recent election results have shown, not only was short range planning off, and generated a larger mess than it should have been, but the long term planning in keeping the people who should be supporting this was also lacking.  People need to believe in the project and be on board with all of it, get buy-in, even from those who may not agree with you, the best way to look at a project and a plan is from many different sides, and then make a decision using all the information on hand.  My last comment for now on the whole Iraq situation is “There is no instance of a country having benefited from prolonged warfare.”

There is also a lot in this chapter about foraging in the enemy’s lands, using his equipment captured in battle to augment your own forces and rewarding your own forces with spoils of war.  Hard to make a good parallel here, but I’m going to try anyway, what can be used are tools developed by Developers.  Yes, they actually do test their stuff, well a lot of the ones I know do, and they may have a tool or script that they used to make sure their stuff worked.  Use it.  Keep chatting with them about the work they did and how they did something, it could be useful for you.  At least Sun Zi was reusing chariots, not that I have room in my cube for one, but it would be a heck of a conversation piece.

Just as is said - “In war, then, let your great object be victory, not lengthy campaigns.”  Don’t let the projects extend more than they have to, the reason for making the project plan is to have a way to measure progress, but also to keep the project constrained into a time that will give it time to be completed.  While it’s often been said that “if I just had a little more time to test I could find all the bugs” well in reality that’s just not possible.  Again avoid the length campaign, sure there may be one or two bugs that get left in, that is the unfortunate part of the work that is done by Quality Professionals, what is best to avoid is the serious bug that will completely ruin the experience of all Customers when using the product.  It’s risk mitigation, if a test suite is run on a component 20 times and in the last 5 times no new bugs have been found, with no changes in the code, then its unlikely that running it one more time will raise that bug that will stop the product going out the door.  It may, but it’s like gambling, if you have confidence in your tests and test suites that you know nothing will be found.  Risk Mitigation is an important part of the business, but it also takes a lot of experience in being able to do it properly and efficiently, I know I am still learning how to do it and I’ve released a lot of software.

Just remember that the QA Manager or Project Manager or Lead or whoever is in charge is the one who will eventually make the call.  “Thus it may be known that the leader of armies is the Arbiter of the people's fate, the man on whom it depends whether the nation shall be in peace or in peril.”

2 down, 11 to go!