Testing with Sun Tzu - Chapter 6

Section 6 is all about Weak and Strong Points.  This is about finding the places where you can attack an enemy, or to see where the mistakes are going to be, in project parlance this would be equivalent to checking for failures.  A good thing for a person in QA, or QC, for that matter.  It also ties in to the other sections which focused on offense and defensive postures (Section 4), Energy (or direct/indirect measures) (Section 5) and now when there is an understanding of how to position yourself and probe for weakness – you need to strike.  At least in a military sense.

Sun Tzu said:  Whoever is first in the field and awaits the coming of the enemy, will be fresh for the fight; whoever is second in the field and has to hasten to battle will arrive

Exhausted.

A pretty easy one for any person coming onto a project, if you come in from the beginning then you are able to handle the work and can do it at your own pace, come in with 4 weeks remaining to do a whole project-ful of work and you will rush and exhaust yourself.  In one respect this is a good way to think of when QA should be brought into a project, come in at the beginning and you have a grasp of the overview and the work necessary to be completed.  Documentation, or any necessary items that must be done, can be handled with enough time to meet deadlines, or aid in the planning of the project.  Come in late in the project and its all catch-up.  QA available and involved at the beginning can generate a Test Strategy, Plans, Cases, Scripts or whatever is needed; come in just before a release build is made and it’s a rush to get things in place.  Make sure you have the time and resources available and be able to learn about the project, getting thrown in will assure that you will be exhausted at the end, and regardless of all the Herculean tasks accomplished by others, and you may find that it was not your best work or at all something you want to be associated with after.

Therefore the clever combatant imposes his will on the enemy, but does not allow the enemy's will to be imposed on him.

Another reason why QA should be involved at the beginning, or in some cases the way to be sure that you have input into the project and not let the project have input into you.  Impress QA on the project; do not have the project impressed on QA, which will always be a losing battle.  Just as the armies of centuries ago positioned themselves to the place of greatest advantage, putting QA in a position where it is overwhelmed only leads to failure.  As has been said, be aware of the layout of the field, the position of your opponent and see the strong and weak points in order to predict the work that will come.

Appear at points which the enemy must hasten to defend; march swiftly to places where you are not expected.

Think ahead.  Not much more to add to that.  Might be a good thing to keep on my white board, but never let the current situation focus you only on the moment, be aware of what is around you and coming.  That is what separates the men from the boys, so to speak.  Its also what makes a great manager as opposed to a bad one, knowing what is coming into the department after the current project and keeping your team apprised of it while making sure they can do the current work makes their lives easier.  When your team is happy you are happy, and when you are happy then work is a much nicer place to be.

 Hence that general is skillful in attack whose opponent does not know what to defend; and he is skillful in defense whose opponent does not know what to attack.

Basically the Art of War in one sentence.  It’s also a way to think of planning, as I have mentioned previously be aware of all the needs, this reinforces the way to anticipate changes in the project.  Just as there is the need to “think out of the box” for determining a bug, so planning requires similar thinking.  I am a big fan of planning, but its also the process in which the planning is done, I document a lot of the process but this is one area I am always bad in documenting, because I know how I would plan a task, but its not always the same as someone else so why document my personal method?  Because someone may actually be able to improve their own by knowing what I do, but by the same token I am now skillful in planning when the project I am on doesn’t know the plan; or in some cases if the PM is lacking I look better in comparison.

Knowing the place and the time of the coming battle, we may concentrate from the greatest distances in order to fight.

Knowing when the final test effort will be, no matter how long, gives the time to plan.  Prepare ahead of time, everything you need, and keep an eye on those resources.  Plenty of times I have had to pitch in on an emergency situation because the main project is running and something came up but I cannot take a resource away; I’ve also tested multiple builds with different bugs to verify at the same time but I don’t suggest that.  Knowing when you are due for a release and how much work is left, keep milestones along the way; its a good way to have an idea of what is going on, will help in being able to say at any time – we can ship on that date.  I always try and keep a pulse on where things are and how they are going so if I am asked I can give a status, or at least know who needs to give me an update.  Knowledge is a powerful thing.

All men can see the tactics whereby I conquer, but what none can see is the strategy out of which victory is evolved.

At the end of a project everyone can see the result, but not the path you walked on to get there.  That path may be a tough thing, and while its great historical data, knowing how many bugs were closed when does not always give you a good idea of resource allocation in testing and its results; I distrust pure numbers in a field where Risk Mitigation often involves some sort of feel for where the project is.

