Greater Saint Louis Area, Missouri, USA

Sun Tzu Was a Tester??

Strategically aligning with our customers needs!

Sun Tzu Was a Tester??

The Book

Sun Tzu’s The Art of War was written in the 5th century BC. It’s since been translated into many languages, and is used not just for warfare tactics, but also corporate interactions, sports, business relationships, and many other disciplines that require strategy and tact.

Once in awhile I run across a quote that seems useful for the QA space too. In some ways, software testing is a little like warfare. We’re fighting buggy code, tight deadlines, lack of resources or irritable co-workers.

So it might behoove us to see what wisdom we can glean from Sun Tzu as applied to The Art of Test.

Following are a sample of quotes taken from the book, along with their parallels to testing. A larger bank of quotes can be found here.

The Application

“The supreme art of war is to subdue the enemy without fighting.”

When working with others, we should understand that we’re emotional creatures. Everybody brings “baggage” to the workplace. Some of our baggage will paint attitudes towards others. If you feel tempted to lash out when someone slights you, it’s better to take a step back and think, “Why are they saying this?” Are they really out to get you or are they just for themselves? It’s probably the latter. Good communication is key–defuse the situation by talking and understanding what they’re really after.

“If you know the enemy and know yourself, you need not fear the result of a hundred battles. If you know yourself but not the enemy, for every victory gained you will also suffer a defeat. If you know neither the enemy nor yourself, you will succumb in every battle.”

It’s good to bite off more than we can chew once in awhile, because that’s how we grow. Sometimes, though, we take on way more than we can handle. This is either because we overestimated our abilities, or we underestimated the difficulty of the project. Understand what you’re definitely capable of, and what you’re probably capable of. Also understand that there are known-unknowns, and unknown-unknowns in software, and account for learning what those might be in your effort.

“Let your plans be dark and impenetrable as night, and when you move, fall like a thunderbolt.”

Oftentimes we may get excited talking about what we’re going to do and how we’re going to do it. I call this “Nerd Mode” or “Geeking Out”. Testing is exciting, challenging work, and sometimes we talk more than we actually deliver. Or, we say way more than our target audience needs, for understanding what we’re doing.
Instead, talk a little less. You’ll surely run into snags, and when that happens it’ll look like you’re quietly adapting your plan, as opposed to flailing around if you’d broadcast what you were going to do, beforehand.

“Victorious warriors win first and then go to war, while defeated warriors go to war first and then seek to win”

If you start a testing effort not already knowing how to find some bugs, you may be fighting the wrong battle, and you may end up testing the wrong part of the system. To “win first” means to have a somewhat cogent plan of attack, while being able to adapt as you go. Not winning first means you’re just winging it.

“In the midst of chaos, there is also opportunity”

This is a great quote for consultants in general, but for testing it applies like this: If everything’s on fire, there are opportunities to land a devastating, calculated blow on one spot, and get rid of a lot of problems.
Most times, teams and companies are chaotic because of small decisions made before, that have built up a lot of technical debt, which then takes enough time that nobody can fix it, even if they know how. Staying out of the firefight, to get altitude on the problem and see what to actually do, is very valuable.

“The greatest victory is that which requires no battle.”

For testing, or for test automation, the best solution is one that requires no action. Either by not testing, or by not writing new test automation.
Instead, the solution lies in communication. Talk with people at the requirements stage and identify rickety places that could hide bugs, and they’ll be considered and fixed before the first line of code is even written.

“There is no instance of a nation benefiting from prolonged warfare.”

Morale-draining death march releases suck. I’ve been through many. A continued string of huge big-bang releases is no way to foster a good relationship with your customers, or high morale with your team.

Strive for short, targeted wins. A smaller dopamine hit from a successful release is better than none at all, and having to furiously break/fix a release once it hits production.

“Move swift as the Wind and closely-formed as the Wood. Attack like the Fire and be still as the Mountain.”

Similar to testing personas, you can adopt different strategies at appropriate times. Avoid sticking to one type of testing–mix it up, and share tips with others.

“Treat your men as you would your own beloved sons. And they will follow you into the deepest valley.”

