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!