Response on Go/No-Go to ship

Questions?
Michael Bolton posted and excellent article called Blog: When Testers Are Asked For A Ship/No-Ship Opinion which made me think and respond about it. I started with commenting on his blog and during that I came up with some thoughts I wanted to share.

Reading this story raised some questions for me I normally are aware of only never asked directly. Perhaps because when dealing myself with it; it is too close to me; the project is in stress. I agree with you that we should not make the decision shipping. Here some questions I have as response to the project manager whether to ship/or not:
- Where did we miss providing enough information? If we provided the proper information she would be more conformable.
- Why did she ask that question at the end of the project and not during the project?
- Why did not we guide her to ask “valid” questions?
- What could we do better to avoid discussions and questions like this at the end?

Do you notice that these are questions to myself instead directly to the project manager. if you have to change, first think what you can do. What value you can deliver. And also when. Looking at these questions, there is more then just providing test results. You have to communicate on other items also. In this case, which message will you have to bring and do you have mutual understanding on this.

I’m sure there are other questions to ask, even more answers to be provided. In my opinion you posted here a basic rule. When thinking further on this, based on this question to ask or not to ask, testers have to deliver all kinds of documents/ metrics and so on, just to “help” the project manager making decisions.

The bright and dark side
The bright side is not having all information and asking the team. Only the moment is “too” late when you get this question at the end. It is a bright situation since you are not exaggerating the documents you deliver and you have time to adapt to the situation. You must check continually if you provide value.

I believe there is another dark side. The dark side is asking the team “all kinds of information not knowing yet it will be valuable or usable and still I need it just in case I come up with questions afterwards forgetting that providing information cost time and resources not delivering other valuable products”.

What I have seen in the past was to gain control by collecting all possible information. Sometimes collecting information is not that bad. It becomes bad when you communicate about it and no one is waiting for it and you have to explain they should.

Awareness
If you have to explain the value of information afterwards, then you are too late. You have to guide them and help them to understand the information you create/ provide. You also are responsible only to deliver that information which is needed/values to the product directly or indirectly. This means you have to communicate and interpret the behaviour of the stakeholder.

To me, testing is more then only finding issues, or proving functionality works. It is also a process to make the results you find be accepted. You must be aware that you have to deliver that information which is requested and make sure that vision about responsibility is agreed upon. Perhaps keep checking if the information you provided is valuable and also understood as you meant it to be understood.

Go/No-go?
Are you the messenger for the GO/No-Go advice? I believe you are not the decision maker on this. You should provide information the decision maker can make that decision. Sure, you should help him/her. Only by providing information within the proper context. You also have to explain and guide how that information can and should be used.

If a question like this is coming from the project manager, you might see that as a sign you did not provided the right information and or guided her/him through the information you provided. Instead of asking question to the project manager, first start asking them to yourself.

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.

Do you change your testing strategies?

Just out of curiosity I'm wondering if you change your testing strategy. Is there room for change? Are you willing to change? Are your brave enough to change?

Deliberately I'm not asking for the need for change. Because of the current recession I think there is an urgent need to change. The question is what should be changed?

In many projects, people are working with proven technologies and methods. Some of the methods are very useful to cover all risks and measure the quality proved by those methods. Some methods are useful as they rely on best practices. Some methods are necessary as organizations are forcing to use those kinds of project management methods.

In all cases those methods are used to solve problems for organizations. I'm just wondering if there is time enough to keep using those solid methods. Is there budget enough to measure all quality? Are resources and skills available to make it a success using those methods?

Perhaps it is time to change. With change I'm more thinking of a context driven test approach as James Bach, Cem Kaner, Michael Bolton and others are suggesting. If I understood that approach good enough the basis of that approach is defining the context first instead of defining the framework for the project first and the "proven" test method.

When thinking about the context and considering the time we live in now we might understand that resources are not available to make it a success. Because of a clear context decisions can be made to accept risks.

Under current conditions risks have to be taken. Accepting risks might lead to new opportunities since the focus is just there were the organization sees it challenges, opportunities and problems which have to be solved.

I'm just curious:
- Do you dare?
- Do you care?
- Do you have enough resources, budget and skills to continue as you did in the past?
- Or do you change?