Do not repeat the tactics which have gained you one victory,  but let your methods be regulated by the infinite variety of circumstances.

…also…

He who can modify his tactics in relation to his opponent and thereby succeed in winning, may be called a heaven- born captain.

The five elements (water, fire, wood, metal, earth) are not always equally predominant;

Be flexible, the project plan that worked for the last release may not work for the next, be aware you will need to change strategy at some point.  Just as I said history will not always give you good numbers, so you should be able to look back and still be able to see what worked and what did not.  Did doing piece A before piece B give the result we wanted?  Was there a need that came up for automation that took up time?  These sorts of things should come out in a retrospective or a post mortem, in order to improve the process, but more often than not most companies just jump into the next release.  Being a believer in the power of history its worth taking some time to discuss the project, not with heated emotions but a little dispassionately, to get what worked and what did not out in the open.  Advocate for what is needed after the discussion, but let everyone have a say as to what they thought went well or not, you might be surprised at what some people come up with.

Oh yeah..almost halfway done!  6 down.

Thanks for reading!

Testing with Sun Tzu - Chapter 5

Chapter 5 is about Energy.  Following on from the last blog’s commentary let me pick up a theme I sort of touched on, which was brought out in the comments, testing in a passive or active manner.  Think of that as energy.  You have potential (stored) and kinetic (moving) energy; you also have inactive (observation) and active (participatory) testing.  When performing test-y duties they can be done in a manner where you are actively using code or by having it run and checking results, or the environment, without any real interaction with the test scripts.  I am not advocating one over the other, at times I have run scenarios in either way depending on what I was testing.  While in this chapter there is a lot of discussion about men and moving them into battle, I am going for the spirit of the idea and while I may refer to men in the quotes, I will not talk about them as it won’t really relate; unless I wanted to talk all about managing.  Which I could, but maybe another time, I’m going to be jumping around in regards to expenditures of energy but relate it as I can to the quotes.

Sun Tzu said:  The control of a large force is the same principle as the control of a few men:  it is merely a question of dividing up their numbers.

I guess a more current version of this might be not biting off more than you can chew, take small bites, or even manage a large group as many small groups.  On a personal level, if I have a lot of work to do, then doing it in small pieces is much easier to control than trying to complete all of it at once.  When getting a project of work, doing 100% of it, and spreading your time across all of the components that make up that project doesn’t get it done any faster than focusing on one piece at a time.  Baby steps, like we used to say when I was a kid, don’t push yourself until you are ready, just take it slow and focus on what is in front of you.  Same way with a large project or task, take what is in front or needs to be done first and as its done move on, be like water moving around a bunch of stones, the water doesn’t crash into the rocks, well it might if it’s a deluge, but a stream finds a path through them of least resistance and deals with the path that requires the least expenditure of energy.

In some ways a project has an energy balance, or in game terms you have 100 Project Points, pushing yourself across the project you lose points as you move through it.  If you rush then you lose points pretty quickly, and unless you can get time to get those points back you will run to 0 and then it’s Game Over.  If you take time, find the right path, look for the Restore Points, allow yourself time to regenerate then you will get further than just running along the path and trying to reach the end.  Sort of like the tortoise and the hare, the hare may be quicker but may need to rest more, or become too confident at getting there first that he makes a diversion, while the tortoise moves along at a good pace and gets to the end.

The discussion on energy from Sun Tzu uses two terms Cheng and Ch’I, which don’t easily translate well to English, many Chinese terms have a lot of significance behind them which is not really a part of the definition but a part of the ideogram and what lies behind it.  A simple definition for Cheng is facing the enemy, where you march straight to the enemy and keep your face towards them; Ch’I on the other hand is movement, making diversions or changing direction in some form.  Cheng becomes passive as its just movement, a steady flow towards a point, Ch’I is activity where motion becomes part of the movement and the point can then be reached by many pathways.  Pretty much all I am going to do for this one, since it could go on and on, maybe a follow up later on.

In all fighting, the direct method may be used for joining battle, but indirect methods will be needed in order to secure victory.

