Sun Tzu Was a Tester??
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 supreme art of war is to subdue the enemy without fighting.”
“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.”
“Let your plans be dark and impenetrable as night, and when you move, fall like a thunderbolt.”
“Victorious warriors win first and then go to war, while defeated warriors go to war first and then seek to win”
“In the midst of chaos, there is also opportunity”
“The greatest victory is that which requires no battle.”
“There is no instance of a nation benefiting from prolonged warfare.”
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.”
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.
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.