Should Tester refuse to test if there is no specification?

This is one of the most notorious statements that one can argue with any of the development manager / Lead / developer and can convert the dialogue table into world war III grounds. But for me, this is one of the statements that provoked me to think about this immensely puffed up statement and then try to publish my views on it.

I will start this blog with one of the anecdote. In one of my earlier company, that I worked, I tested a GUI application for more than 4 months. After performing a rigorous Testing cycle on it, when we showed it to our customer, he simply said that this is something totally different GUI that I discussed from you. After having a lot of brain storming (and blame storming) with them, it has been decided that we will again develop that application. And this time, we will not only create the specifications but we will get it reviewed by our customer also before going for the implementation.

Now the fact is that initially, we, as a Testing team, we have no proper specifications. We are only following the instructions that our superiors are giving to us about the design. Moreover, we are following a treatment (or a prototype) created by some other company to test our application. But all went bad. The customer simply refused the application and we again started from scratch.

Now this could be stopped; at least at that moment of the Application Development Cycle, when the Testing started. Since I was not so experienced in Testing at that time, my manager should refuse it to Test without any specifications. But that didn’t happen and the whole team have paid price for that.

One of the core problems of Testing is the infinity of possible tests. And to create at least 50% of these tests, testing team required good, complete and proper requirements. The better we understand the product and its risks, the more wisely we can create more tests.

Most of the time, the Software specifications are usually not written to such details as to someone outside the organization can follow. The resulting software usually falls short of satisfying the specifications. The results can be even more costly in time and money than having the software developed/tested onsite. In this scenario, which is quite common now a days, creating the test cases will become a major challenge for testing team.

In my opinion, testers should refuse and strictly say “NO” to test if there are no approved requirements against the application. Sometimes, I have seen that if the customer fired any issue in the application, the management tries to put the testing team on the spot without even thinking over the requirements issue and complexities. Management should try to know why behind what.

To achieve better quality, build a better product – better code, better training, better support, best software practices and above all better documentation.

So, start thinking differently and refuse the release to test if there are no proper requirements. There are many who wants to make a difference but don’t know where to start. Better to start from here itself. Definitely it is a new and challenging challenge for test team but you should make a difference in how you view challenges.

It’s better to act smartly and intelligently for a testing team and refuse to test the application if there are no proper requirements documents. It is my personal opinion that if testing team continues testing the application without proper documents; they are doing well for nothing. Intelligence is not to make any mistakes, but quickly to see how to make them good. Grow up testing team, and start paying value to your work. Remember “VALUE HAS A VALUE ONLY IF ITS VALUE IS VALUED BY YOU”.

-- Sanat Sharma

Talk More, Write Less - TMWL

TMWL – Talk More, Write Less. Do you believe in this? It definitely sounds good but is not feasible in all the conditions for all the projects in all the organizations. There are n numbers of pre-requisites before even thinking of this statement.

Let’s come to very basic about this statement “Talk More, Write Less” alias TMWL. This simply means that better to discuss the issues, concerns, problems, topics and other stuffs rather than writing long emails for that. But there is a long list which one should think of before even throwing a single thought on it.

1. Is there a trusty and healthy environment within the team?
2. Is there any attitude problem in the team?
3. Is there a good communication channel established between the different teams?
4. How are the managers leading their team?
5. Is there any dissatisfactory team member in the team?
6. Is there any right person in the wrong place?
7. Is there is any wrong person at the right place?
8. Is there is any ego problem within the team or team members?

I have seen in many companies where I worked previously, that talk more as well as write more is the only feasible solution. Talk more will establish and maintain a communication channel within the teams and write more will give a confidence to the entire concern persons about what is going on concretely in the project.

There should be a trusty and healthy environment within the team. No trust within the team will definitely create an unhealthy environment in the team and consecutively TMWL will fail. Sometimes it is not easy to find out whether trust is there within the team or not. But we should remember that trust is invisible but the symptoms of its absence are not.