To get work done in the project requires a path, that was determined within the project plan, to achieve those results occasionally means moving around the point or task and determine if maybe the direction to complete it has changed.  Do you use energy actively or let it collect until the end?  In other words, expend and recharge or use it in a burst?  In some respects using it all at once can be useful, if your culture moves you in a direction where all testing happens at once, or if testing is done over time then alternately saving and expending energy will be the wise choice.  How you move and use your energy in a project is up to you, and will change according to conditions of the project and the company culture.  The important thing is to avoid burnout.

Indirect tactics, efficiently applied, are inexhaustible as Heaven and Earth, unending as the flow of rivers and streams; like the sun and moon, they end but to begin anew; like the four seasons, they pass away to return once more.

There are multiple approaches to the problem, think back to a solution made a year ago, would you make the same results now?  Has experience taught you that maybe a better way now presents itself?  Just as lessons learned are gone in the past, they will come again unless the culture that generated them has changed, just as the problems that arise can be infinite so can the solutions to resolve them.  But just as there is more than one way to plan a project, so there is more than one way to test a project, one may be better than another in a given situation.  A project that has limited resources would be tested much different than one where you have twice the resources, including automation capability, that in itself changes how the project would be handled once it undergoes test.  Still the point I made earlier, there is a certain amount of energy in a project, what changes over time is how that energy can be used and channeled.  A team of testers who are able to do Functionality, Exploratory and Unit Testing are going to be handled and worked differently than a group of Functional, GUI and Automation testers.  Understanding what kind of energy you have, and how it can be used to be most effective will help not only in smoothing a project, but even on a personal level allows better choices in choosing what to do and handle within the time allotted.  Know how much energy you have for a project, then plan it out to get to the end, but remember roadblocks may happen, when they do, be like the water and flow around them eventually they will grind down.

The direct and the indirect lead on to each other in turn.  It is like moving in a circle - you never come to an end.  Who can exhaust the possibilities of their combination?

It’s circular.  Like a point in a circle there are many ways to look at it in two dimensions, 360 degrees of looking actually, but if that point is now in a sphere you have a larger number of ways of seeing that point, use it to your advantage and consider how many ways to test then choose the right one for you.

This one was tough…but its 5 down!

Testing with Sun Tzu - Chapter 4

Chapter 4, I decided upon Chapter rather than sections, is on Tactical Dispositions.  Since this basically means determining where the other army is, and their condition, there is no straightforward way to match this, so I am going to stretch this into my general project planning scheme.

A bit of history.  Before the advent of rapid-repeating firearms, and the British line (the most effective 18^th and 19^th Century force of firepower IMO), armies would march around each other to determine the most advantageous ground.  This did not often end up in actual battles, at times after a day of marching the armies might go home, once gunpowder became part of the war machine this changed.  In the American Revolutionary War when the colonial army fought the British, who would form line, the colonists lost because they could not match the firepower, and shooting speed, of the British army.  The colonists took to hit and run tactics as a way of harassing the British and use their strengths, while the British formed line the colonists would back off and lay ambush somewhere else.  No matter how strong you seem, someone can always find a weakness.

Sun Tzu said:  The good fighters of old first put themselves beyond the possibility of defeat, and then waited for an opportunity of defeating the enemy.

If I am on a project and want to make sure it’s a success, a lot of the failures lie within me (or at least within my own part) if I have an equipment need or a schedule dependency that is critical but I do not raise it as an issue, then its my fault.  My job is to make sure EVERYTHING I need is in place; that my part of the project is on track, following up with other people, making sure they know my schedule and needs helps me get my work done.  In this case the enemy is Project Failure, not something to have on the permanent record.  If I do not want to see my part lose I need to make sure that I have everything I need to succeed, and win, as this says “old fighters would be sure to have their weapons and armies in place then look upon the enemy to see where the weakness may lay”.

I have had situations in the past where I got so bogged down in my parts of the project I did not talk to people and find out where they were, getting blindsided by someone’s late work did not make me meet my deadline.  I was late, and I also had to cut corners, as well as work some long hours, to make up the time, but in the end the blame came down to me.  Learning to watch how other people are coming along, listening in the status meetings for the tell-tale signs someone is not on time, checking in personally and seeing how things are progressing, all things I have learned on the front lines and in my defeats.

Security against defeat implies defensive tactics; ability to defeat the enemy means taking the offensive.

