“Testers or Beggars”

What would you call a Test Team who himself is asking for the release to be passed on to them so that they can perform testing on it and can justify their salaries?

I believe you are confused. But please don’t be.
This is something very rare in software industry. Recently, one of my friends, working in a big multinational MNC, asked me that what he should do if the development team doesn’t want to pass on the release to them? I simply asked him to tell me three reasons, as per his mindset, that why this is happening. We have a lot of discussions after that but finally, we came up with something which was definitely a true picture of the mindset of a development team who is doing this rubbish act. After having a good brainstorming in all the aspects, we have categorized the following six points

1. They are not aware of what is the purpose and meaning of Testing.

2. They are feeling scary about bugs which the Testing team will find after providing the release to them.

3. They himself are not clear of what they have developed?

4. Since development cycle has expanded, the Testing cycle shrinks.

5. They are simply undergoing in frustration with the Testing team.

6. Management is not interested in Testing activities and believes it to be an overhead activity.

Now, after identifying these six points, I played a game with my friend. The game was very well known - “Who wants to be billionaire”. (In Hindi, “कौन बनेगा करोरपति”). I asked him to select the best option from all these points that what he thinks best suits for his team. But what he said was truly amazing and shocking. He has not selected any of the options and told me another option. And that was “All of the above”.

It was the challenge now for me to continue the discussion with that person. Still I am summarizing the solutions and the action items against each of the above mentioned points.

1. (They are not aware of what is the purpose and meaning of Testing?) -We should educate our self before saying that development is not clear with the purpose and meaning of Testing. It is the responsibility of the Testing Manager to aware and convinces them with the positives of the testing phase in the SDLC. So better to educate yourself before you educate someone else.

2. (They are feeling scary about bugs which the Testing team will find after providing the release to them.) -We should convince them that bugs will come in any software if it is being developed by the human beings. If they consider themselves as human beings, they should be open to accept the bugs. Also the bugs filed by the test team are on the product, not on the developer. Development managers’ attitude towards the bugs will also play a major role in this point.

3. (They himself are not clear of what they have developed?) -This is something which is very unrealistic. If the development is not clear about what they have developed, better not to develop the product. And if this is very harsh (that I have said), the much better is that testing team should refuse to test the release.

4. (Since development cycle has expanded, the Testing cycle shrinks.) -One of the most common and foolish point that the testing team is facing now a days. It happens something like

· Total Development Effort = 20 Days
· Total Testing Effort = 7 Days
· Total Effort (Development + Testing) = 27

On 15th day of the development phase, the new efforts will be

· Total Development Effort = 23 Days
· Total Testing Effort = 4 Days
· Total Effort (Development + Testing) = 27

On 22nd day of the development phase, the new efforts will be

· Total Development Effort = 25 Days
· Total Testing Effort = 2 Days
· Total Effort (Development + Testing) = 27

Finally, testing team has been allocated 2 days to test the release. And on top of it, the release will be passed to the testing team at evening of the 1st day and topmost of it is that the Release Description Document will be provided to the test team on the 2nd day evening.
The work around of this issue is to discuss the testing efforts with the client also and educate them about the testing phase in the SDLC cycle. This cannot be (and will not be) done by the development managers. So better to initiate this thread by yourself.

5. (They are simply undergoing in frustration with the Testing team.) -This depends on the previous experience of the development team. What is happening is because of what already has happened. So better to investigate a little bit of what has happened in the past and try not to repeat those actions. Sometimes a road less traveled is less traveled for some reasons. We should recognize the source of their irritation and change our own response.

6. (Management is not interested in testing activities and believes it to be an overhead activity.) -Change the management completely who is under impression that testing is an overhead activity, if possible. If not, start believing in God. He will help you and will show you some way to get out of it.

-- Sanat Sharma

“It’s ready for testing”

What do you mean by a developer if he says “It’s ready for testing”? Let me clarify this by adding some more words in it. If there is a conversation between a developer and a tester which ends with the statement “It’s ready for testing”, what does that mean?

There are three possible answers for this.

1. It’s ready for testing and the tester doesn’t know what needs to be tested but the developer is aware that what he has implemented and what needs to be tested.
2. It’s ready for testing and neither developer nor tester aware of what are the functionalities that needs to be tested.
3. It’s ready for testing and the tester knows each and everything about what needs to be tested.

Sometimes, I have seen that the developer himself is not enthusiastically releasing the build to the testing team. I believe this is the situation when the development itself is not clear about what they have developed. This becomes one of the most difficult situations for the testing team since they have to test the application without knowing what to test.

Sometimes, there are examples where development team tries to hide the things that they have developed keeping this fear in mind that testers can find some bugs in it. In this scenario, there is a huge understanding gap between the developers and testers.

Please note that in both the above two scenarios, there is nothing as such called system requirements documents or software requirements specifications. If that will be the case, no need to discuss the above scenarios as everybody will be clear about what needs to be tested or what needs to be implemented.

