The Art of War in Software Testing

Introduction

One of the things I like to do is checking for similarities between history or other methods and software testing. Recently I was heading towards my assignment and got stuck in a traffic jam. You have some of those days. A radio station brought again some information about some war somewhere. Like software testing, no war is the same. No test process is the same. I think there should be some similarity between war and test processes due to the fact they are build upon a mission, vision, strategy, objectives, leadership and a context.

Types of war

On WikiPedia I searched if there was some information about different types of War . On this site I found a table containing types of war explained. (see below)

Environments of warfare

In warfare the environment has a huge impact on the type of battle which take place. You have conventional and unconventional warfare. In conventional warfare an attempt is made to reduce an opponent’s capability through open battle. In unconventional warfare is trying to achieve victory through acquiescence, capitulation, or clandestine support for one side of an existing conflict.

Environments of testing

I think in Software Testing you also might consider conventional and unconventional environments. Below a shot how this could be presented.

Each type of environment has its own type of leadership and needs its own type of strategy and approach.

War strategy

In an old computer game (Civilization II) I learned about Sun Tzu. I understood that this book is a must read for any strategist. Sun Tzu: The Art of War In this book in thirteen chapters an explanation is given how the context of warfare an be defined.

The combination of leadership, environment and goal makes each war different. I think therefore there is a similarity between warfare and software testing. In software testing you also have different objectives, circumstances and resources.

Test approach

When looking at the thirteen chapters of The art of War there is some similarity which can be translated to testing. I tried to visualize it in the image below.

Similarity between warfare and software testing

Is there a similarity between warfare and software testing?
Perhaps there is, in both situations:

- The environment and goal has impact on the type of execution and leadership

- The chance for creating chaos is high

- Dealing with chaos should be part of the strategy

- The desired outcome is victory, only at the end you know about failure

- Best practices is not a guarantee for success, it depends, and most of the time on the context.

TestData Generator

A colleague tester pointed me recently about the importance of test data management and the recently offered site towards test data management: Testdata Management.

Behind one of his links there was a free test data generator: GenerateData.com
GenerateData.com offering a free test data generation tool with several functions to generate "standard" test data in several formats: HTML, MS Excel, XML, CSV and SQL.

Next to generate data online you have to ability to download the script which is under GNU open Source License.

I have to admit that this tool is easy to use although I think you have still to manipulate the data for your own use.

This triggers me to search for more opensource generation tools related to testing. A new world opened in front of my eyes, :)

Here some other open source tools:
dbmonster : can be used for DB tuning
benerator: performing load and performance tests
Database populator : Examines the table and populate it according to it (note: downloadable version is from 2004)

These seems somehow promising, perhaps in the nearby future I can try them sometimes.

All those fine test methods and approaches

There are people who think software testing is easy. There are testers who claiming to be experts in the testing area. There are companies who believe their tool is the solution for everything. There are program managers who know that mentioning a method in a plan and using templates solve all problems. There are developers who are able to use development methods as they were intended to do.

I cannot not believe we live in a world this beautiful. I'm a tester and somehow I'm an expert. In certain areas in certain conditions I know more about software testing then others. And still I'm eager to learn. This is one of my main goals. I like software testing as an occupation and as a way of thinking.

Only I believe this world is not that beautiful as it is. And we all know it. Most of the people are claiming that their methods, approaches and tools are just the way we have to work and then all problems will be solved. There are testers who work according those methods and are forcing organizations to change otherwise they are not able to do their job. They forgot that a method or approach is just a tool to help and can and should never be used as it is written on paper.

How often did you hear or did you mention that we should do this because it is: ITIL, CMMi, TMMi, Prince2, TMap, ISTQB, Agile, RUP, or whatever method/approach/ best practice? How often did you ask yourselves if it values the method or the organization?

As methods are often models how to handle things. A model is just a representation of the actual world. Models are fallible and therefore methods too. Using those methods as written makes you fallible.

Fortunately, because of human nature we are trying to avoid being fallible and we are striving for success. Preventing fallibility we adapt. We adapt our vision about methods and adjust our approaches. By doing this we have to be aware that we change the chosen methods/approach which supports the organization.

This is what makes software testing interesting for me; finding solutions under given circumstances reflecting against organizational defined methods and models using the boundaries of those methods/approaches/tools/best practices to provide information about risks and benefits for the organization when rules are broken.

Therefore software testing is not easy and we are not experts and there is not one solution. Testing is fun and should be done by people having expertise and gaining knowledge, able to adapt and having the courage to think out of the box, within the context. Testers should use their knowledge about methods etc. to value organizations instead of preaching their knowledge of a method or tool is the best solution.

Pretending to be green and not explicitly measuring it

Last year I already introduced on my blog "Ecoliability" as a potential new quality attribute. I still believe this quality attribute can be of use to explicitly measure how "Green" a company or software is.

On CeBIT green IT a entire hall was dedicated to innovations related to energy saving solutions in the IT-world. Looking at this site it seems those solutions are for a wide scale of potions, from efficient usage of processor time through cloud-computing or SaaS till hard ware solutions to save energy.

If organizations pretending or intending to be green; why not explicitly measure this? Most of the software testers like to talk about quality attributes when they need to test something. It is common knowledge that if certain quality attributes getting more attention in projects it have a positive influence on some attributes and a negative influence on others. For example increasing functionality could have positive effects on usability and efficiency only the sustainability and portability might be lesser.

Management make decisions on those effects. If this is so important for management to decide what to choose based on the impact on certain quality attributes this new quality attribute "Ecoliability" can also be of use and must be introduced.

If we start using this quality attribute it can help management to decide if they accept the costs on other attributes for being "Green" or forcing projects to look for other solutions. If being "Green" is a management decision based on a company’s vision we should help them making it measurable and therefore visible.

If you are "Green" you might think about this and start discussions about this new attribute.