In order to maintain progress you need to know where your supporting documentation is, as well as any dependencies, programmatic or otherwise.  There is the “bunker mentality” of sitting down in a cube and doing work, occasionally popping up “prairie dog”-like in order to check on free food in the kitchen or see who is around.  See my previous example of why this does not work.  As a Manager on a project, the expectation is that you know where everyone is, or at least how to find out quickly what the status is; which also implies keeping people alert and doing their part of the project.  As a person assigned to the project, the better ones will know where other people are, sometimes even those who are not directly impacting the current work.  One of the better people I had working for me in that past knew not only where the people directly affecting her were, but the people THEY depended on, that way she could tell ahead of time what the impact of delays would be.

(Names are changed to protect the innocent….and not so innocent)

Since everything was connected it became easier to know whether Tim would have things done on time if Bob was a little late, by knowing where Bob was Sue could ask Tim where he would be and what Bob’s late work meant to him, Sue could tell where her deadlines would fall.

Sometimes taking the offensive means not just looking at the people and work ahead of you, but the ones behind them, seeing further ahead means being ready for surprises.  Think of how many war movies would be shorter if the man in charge had looked beyond the mass of men before them, or even to the sides, to see the sneaky group coming up that would be the surprise in the battle.

To lift an autumn hair is no sign of great strength; to see the sun and moon is no sign of sharp sight; to hear the noise of thunder is no sign of a quick ear.

Ignoring the part about hair, this fits in with being able to see ahead of you.  Just because you see the sun, doesn’t mean you should ignore the comet hurtling towards you from the other side.  Just because you can hear the thunderclap does not mean that you will hear the people whispering in the next cube.  I just wanted to add this one for effect because I like the wording.  But its also a good metaphor for being able to see the hidden things, and to not just use a talent directly, but indirectly.  Perhaps an early way of saying “think out of the box”?

In respect of military method,  we have,  firstly, Measurement;   secondly,   Estimation   of   quantity;   thirdly, Calculation; fourthly, Balancing of chances; fifthly, Victory.

Measurement owes its existence to Earth; Estimation of quantity to Measurement; Calculation to Estimation of quantity; Balancing of chances to Calculation; and Victory to Balancing of chances.

Who knew you could use math to win wars?  Especially at a time when really it was about numbers of swords and arrows, and I do mean more than just < or > in determining who outnumbered whom; my Algebra teacher would be proud.  Now these five items are interesting, and not just because of the use of them, but by using these five items in the right way there are some good steps of project planning.

• Measurement, originally this seems to be surveying and measurement of the ground, in this case the terrain of the project.  What is the environment?  What will I need to be successful in this environment?  Thinking this through is not only a good mental exercise, but helps in planning the project to its completion
• Estimation of Quantity, Measurement helps very much in estimation. which enables us to form an estimate of the enemy's strength.  In other words by taking measurements of what the project entails, we can then determine what it is we need, how much, when we need it and where we can use it.  In this case Quantity is both physical and it’s the amount of time needed to complete tasks.
• Calculation, and to make calculations based on the data thus obtained.  From knowing what it is that is needed and what time it takes to complete tasks, these can be used together to determine, do we have enough stuff and time to complete by the date?  If not, recalculate, and if so then we can go on.  Sort of a stop in the decision tree; or it may be circular depending upon how you look at it.
• Balancing of Chances, we are thus led to a general weighing-up, or comparison of the enemy's chances with our own.  Now that all the data is calculated, does it look right?  Can this be done, is there a nagging doubt that says step X will probably not work right, no matter how much we want it to?  This is where luck comes in, and its also the point where Guesstimation is either going to succeed or not.
• Victory, if the latter turn the scale, then victory ensues.  So if we guess right, then we are successful, especially if we make the right choices on the way to the end of the project.  Or as I like to think of it, if we get lucky we win the lottery.

Just remember when you live in a deadline driven environment the following is what it looks like when you are behind and the end of the quarter is coming.

The onrush of a conquering force is like the bursting of pent-up waters into a chasm a thousand fathoms deep.

4 down only 9 to go!  If you are enjoying this, or not, let me know.

Testing With Sun Tzu - Chapter 3

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!

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!

Testing With Sun Tzu - Chapter 1

Being somewhat of a historian I tend to look for parallels to things in the modern world with the past, perhaps its the illusion of connection or I am just bored, some days it is hard to say.  Still when I was driving around the mall this past weekend with my wife and son and looking for a parking space I started to think about a parking strategy, or was it tactics, then it hit me - what about my testing tactics or stragtegy?  Of course there are many parallels that work in the world of software and business, but I like Sun Tzu or Sun Zi, depending on your pronunciation.  I am sure this has been done before, but what the heck, I've never done it before.

