We come to Chapter 3 Attack By Stratagem, I like that translation. Maybe one day my Chinese will get good enough so I can read the original, but that’s a long time coming, I have enough trouble reading printed characters never mind calligraphy. I may wander my thoughts a bit here, my apologies, maybe I’ll clean it up later. While QA doesn't really need to attack, its usually good diplomacy to not go on the offensive in a project, remember War is the last resort to Diplomacy so always try to work things out before going on the offensive.
First in this chapter comes some very good advice “the best thing of all is to take the enemy's country whole and intact; to shatter and destroy it is not so good.” So much for a scorched earth policy. But the important thing is to take from the enemy what was theirs and subsist on it. Not that Development should ever be considered the enemy, but going to Dev-Land and seeing their resources, and what could be useful in testing, is a good strategy. In some respects consider the area of a bug that has been fixed has been left alone, we are reclaiming or recycling what the Developer left and used to do his work. Reusing tools is not only good policy but is good for the environment too! Just as “it is better to recapture an army entire than to destroy it” you do not want to waste resources of any kind, including intellectual resources, make the Developers you work with your friends, get them on your side and in your army and they will help you against the Bug Enemy who comes to frustrate your efforts to complete your task.
I would like to point out, in this section is one of the lines Bruce Lee utters in Return of the Dragon, “my style is fighting without fighting”, originally written here as “Hence to fight and conquer in all your battles is not supreme excellence; supreme excellence consists in breaking the enemy's resistance without fighting.” Cool stuff.
Part of the thinking here is to deal with the enemy without engaging forces, in planning “the highest form of generalship is to balk the enemy's plans”. This can be done early by marshaling your forces and preparing for as many contingencies as possible in the project. In the footnote to this quote Ho Shih puts this very clearly: "When the enemy has made a plan of attack against us, we must anticipate him by delivering our own attack first." Don’t wait for the bugs to appear, anticipate them, prepare for them, plan for them and defeat them first. Know which areas of code have been rewritten, touched, added, deleted and or modified and focus on them; when I have worked on code common to multiple platforms I focus on that area first, before the individual platforms, because I know the changes affect more areas. If the code does not work properly on both, that is going to be evident very quickly, if there is a need to delve deeper that can be done individually as well but it will be a judgment call on what is more important, something that comes easier with experience.
To recap some in the original “Therefore the skillful leader subdues the enemy's troops without any fighting; he captures their cities without laying siege to them; he overthrows their kingdom without lengthy operations in the field.” Do not directly engage the faults of a project, anticipate them, and do so in a way that is economical to you; do not have QA resources testing some area that will not work if it’s known, just to see how much is unaffected. Do not “siege” bugs by using multiple people to try and approach the bug to see where it might be, and if there is a way to get more data on it (there may be cases you need to do it, but this should be a rarity IMO). Try and find the issues quickly, simply and once documented move on to the next areas under test, using resources in one area and one area only causes delays the project may not have. Attack with one or two resources, don't pour everything you have into the "siege", using Pairwise Testing works, but not the whole department. It may be useful in some cases but not all.
Now this gets me to something new, in laying siege to “faults” there are resources, and these resources are finite (if not, I’d like to work for your company) so just as there is a strategy to use your own personal resources on a bug so to are there resources that need to be effective on a project. Part of being a Manager, Lead or whatever titles the person in charge has means knowing how to allocate resources, hopefully effectively. The numbers are Sun Tzu’s not mine, so take them with a grain of salt.
- “It is the rule in war, if our forces are ten to the enemy's one, to surround him”. If your project is small and you have the resources then do everything you can, attack the project from multiple points at once and test everything by overwhelming it; though I admit this is probably a rarity.
- “..if five to one, to attack him…” This is getting closer in a ratio of resources to project points, not as many people to work with, but still very manageable.
- “…if twice as numerous, to divide our army into two…” When dividing resources make sure to do it properly, in this respect one part of an army can meet the enemy head on, the other can be used for special tactics, so many focusing one group on Functional or Regression Testing and the other for specialized testing like Unit Tests, Automation, Stress or Load or whatever else needs to be done.
- “…If equally matched, we can offer battle…” This is probably the reality for many, where there is enough to get the job done, so plan it out and get it done, you won’t have much to gain by creative allocation of resources, stick with the plan you get from your team and what they can do, reprioritize only when necessary and make those judgment calls.
- “…if quite unequal in every way, we can flee from him…” Well you can’t really flee, unless you want to quit, but you may want to raise those red flags now on how late things will probably be by the time you are done.
Now there are also some ways to make sure your project can fail, I will only adjust these when necessary and most are pretty understandable as they are.
- “By commanding the army to advance or to retreat, being ignorant of the fact that it cannot obey. This is called hobbling the army.” Don’t keep moving resources around to meet day to day issues unless you are set up for it, if you are then you have the planning necessary and you are not reacting to situations, you are dealing with them before they arrive.
- “By attempting to govern an army in the same way as he administers a kingdom, being ignorant of the conditions which obtain in an army. This causes restlessness in the soldier's minds.” Don't overstress your resources either, setting impossible deadlines or work on your team, listen to them and know when the grumblings are real and not just a sound off of something else. If you don't know the mood of your team, you are not in sync with them.
- “By employing the officers of his army without discrimination”. This is a warning to put the right person on the right job, match skills to the task at hand.
One last thing that is mentioned here and I can bring this to two words “Know Thyself”. Finishing a task comes down to a couple of things;
- “If you know the enemy and know yourself, you need not fear the result of a hundred battles.” Know your abilities and what it may take to deal with the bugs you find and you will succeed.
- “If you know yourself but not the enemy, for every victory gained you will also suffer a defeat.” Knowing your abilities but not what it will take to determine what a bug is and you can not only waste time, but yourself, in trying to determine something without reward. True there are learning opportunities but these should be done when a schedule allows, when you have 2 days left in a project and you need to learn Java to discern a problem in the application this is not the time to do this yourself.
- “If you know neither the enemy nor yourself, you will succumb in every battle.” If you are unsure of your abilities and what it takes to determine what the bug is this is what I call being over your head, ask for help or come clean with your manager on what you know or don’t know. Don’t be the person to bring the project down, that will not earn you any friends.
I do like this quote here as well attributed to Chang Yu: "Knowing the enemy enables you to take the offensive, knowing yourself enables you to stand on the Defensive... Attack is the secret of defense; defense is the planning of an attack."
Finally, 3 down!
No comments:
Post a Comment