Attitude also plays a major role in the success of this philosophy. A positive attitude can make a difference in approach to life. It makes a difference in your relationship with people. So it’s better to work on team’s attitude first before going for TMWL.

In a team where there is no communication channel due to any of the reasons, TMWL is definitely a greatest process failure. Communication plays a major role in any project’s success or failure. A situation in which miscommunication or the complete lack of communication adversely affects the work as well as the relationships among the people carrying out the work. Good communication is critical to software project quality.Talk More will work only well if there are proper official communication channels established within the teams.

The success of TMWL also depends on how the managers are leading their teams. If the managers are defending themselves by offending the other team managers, they are adding a failure tag against TMWL philosophy. They should focus more on mutual goal of delivering high-quality software and less on shielding themselves from blame and proving the other side wrong. The managers should also work for the quality of the project keeping aside their egos.

Any unsatisfactory team member is definitely a danger key for TMWL philosophy. So if there is any team member who is not satisfied working in the team, try to fulfill his/her demands (if possible) so that he can also be part of team’s success.

There must be a right person at the right place. When you put the right person in the right place, you are helping your current staff learn from talented leaders (yourself included). TMWL will work effectively only when there is a right person at the right place.

So the whole story has turned up into an episode that it is better to work on other aspects first before going for “Talk More, Write Less” philosophy.

-- Sanat Sharma (सनत शर्मा)

Being your own Manager

A fresh, elegant and neat New Year 2008 has just started. And as a part of Software Development process, we all have some complaints with our Managers. We all are continuously criticizing our managers with n number of complaints. And the dilemma is that the counts of complaints are increasing day by day. Or rather I would say year by year.

But just think about it. Is it fare to criticize your manager for all the negative happenings around you? I don’t think so. That is why “Being your own Manager” is the only concept if someone wants to work progressively, effectively and consistently in the software environment.

One of the main insane states between the management and the other counterpart is due to the communication gap. It is a global fact that communication plays a major role for a project’s success or failure. Most of the time, managers speak a different language which is Chinese for the other counterpart. That means no one is able to catch the words thrown by the manager. Effective communication involves speaking the same language. A manager often speaks and understands in terms of return on investment (i.e. Value added). So if you want to be your own manager, better to communicate effectively with others.

In one of my previous company, there was no communication between the higher management and the middle management. Everyone was working in his/her own style with no control over the tasks, activities and processes. And the result was very ill-fated. The customer also understood the “Communication Gap” between the teams and they acted accordingly which was not suitable for the organization at that time.

Sometimes, due to this communication gap, management doesn’t care about what is happening in the project. But as a responsible software engineer, you should not take advantage of this scenario. Try to manage yourself in a better way and be a decision maker. If management doesn’t care that you are doing things poorly, at worst they won’t care when you start doing things well. So broaden the communication bridge among the teams for a better self management.

Decision making is one of the most important aspects that one should have for being your own manager. One should fix the problems what’s within his/her own control, rather then waiting for management to take action. But you should be dam sure about your decision and the decision should be in favor of the project. You should be in a situation to advocate your decisions and opinions.

Better thinking and better self management doesn’t need a management mandate. I have seen a category of engineers in all the companies saying that their manager’s task is to only make plans. That might be true but not in all conditions. I personally believe that the surest thing about the plans is that they will get failed. But that doesn’t mean that plans are not worth. So if you want to be your own manager, you should manage yourself to plan, not plan yourself to manage. Be more realistic in making plans.

A project manager’s job include making sure that all of the individual work activities in a project happen at the right time and in the right order. If they don’t, delays in completing one activity can set off a domino effect that cascades through the remainder of the project. So better to identify your work as soon as possible and then manage your tasks and activities in a sequential and proper way.

In fact by the last two years, I am also working on this theory. I am trying my best to be my own manager and I think I have done well till date. In my mind there was never a question about will I be able to do it? It was always how I can do it, till I actually did it. I made a difference in how I view challenges. And since I am still working on this theory, I made myself open for anything that works.