Sun Zi is the man behind the treatise The Art of War.  While the Book of the 5 Rings by Miyamoto Musashi always has its place, I've also seen some use of the Art of War in planning testing, and its chapters line up well (while also giving me a lot of time to expound on them, think of it 13 more posts by me!).  But in the interest of history lets get things straight, Sun Tzu is actually a title that translates as Master Sun, his real name was Sun Wu, where Wu is the same character as martial (like Wu Shu or martial art), he lived by the Western calendar around 544-496 BCE.

Mind you these are my interpretations, your own my vary.

The first Chapter is about Laying Plans.  Preparing for battle and readying the army for conflict, but the most apt comment, and probably most used, is "All warfare is based on deception.".  Testing is finding deception, or the uncovering of deception if you will, faults lie hidden and must be brought out, the small bug may be a deception that requires more investigation to find the larger one hidden beneath.  Never let the enemy distract you, and yes I am referring only to the defects as the enemy not the person who created them, in my place of employment open warfare is discouraged, hopefully yours has the same policy.  Yes I know we have trebuchets in the QA area but those are strictly for amusement, we never launch them directly at people, on purpose.  Yet.

In Laying Plans there are 5 constant factors that are mentioned:

1. Moral Law
2. Heaven
3. Earth
4. The Commander
5. Method and Discipline

So lets take these in order.

Moral Law refers more to the ruler and in the day of Sun Zi was more along the lines of harmony, especially among the ruler and his people.  Keep the people happy and content, and they will follow their ruler.  Focusing on harmony is useful here, in that the Test Strategy that has been defined keeps everything in play, while a Test Plan is written for one area it should be in harmony with the others.  Tests should be done so that individual pieces (Unit Testing) are complete as well as the entire structure is done (System Testing) so that no plan overlaps another, no need to run the exact same test twice, and cases done in one plan complement another.  Nothing gets lost, or missed hopefully, providing for more complete testing.

Heaven, in the treatise is a reference more to the environment such as night and day, hot and cold, times and seasons.  This is a bit ephemeral for use in a test environment, I could say infrastructure but wait on that one, still there are some uses here.  Consider the schedules, the times the software comes in, the time of year, the Friday at 4pm drops that may require work on the weekends or on the holiday or even that snow storm that started up while you were reading email or even that annoying person in the next cube who constantly checks voicemail on speakerphone.  Much like the armies in ancient China had no control over the elements neither do we, except the guy using the speakerphone, and like it or not they effect a persons mood, so try to leave what is not work related out of the scheme and focus on the task at hand.  If something is frustrating take a few deep breaths and get back to a calm state, don't let external factors you cannot control get in your way.

Earth is the physical realm, such as distances between the armies, chance in life or death, security and danger.  In a modern implementation the infrastructure fits nicely here, make sure you have the infrastructure to complete the tests that need to be done, is the lab equipped to handle the project?  Are there security concerns?  Are there chances being taken with the tests that are being done?  What is the overall risk of delivery?  If an external group is involved in the project are they being taken into consideration, and should there be additional time added to a schedule to handle them?  There are a lot of considerations on just the physcial aspects of a project, thinking through them all is a good exercise, taking some time early in the planning phase to mentally walk through the entire project is useful.  Take notes on how the flow would go through the entire project, what would be needed and when, get input from those involved.  Its a small amount of time to spend on something that could be a roadblock later on.

The Commander was used to represent the virtues of wisdom, sincerity, benevolence, courage and strictness.  Mostly this was to generate an image of a good military commander who understood and cared about his men, while being an apt leader who can bring them victory.  While not everyone needs to be a leader, someone needs to be part of the crowd following, its good to look at what it would take to be in charge, are there skills needed to be the lead in the project?  What are they?  Do you have them?  If not, how do you get them?  Again, this is all about planning, and planning the Lead is also important, a person cannot lead unless they do not know what they are leading people to, sure they could but its not really effective and let's face it those people usually bring disaster with them.  Have the wisdom to know what you do not know, the sincerity to ask questions and give answers, the benevolence to work with others, the courage to stand up when needed and when things are not going well and the strictness to keep things on track without meandering all over.

