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.