Finally, I would like to say that you can only manage yourself internally. But officially there must be a manager who will be your reporting person. But if you are not convincing with your manager, most of the time, you can’t do anything. But there is a solution. If you cannot change your managers, change the way they manage you. And believe me; this can be done but only by you.

The whole episode has turned up into a case study that better to be your own manager rather than criticizing your manager continuously. I believe if someone has guts, time management and knowledge about the subject, it can be done. At least you can try to attempt this theory because anything unattempted remains impossible.

-- Sanat Sharma (सनत शर्मा)

Bye Bye 2007 – One more Testing year passed

Wishing all my readers a Very Happy New Year 2008

One more year passed. Or rather I would say one more Testing year passed. As usual, I was calculating (or rather re-calculating) my achieved milestones for the year 2007 in the Quality and Testing area. And I believe the achievements are countless. But hold down. There are countless achievements in Quality and Testing area but that are not related to me. May be I will take some more time to add some achievements in my working area that will be identified as global achievements.

When I look back, I notice that I have covered a long journey (not so long) full of Testing, Quality , challenges, hot arguments, achievements, and lots more. I am going to complete seven years in Quality and Testing domain. Started as a GTE (Graduate Trainee Engineer) and now a Testing Manager.

Like other years, last year was also full of workitement (Work + Excitement). I met with some wonderful people in this industry. One of the most common aspect that I had faced and still facing are the encounters that I have done (or still doing) with the other part of the Software Development. I mean the encounters with the development team. Some are really interesting, some are really good and some are really really bad. An encounter means the discussions where there is a disagreement between the development and Tesitng. Those disagreements are due to bugs, processes, deadlines and lot of other stuff. But the primary reason is the word called "Process".

Actually if someone is gladly not accepting the processes that are good for the project’s health, I think no one can do anything to make them convinced. Solo efforts are OK, but the process is much richer when other members of the project community are involved. Good people do not need laws to tell them to act responsibly, while bad people will find a way around the laws. This statement truly captures the mentality of those software persons who doesn’t even want to discuss the word “Processes”.

Here is the list of comments that are really noteworthy that I received from my fellow development team till now in my Testing carrier.

1. Making things too knotty – Initially, when I started my carrier as a real and raw hardcore tester, this was one of the most common statements that I heard from the development engineers and their managers. Actually, I was the person, who has created numerous scenarios in the software while testing that is easy to explain for me but difficult to understand by the development team. But definitely, at the end of the software cycle, it was the customer that really appreciated my knotty things and software were become more or less OK.

2. Being difficult to handle – Well, one more common comment for me (or rather for all the genuine Testers) by the development side. Actually, if I found any bugs, it was really next to impossible to convince me that it was a bug. Most of the time, development was trying their best to convince me for their so called implemented (or I would say missed) feature. After having discussions with the customer, I was right most of the time and then the development team has to fix those bugs. I always emphasize on clarifying the problem because clarifying the problem can take you long way towards solving it.

3. Being philosopher – This is not a so old comment for me. In fact, this is one comment that every Testing Lead will get, if he is trying to implement some processes in an organization where existing processes are only as decorative as Chinese lamps and no one is ready to accept the new processes.

4. Not being a team player – This is the latest one that I got from a team who was far away from all the processes and working as they were working in a fish market. Here I have seen a lot of examples where reverse software engineering is being followed and if someone tries to do some process work (like me), a similar type of comment will be passed.

5. Creating unnecessary problems for the team – Not a new one from the development team but the dilemma is that I got this comment at that stage of my carrier when I was not expecting this from the other side. Ironically, I got this comment from a development manager who was a very senior guy.

Finally, I would like to say that be open for anything that works. Communication plays a major role in any project to make it a success. If the team is far behind an average communication channel, it is quite impossible to deliver a successful release to the customer. I learnt a lot from my rejections and I am still learning. But the good thing is that I am fine tuning myself and have done it till some extent. I firmly believe that improvement is a never ending process and everyone should drive his/her car on improvemement highway.

-- Sanat Sharma