Managers: I know you know testing is hard. If you do nothing to foster camaraderie with your team members, you will lose their heart, and then their spirit, and their body, possibly to a competitor.

Domain knowledge is hard to earn and easy to lose. Just saying.

“When the enemy is relaxed, make them toil. When full, starve them. When settled, make them move.”

When we test an application the same way each time, it might seem like it’s stable, but we’re really not putting it through the paces. Change up some things–use random data, or special characters, or something different every time you test. Hit it rapidly, make it work hard. The more variety you use the higher the likelihood of finding a bug. Don’t be afraid to fight dirty.

“There are not more than five musical notes, yet the combinations of these five give rise to more melodies than can ever be heard.

There are many ways to test. Some people will look for specific kinds of bugs, and everyone has their own style. When we mix different approaches together, there will be new approaches that show up as a result–things that neither person would think of by themselves, but together form a brand-new strategy.

“So in war, the way is to avoid what is strong, and strike at what is weak.”

If there’s a place in the system that’s been well-tested, don’t focus a lot of effort on it. The bugs likely aren’t there. Rather, they’ll be where the system is weak–where code was written hurriedly, or written by someone who is known to leave certain types of checks undone. Where requirements weren’t detailed enough. Where end users have control of what data can go into the system. Consider what weak points are in your system, and test accordingly.

“To win one hundred victories in one hundred battles is not the acme of skill. To subdue the enemy without fighting is the acme of skill.”

The best testers are the ones who can communicate best. This goes back to using words to eliminate bugs before code is even written. The code quality metric goes WAY up when this starts happening.

“Who wishes to fight must first count the cost”

Many testing efforts either fail or get drug out because we don’t correctly estimate the time and money for it. Determine first how long (and therefore how much) it will take to perform the testing, before beginning.

“One may know how to conquer without being able to do it. ”

Some may know how to test without being able to really do it. Strive to be a person who contributes ideas, but also doesn’t have a mental lockdown as soon as an application is in front of them.

“Rouse him, and learn the principle of his activity or inactivity. Force him to reveal himself, so as to find out his vulnerable spots.”

With exploratory testing, be aware of what else the software is doing, in response to your actions. Is there a pattern to it? Are there any oddities? Do either of these reveal a place where there may be a bug?

“Therefore, just as water retains no constant shape, so in warfare there are no constant conditions.”

Be fluid all the time. Don’t do things the same way all the time–adapt based on what’s going on, and you will be successful.

“By reinforcing every part, he weakens every part.”

Junior automators may try to “Automate All the Things!” but that rarely goes well. The more automation you have, the more you have to maintain. When you’re spending all your free time dorking around with the tools, you’re not contributing to quality.

“If you fight with all your might, there is a chance of life; where as death is certain if you cling to your corner”

If you stick to a particular way of doing things, the trend of software is that you’ll be obsolete before long. Software changes so much that we can’t afford to zealously guard a toolset or a methodology. We have to push into areas that we’re not familiar with and always keep moving and learning.

“The general who does not advance to seek glory, or does not withdraw to avoid punishment, but cares for only the people’s security and promotes the people’s interests, is the nation’s treasure.”

The spectacular manager won’t use the team as a step stool for themselves. Rather they will seek to encourage growth and camaraderie among the team members.

“You can ensure the safety of your defense if you only hold positions that cannot be attacked.”

When developing test automation, it’s important to not architect in a way that causes lots of unstable behavior or a ton of upkeep. Keep things really small, very simple, and “unattackable”. The less time you spend fooling with your automation, the more effective it, and you, will become.

“If those who are sent to draw water begin by drinking themselves, the army is suffering from thirst. One may know the condition of a whole army from the behavior of a single man.”

If your team is populated by people who know a lot but don’t share the knowledge much, the team will suffer. Nobody knows everything about testing. Ideas must flow for you and your team to be successful.

I’m Done

You know what, I had to delete like 50 more quotes because I’m kinda tired of typing 🙂

There are lots of other abstract ideas that can come from The Art of War, and I encourage you to find where quotes can apply to your work.

If you’re looking to get strategic about your testing, it’s time to schedule your free 15-minute discovery call.