Method and Discipline, the last ones, refers to the generation of the army and its structure, in addition the supplies and supply lines necessary to keep the army in the field.  Just like in Earth where the infrastructure needed to be put in place, its needs to be properly maintained, if a server is being used and it crashes how will it be replaced?  Personally I have spent time in my labs learning what I need to do my own server rebuilds, how many servers I have killed I can't count, but I know how to regenerate them as needed.  Understand what the test lab structure is, how to get replacements and be on good terms with your IT staff, who can give you that all important image disk to rebuild the computer with.  Know who is working on the project, and in what capacity, finding the Subject Matter Experts and checking with them on issues, or changes, can be useful.  Just as an army always changes in battle, so does the test lab and the tests during a release to QA, know what is happening underneath you and avoid surprises.  If the database is being restored on Tuesday, its probably not the best day to do some UI testing that relies on data put in on Monday.

Hopefully, I've made you think about some of this I don't have all the answers, I have the wisdom to know I don't, but I try to find them.  Before they find me.

Thanks for reading, and there will be more of this.  12 chapters to go!

Multi-Lingualism - One Testers View

I've been asked, and often seen asked, "I am a Tester (QA Engineer or whatever the title is) and I want to learn a language, which one should I learn?".  Well...

Answer: Whatever will help you in your job.  There is a lot out there, its like deciding what to learn for a second language, you learn one you enjoy or one that will help you progress, its the same with software and computer languages.  If you work testing Java apps, then learn Java it will only help you out, Scheme or Lisp no, they may allow you to understand jokes from some old programmers but thats about it; unless you work in a place that uses Scheme or Lisp.

For more keep going.

This is going to be a HOP (Highly Opinionated Post), and will cover my own career in this space, so bear with me.

I started in QA with no education in this field except what I had learned myself, some BASIC, some more Visual Basic, a little C and at the time I was hacking PPP and SLIP, plus some HTML.  I decided I needed something to help do things in a more automated fashion, and at the time the language of choice for that was Perl.  Over the years I have become a good Perl hacker, and can pretty much get to happen what I want when I need to, only now though I am doing it in an object orientated fashion.  I ended up using a few test tools over the years, WinRunner and LoadRunner, so I became familiar with their scripting languages because if you want to use them effectively you need to.  I used a Bug Tracking tool years ago called Clarity, for that I needed to be trained in their proprietary language, so I took their courses and got our system set up to run.  It worked well, but over the years I have also come to like Bugzilla - and what do you know its written in Perl!

Product-wise I spent many years testing web sites and multi-tier systems.  I have had to test ASP, Visual Script, use a tool written in Visual Basic, and databases.  Well, learning ASP was not all that hard, its just getting used to its syntax (could I code in it?  No.  But I can read and follow it...I've even hacked it to perform date testing).  SQL, that was a little tricky and I got one of those SQL in 21 Days books, that followed me around for years.  Windows Installer was another item we tested, as we were installing some Applications, so I got used to the syntax for running it on the command line, and then check out how to read its logs.  Java came into much more use as I worked, I started learning it twice over time, never got good at it, but hey I can follow it!  So testing Java Apps became easy.  Especially Java Apps that used databases since I already knew SQL.  In one job we started using JUnit, and that meant working with Java, it was some doing but I got some JUnit tests created and running.  Shell scripts were useful in a couple of jobs, as we needed to be able to work some packages properly, and there is just some stuff you SHOULD NOT do in Perl.

Taking a look back I started with very little, but what can I do now?

• SQL, can query, create, delete, destroy, manipulate and do what I want with data
• Perl, anything Perl can do I can almost do, not that great with Objects yet but getting there
• ASP, I can read, follow, hack and troubleshoot it
• Shell Scripting, can set up something to run what I want
• Batch, can set up Windows Batch scripts to do what I want
• Java, can read, follow and troubleshoot it.  Hacking is a bit different
• JUnit, can make a JUnit test since I can follow Java
• Perl, most useful tool I came across and its multiplatform!
• C/C++, can't code much in it, but I can follow it - great for Code Reviews!

Recently I started tackling Python, because at home I decided I needed some way to track my downloaded music videos, a bad hobby I know.  But what else was there to do with the tools I had but install MySQL and then add in a front end to query data, I used Perl before but wanted something graphical and Python seemed the next logical step.  So now I can add Python in my little bag of tricks.

If a project comes up and I need to work with something, learn about it, that is what is great about this industry, you can read all you want and there is always something new.

Note: I know Perl is listed twice, it's on purpose and you can make your own jokes about it.