The best and the only feasible condition for a better testing is that tester should know what needs to be tested. Although this task is not an easy one for a tester but this can be achieved with a great enthusiasm and management support. So better to ask for

• approved system requirements documents
• approved software requirements specifications
• release description documents
• Unit test cases results

Communication plays a major role to achieve the only feasible condition that has been mentioned above. Remember management will not consider the issues that you have faced while testing. Management only knows the matrix and a bad matrix with so much number of bugs filed by customer will create a bad image for the test team and a good matrix with so much number of bugs filed by the testing team will create a good image for the test team.

-- Sanat Sharma

Are you good or too good?

Most of the time, I have seen that if you are good, you will be assigned the work. If you are very good, you will be assigned most of the work. But the question is what if you are too good?

Well, definitely you will not answer this question like “if you are too good, you will be assigned all the work”. This is because of the way of the question series by which I have started this blog.

Somewhere in one of my previous company, we have a person who was definitely a sound one in all the areas. Here I am referring to areas like – Coding, Testing, Marketing, Technically, management etc. etc. etc. I mean that guy was a legend and a right person at the right place. At that time, this guy had a rich professional experience of more than 15 years. But some of his colleagues or in fact subordinates, didn’t like to put the topics on the discussion table in front of him. Those useless guys always said that he will start his “philosophies” and will waste our time.

Once I have a problem while testing and I discussed that issue with all my senior management. But I was still confused about what to do. I straight went to that guy and we discussed about 1 hour for that problem. After coming from that meeting, the way I managed that particular issue was awesome and most of my colleagues were not aware of the fact that this all was due to that legend guy.

Later as the time passes, I have seen that only those guys worked with that masterpiece who himself are too good in their areas. That means most of the managers (or subordinates) that have a lower frequency cannot even sit in front of him.

This is a fact that when you have a professional experience of more than 12 years, you should maintain a class in your domain. But what if you have only 6-7 years of experience and you are somehow started creating your own class in your expertise area. This is the time frame when most of your managers (or subordinates) will see you from their eyes wearing a jealous sunglass.

Those who think or seek to express themselves differently are marginalized early. I do agree that no one can be good for long if goodness is not in demand.

But we should never forget that only dead fish swim with the stream.

So the whole episode has turned up to a final law which I will call –

The great Law of work: If you are good, you will be assigned all the work. If you are too good, you will get out of it.

-- Sanat Sharma

Group vs. Team

Till date, I have worked within different teams in different organizations and if I check the number, I would say it must be around 15 teams. But recently, while going through a blog, I came to know the difference between a team and a group. That blog makes me think that whether I have worked with teams, or groups or a combination of team and group. Finally, I tried to concentrate on my current assignment and still searching the answer that whether I am a part of a team or a group.

A GROUP can be defined as any number of members considered as a unit. On the other side, a TEAM is defined as a cooperative unit. This is really a true fact that most of the managers are not clear with the differences between these two terms. And that is the reason they fail to manage a unit which becomes a group due to mismanagement. A best management can transform a unit into a team.

Just going through my past experience, I have worked as a part of team in 80% of my projects. As a team, we worked for the product not for the individual egos. We shared the responsibility of the product and not trying to blame anyone for the bad quality of the product. And in all these teams, management plays a major role to keep the spirit high of the unit so that the unit members can work as a team not as a group. There are n numbers of factors that can map a unit towards a group but if the management is effective and efficient, they can divert their unit for a better team.

One should understand that coming together is a beginning, keeping together is progress, and working together is success. So better to go for cooperation, not confrontation.

-- Sanat Sharma

Who is your customer?

Wow … After a long time I am back with a new blog.

Actually, I was busy in a training CSTM (Certified Software Test Manager). I have gone through the training and exam and waiting for the results. Hope for the best ….

Now let’s come straight to business.

Few times back, I was discussing one of the bugs that my team has found while performing testing for specific software. After analyzing the bug, the developer was not agreeing that it is a bug. Although the bug was a valid one but as usual the developer was not agreeing.

This is not the end of the storey. Finally, I got something from that developer that totally makes me feel like what the hell this is going on. The developer said that “We will not consider your bug as a problem in the software and at any cost we will try to convince you that this is not a bug. Although we are aware that this is a bug but still we will not accept. And if, by chance, we have to accept it as a bug, we will change something in the code which will temporary resolve the issue and will satisfy you. But the problem will be resolved permanently only when the bug will be reported by the customer”.

This was something very strange that I heard from any developer and that too in a so open way. But in my opinion, the fault resides not in the developer. It is the development management part to consider the testing team as their first customer. In this scenario, I would expect from the development managers to transfer all the testing-development knowledge and information to their sub-ordinates and convince them what you mean by the Testing.

But one more interesting question that is hitting in my mind is “What would happen if the management is the only creator of this mentality”. Keep thinking.

-- Sanat Sharma