Appraisal Convincing Process

I will start this blog with an incident that I have faced four years back. One of my reporting colleague in my previous company has been given a task by his manager (which was my manager also) to convince me about the appraisal amount that I got in my annual appraisal process. Actually, I was not satisfied with the increment that I received at that time. But I was silent and have shown my disinterest in the work. I indirectly passed the information to the management that I am not happy with that appraisal. My reporting colleague, who was my best friend also, tried his best to convince me (professionally + personally) about whatever has given to me, as an incremented compensation, is OK but I was not fully agreed.

One day, my manager scheduled a meeting with me and discussed the positive and negative aspects of my recent professional year. He gave me some very good feedbacks about my work and convinced me (more or less). Finally he told me that “Keep your spirit and efforts high because efforts may fail but don’t fail to make efforts”. I realized his concern. Actually, he was trying to motivate me and indirectly assuring me that I will get a good pay hike if I work again in the same manner I was working by the last one year with some improvements. I immediately changed my mind and again start working in a more aggressive and managed way. After two months, my manager sent me onsite for some Testing activities and within six months I roam all around India for some more Testing activities. The result was that after one year, I got a salary hike more than my expectation.

Now, what does that story mean? These is something useful for all those employees having work experience less than 4 years in IT industry and have spent less than a year in any firm. Sometimes, the firm is trying to check your patience in financial sector. But this is rare in today’s environment as there are a lot of opportunities in the market.

On average, the loss of one dissatisfied employee will result in about 150% of his yearly salary between advertising for his replacement, training the new person, lost productivity, and overtime of others to compensate while waiting for the new employee to get up to speed. When the lost employee is from higher side, the number increases to closer to 200%. This isn’t taking into consideration to loss of valuable knowledge. And more important thing: No amount of training will replace the knowledge that comes from doing the job everyday.

Most of the time (or I would say all the time), the appraisal amount depends on the performance that have been performed by the concern employee. The firm only banks on those employees who are really a great asset for them in future. So better to prove yourself in the firm first rather than disagreeing on all the concerns raised by your manager at the time of so called (by me) “Appraisal Convincing Process”. We all should be ready to discuss the negative side of the performance and to face the truth. Truth is a big word, so let’s settle for something more routine: the current situation or the current state.

It’s better to resign on the same day from the company if someone is not convinced with the appraisal amount received. Showing all your disinterest after the process and still working with the same firm/group creates numerous vibes within the management. I have written a blog previously titled “Official Honeymoon Period” that is related to this kind of working resource.

Creating a trusty environment after performing all the negative activities is difficult. Trust is invisible but the symptoms of its absence are not. So better not to think with your mouth. Think with your mind and plan accordingly.

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

50 % Project Allocation

I will start this blog with one anecdote.

About 5 years back, I was working as a Test team member in one of my project. One fine day, my manager committed to another team that I would also be a part of their Testing activities. When I asked how I will handle these two Testing activities, I got the answer that I am 50% allocated to my current project and 50% to another one. At that time, since I was new in the Software Industry, I became puzzled and ironically my manager was not able to plan for me for this situation.

What I did at that time is that I increased my working hours from 10 hours per day to 16 hours per day so that I would be able to meet the deadlines set by my manager for both the projects. I continued with this 16 hours schedule for more than 4 months (including weekends). Then somehow I managed and completed the Testing part for both the teams. As a reward for this excellent effort, I got the “Best performer” award for that year by my manager.

But I am not saying that this is the only execution path for any resource if your manager assigned you to two different projects each with 50% allocation. This might be a path but not feasible for everyone. Or in fact not recommended by me now.

Sometimes, that target resource, which has been assigned 50% each in two different projects, does not respond properly. Assuming that a resource “XYZ” has been assigned to two different project – Project A and Project B, each with 50% allocation. Now if the Project A reporting manager wants some updates about the progress for his project, the answer would be “I was busy with Project B work”. And if the Project B reporting manager wants some updates about the progress for his project, the answer would be “I was busy with Project A work”. And in reality, the resource is doing nothing.

Sometimes, this allocation works for only one project. The 50% allocated resource prioritizes the tasks and activities to the primary project in which the work will be noticed and hence personal progress can be done. In this type of scenario, the other project will suffer a lot. Because that project has a resource which is not working at all. Or rather not working properly at all.

I would suggest not executing this 50% allocation process as this is a total failure in practical software cycle. And if, by any chance, you have to allocate your resource by this way, follow the below mentioned practices:

• Better not to allocate 50% on daily basis. It should be on weekly basis.
• Keep track of all the activities performed by him/her for both the projects.
• Schedule a daily status report for each project with respective Team manager.
• Make a detailed and comprehensive plan for both the projects.
• Both the project managers should be in sink on what are the activities for both the projects that resource is doing.
• Don’t hard press the resource for performing both the activities.
• If 50% allocation doesn’t give a positive output, replace the resource with another one and try to work out with new resource.
• If another resource also doesn’t work, better to work on the planning and managing a 50% resource allocation roadmap.

-- Sanat Sharma

(Quality Assurance and Testing Expert)

Quality Success Criteria

What should be the criteria for a release to declare it as a “Quality Success”?

The most common and expected answer against this question is that “This depends on the number of bugs found in the release, fixed in the release and delivered with the release.”

Among these three dependencies, the most crucial one is the number of bugs delivered with the release. In most of the companies, I have seen a standard format of this Quality Success. On a scale of 1-5, assuming 1 is the worst quality and 5 is the best quality, following metrics is followed frequently to rate the release from quality point of view.

1. If number of major + critical bugs is 0, quality rating is 5.
2. If number of major + critical bugs is 2, quality rating is 4.
3. If number of major + critical bugs is 5, quality rating is 3.
4. If number of major + critical bugs is 10, quality rating is 2.
5. If number of major + critical bugs is 15 or more, quality rating is 1.

I believe rating the quality standards in terms of only the severity (major, critical) of a bug is a fake rating for a release. Ideally, a combination of severity and priority should be the criteria for assigning the quality rating to a release.

I believe categorization of bugs in two classes – Major and Critical, will develop a new hot thread between the development and Testing teams especially when this is the criteria for “Quality Success Ranking”. For each and every Critical or Major bug, there will be a definite discussion (or rather hot discussion) between the development team and the Test team. No development team will allow willingly firing bugs by Testing team having categories either Major or Critical because increasing of this number will definitely affect the quality rating of the release and eventually the thread will end at the performance of the development team. Even if there is a genuine critical or major bug in the release, the development team will try their best to lower down the severity of the bug. I have seen this in one of my previous company which is supposed to be the biggest IT giant in the world.

In my opinion, we can categorize this breakup into two classes – Must-fix bugs and Non-must fix bugs which is totally independent from this “Fighting point” of Major and Critical.

Basically, these two categories (Must-fix bugs and Non-must-fix bugs) are the outcomes of the combined and extracted result of the two factors of a bug – Severity and Priority.

Confusing …… Let me explain. Please see the below matrix.

(Severity is Critical) + (Priority is Lower) = Non-must-fix bugs

(Severity is Trivial) + (Priority is Higher) = Must-fix bugs

(Severity is Critical) + (Priority is Higher) = Must-fix bugs

(Severity is Trivial) + (Priority is Lower) = Non-must-fix bugs

So, the take away point for all the testers who has invested their time in reading this article is that better to categorize the bugs in two classes – Must-fix bugs and Non-must fix bugs and then make efforts to convince the management that these two are the best options to rate the release from quality point of view. Other wise the quality ratings based on only the severity of the bug is as good as nothing.

I often said that Quality is everybody’s job and that’s true. But it must start with management. Management’s job is to lead people toward a goal. And quality is the only goal that matters.

-- Sanat Sharma

50% Testing

50% Testing. What does that mean? There are many possible answers for this question.

Possible Answer 1 :

Testing team has to perform Testing for only half of the new features implemented in the new version of the software. For example, if there are 6 new features implemented in the new version of the release, Test team will perform Testing on only 3 features.

Possible Answer 2 :

Execute only 50% Test cases against the release written by the Test team.

Possible Answer 3 :

Perform only 50% Sanity Testing, 50% Acceptance Testing and 50% Progression Testing.

Possible Answer 4 :

Prioritize the Testing effort as per the priority basis which is suitable for the release and then perform 50% Testing on it.

Well, a lot of possible answers. But all are confusing and creating nonsense for the Testing team. As I always said Testing never ends. It just gets transferred from the Testing team to the customer. Then how come 50% Testing can be done.

Assuming that the effort estimation measured by the Testing team to test software is 20 days and project deadlines denies this estimation due to time crunch. Is it a fare statement that “Since due to time crunch, only 10 days will be provided to the Testing effort and hence Test team should perform 50% Testing.”?

It is possible but should have a very clear understanding of what has to be performed in those 10 days so that a must test features can be covered completely and some other features, which are not so critical from the release point of view, can be escaped. But this should happen under this 50% Testing umbrella.

Risk Based Testing can be linked with this 50% Testing coverage but it will not fit completely under this.

So, next time, whenever your manager ask for performing 50% Testing on a given release, no need to confuse and start with prioritizing your Testing efforts.

-- Sanat Sharma

Non-reproducible bugs – What does that mean?

From Testing team standpoint: We found this Bug once while testing the software. Now we are not able to reproduce it.

From Development team standpoint: Please reproduce it else we will mark this bug as invalid.

These are the two aspects against a bug which the tester’s find only once while testing the software but not able to reproduce it. In my opinion, non-reproducible bugs should be renamed as "hard-to-reproduce" bugs. This term will justify some existence of these kinds of Bugs.

All the Bug Tracking Tools have some options to handle these kinds of issues but normally I have seen a same way to tackle these kinds of bugs by the development team. “Please reproduce it. Then we will consider this as a Bug and work on it”.

In one of my previous organization, I found a bug which I was able to reproduce it my setup but the developer was not able to reproduce it in his setup. I also tried my best to recreate the scenario in the development’s setup but all efforts failed. At that time, one of my development manager surprisingly said that the Test team should not file this bug because the development team is not able to reproduce this bug in their setup. It was the statement that truly captured his attitude towards Testing. But I still logged that Bug and it has been marked as “rejected” by the development team. After two months, same problem has reported by the customer and then you can imagine whatever happened after that was not good for that development manager. Every muscle in his neck and face was tensed when he was questioned by the management.

In my first organization where I worked and progressed as a Test team member, I fired 75% of the total bugs logged in the Bug Tracking System against specific software that I tested. Some of those issues are non-reproducible but 65% of those bugs have resolved by the development team. Fortunately, the development team understood the term in a better way.

I have seen in my carrier that a non-reproducible bug remains as it is in the Bug Tracking System as decorative as Chinese lamps. And after some time, that bug has been rejected by the management without even asking from the Test team.

There should be some rule (or process) according to the organization perspective as to how to handle the “Non-reproducible” (or better say “Hard-to-Reproduce”) bugs. Good people do not need rules to tell them to act responsibly, while bad people will find a way around the rules. If we ignore these bugs, we have to pay off. Ignorance can lead to unawareness that the light you see the end of the tunnel is actually an oncoming train.

-- Sanat Sharma (सनत शर्मा)
Quality and Testing Expert

Project Plan – Initiating, Planning, Execution, Control, Procedures and Deadlines.

A Project Plan (PP) should contain the track of all these activities mentioned above. Few days back, I was reading a book about Project Management and Planning. There was a statement which says “Every professionally managed, successful project is driven by a project plan and every un-successful project is driven by the project itself”.

Initially, I was a little bit confused for this statement. But after giving a second thought on it, I found it very realistic and relevant statement for Project Management (PM).

All the action items covered in the PP can be tracked in a better way if they have defined in a proper way. In one of my previous company where I worked in my earlier carrier phase, my manager always used to ask the question” What are you doing today?” Once I said to him that since there is no PP defined for this project, so better not to fire this question to me on daily basis. I asked him to first make a PP and define the tasks and action items against me, so that I can tell you in a better way. But I believe he was not convinced with my answer as most of the managers are not convinced with their subordinate’s answers. After two three days, he again came to and an interesting conversation between us went like this:

Manager: What are you doing today?

Myself: I am going to listen songs today.

Manager: What?

Myself: Yes, I will listen songs today. In fact I have done this exercise yesterday also.

Manager: This is not expected from a resource like you. You are one of the most critical resources in my testing team.

Myself: So what sir. I have no tasks assigned in Project Plan. In fact there is no Project Plan as such for me. So I can do anything what I want.

Manager: If there is no Project Plan, that doesn’t mean you will do whatever you want.

Myself: Agree. But in that case, you should assign me some other work related to project and then better come to me asking for what I am going to do today.

Manager: Ok.

And then he left my place. After one week, he again came to me with a Project Plan and also some additional activities for which he allocated me as a primary resource. I was pleased to see that change. This time, I have to answer his question “What are you doing today?”

This incident gave me a lesson that if your team is not performing, the managers are responsible primarily for this state.

The whole event comes to a conclusion that making a PP can definitely track the team activities in a better way and at any time of the project, it can be measured that how much percentage of work has been done against the project.

I have seen in some companies that managers are not interested in updating the PP on regular basis. They are only interested in making it once and forget to update. They should understand this fact that updating the PP is their primary task. If they are not doing this activity on regular basis, better not to say them managers. They are only a front desk employee of the company with a Manager’s salary.

Last month, I was discussing some quality processes for an accurate PP with one of my friend who is a Project Manager in a reputed MNC. He said that PP is one of the most important tasks that a Project Manager should perform. He also added that this is also one of the most cumbersome tasks in Project Management. According to his statement, he is going to leave the IT industry only because he has to update and maintain the PP. I tried my best to convince him that there are n numbers of ways to perform and execute this task in a better way. I personally share some of my views about the PP and Project Management with him. Somehow, he was convinced with me but not by the processes and techniques that his company is following with respect to the Project Plan and Project Management. We discussed about 4-5 hours for the same and then went off to our places. Last week, he called me saying that he has resigned from his current company and going to join a small IT company. He said that he will now check these management practices in a small company.

Anyways, small, mid and large companies don’t mean that there is a difference in the Project Planning and Management. The only difference is the attitude of the middle and higher management. The middle and the higher management should be responsible for anything that is going in a wrong direction in any project.

It is your attitude not the aptitude that decides your altitude.

-- Sanat Sharma

Buffer Time in Project Management

3 years back, when I was not a part of project management, I was not aware of the term "Buffer Time" or BT. or fairly I can say I was not aware of the actual meaning of "BT". When I primarily started my carrier in Project Management, I came to know the actual and meaningful meaning of this term. I was fortunate to start my role in project management in a very small company but a value centric company with a genuine and great management team. At that time, I was under the impression that BT means time that is being kept by the management to protect the project from the impact. I believe that is somehow the appropriate definition of BT. At that time, I tried my best to keep BT on the basis of other factors so that it can be evaluated in a proper way.

As far as factors affecting the BT is concern, two factors “Risks” and “Dependencies” plays an important role to evaluate this. There are some common rules based on these two factors that calculate the BT for any project. Whenever I asked to provide the effort estimation for any Testing cycle, I always try my best to calculate the effort estimation including BT on the basis on these two factors – Risks and Dependencies.

But now days, BT is becoming a part of effort estimation in projects. Let me clear it in a mathematical way.

Effort Estimation = Time to develop (or Test) + Buffer Time

What I have seen recently is that Buffer Time is being used by the teams (either development or Test) as a part of performing their activities. In that case, if anything goes wrong i.e. any of the risk or dependency happen, the project delays. Ideally, the BT should not be used in the primary activities. The managers should not disclose the BT to the front desk employees. If the BT is being shared with the team members, everyone is assuming this time as a regular project activity time. These practices definitely delay the project deadlines.

But before calculating the BT, the managers should be aware of the risks and dependencies. Not to disclose this but I have seen some managers in my carrier who are not aware of these terms and managing the project. What a joke.

I have seen on the road traffic signals a great example of crushing the BT. The vehicle owners always look on the other side traffic signal so that they can act according to its movement. If there is a green signal and the traffic goes on, the other side vehicle owners will not see their respective traffic lights. They will see the other side traffic lights and immediately when the green turns to orange, they start running irrespective of the fact that they still have red light to stop.

Now this orange light is the BT. But who cares. People start their vehicles running on orange light itself. Most of the accidents I have seen in the traffic signals in due to this BT crushing.

So a million dollar tip for the managers is that they be aware of the risks and dependencies of the projects and should try their best to evaluate the BT. If possible, do not disclose the BT in front of your team and if you have to do that, in any case, keep another BT for the completion of the project still on the planned dates.

-- Sanat Sharma

(Quality Assurance and Testing Expert)

System Requirements Document (SysRD) versus Software Requirements Specifications (SRS)



Questions 1. Who is responsible for creating SysRD?
Questions 2. Who is responsible for creating SRS?
Questions 3. Who will approve the SysRD?
Questions 4. Who will approve the SRS?
Questions 5. In which phase of product life cycle, the SysRD should be finalized and approved?
Questions 6. In which phase of product life cycle, the SRS should be finalized and approved?
Questions 7. Which document should be considered by the Test team to test the software? SysRD or SRS?


And the ideal answers are

Answer 1. System Engineers after having discussions from the marketing teams.
Answer 2. Development Team taking inputs from the Testing team.
Answer 3. System Engineer
Answer 4. System Engineer
Answer 5. Phase - 2 i.e Requirement Analysis phase
Answer 6. Phase - 3 i.e System Design
Answer 7. Both

But what is happening in the Software industry now a day. See the factual answers

Answer 1. System Engineers but not having a clear picture from the marketing teams.
Answer 2. Development Team only. Few inputs or rather no inputs from the Test team.
Answer 3. System Engineer
Answer 4. System Engineer and Testing team
Answer 5. Phase – 4 i.e. Coding
Answer 6. Phase – 4 and 5 i.e Coding and Testing
Answer 7. Mostly SysRD.

-- Sanat Sharma

Testing Effort Estimation
--------------------------

This is one of the most crucial issues that the Testing team is facing now days in Software Industry. Your manager will simply ask for the effort estimation that is required to Test the software. He is definitely not aware of the fact that the Test team has no requirement documents. Or if he is aware by any chance, he will not consider this fact.

Recently, I have seen that one of the development lead was asking for the Test cases from the Test team without providing them the requirement documents. That was really a great fun. I don't know from where these guys are getting their engineering degrees.

Well, the problem is not with the estimation but with the clarity. If you are not aware of what you have to estimate, how you can estimate the exact deadlines. We should understand this fact that why these are called the Estimations not the Predictions. We should know the difference between the Estimations and Predictions.

Recently, I have seen an example where Test team has given an effort estimation which could not be met due to some miscommunications between the development and the Test team. But finally, all blame goes to the Test team saying that your estimation was wrong. That was one of the most horrible experience I have ever suffered.

I have seen some managers who are not aware of the difference between the Risks and the Dependencies. And officially, those guys are responsible for effort estimations in development cycle. Amazing.....

I think one of the major factors for providing the effort estimation for Testing is definitely the requirement documents. But one more important criteria that should be considered before, is the previous experience. Make a thumb rule that I will estimate twice the number of days that is actually required to test the system. If you don't do so, the blame will come to you only.

-- Sanat Sharma

Official Honeymoon Period (OHP)

In my total 6+ years of work experience in Software Industry, I have seen n number of people who are not keen to work when they issue notice to the company about their parting from company. Notice period will become the “Official Honeymoon Period (OHP)” for them. Following actions have been noticed by me when any of the employees is enjoying his/her OHP.


1. Late coming and early going
2. No work responsibility
3. Least interaction with the seniors
4. Internet browsing and chatting
5. Searching for the better job (they already have a job in hand)
6. Using official phone
7. Consuming all the remaining leaves
8. Not interested in knowledge transfer process
9. Study about the next company and their work processes
10. Performing all the other remaining unofficial activities (if I missed anything)

Basically, they are interested in only getting a better job and their last salary. In my opinion, the salaries should not be given to those employees who are performing these kinds of rubbish things. Company relieving letter should be given to the employee only when the HR gets a “Green and Clean” signal from the management. Management should try their best to assign work to them and notice them on a fast pace. At least, management should try to perform the knowledge transfer sessions from them. If the management is not happy with the way of their actions after giving the notice, they should at least inform HR about this and HR must take some indiscipline actions against them.

On the other side, I have seen a few employees who act more responsible in this period. I have seen two guys till date in my carrier who acts like anything in their notice period. They tried their best to give the company whatever they can in that period. I really appreciate those guys.

The whole story can be summarized in one line that there should be no notice period. Ha ha … Just kidding.
We should notice the notice period guys in a proper way and precede their proceedings accordingly.

-- Sanat Sharma

The habit of finding Bugs (continue)..

In continuation of my blog (headline above) that I have published on September 2007, I was not sure whether the mentioned habit is good or bad. But few days back, one of my friends said that he is also doing the same task in his personal life. There was an issue in his telephone bill that he got from the company. He discussed them with those guys and they corrected their mistake. Similarly, he was saying that he is now trying his best to get the full perfection in his life at least from personal side.

Although he has only one plus year of experience in testing domain but I think he is doing the right thing. Or directly he is supporting me. According to his statement, he is now able to get the things done at right time in right place with right attitude. I think this is one of the most important aspects of anyone’s life. Being a tester, you should be able to find the issues in your personal life. But finding the issues is not sufficient. You should be able to resolve them amicably and give your best not to repeat that issue.

The above views are totally coming from my mentally. This doesn’t mean that each and every tester should try to follow these things. In my opinion, this kind of attitude makes you a person who is more aligned towards the complete perfection. You should be good tester in your professional life and try to become the same in your personal life also. I know by having this kind of attitude, people will try to put you on the spot. But you should be careful for this and handle the situation in a matured way.

But this will take time. It takes courage to grow up and become who you really are. Remember Rome was not built in a day.

So, all the best and happy bug finding. Both in Professional and Personal life.

-- Sanat Sharma

Software Entry-Exit criteria


There are lots of discussions about the Entry-Exit criteria within the management for a software release. Here I am summarizing few points that I think should be a solution for most of those dialogues.

Entry criteria –
Entry criteria means when the release should be accepted for testing. Now there are three filters for entry criteria:
1. The first Entry criteria should be from the Configuration Management team. They should accept the release only if the release was being thoroughly unit tested by the development team.
2. The second Entry criteria should be from the Test team. They should accept the release only when the release was being thoroughly sanity tested by the Configuration Management team.
3. The third Entry criteria should be within the Test team. They should perform the acceptance testing and if passed, they should start performing the major testing for the release.

If any of these entry criteria failed, the release should not be accepted by any of the team and return back to the development team.

Exit criteria –
Exit criteria means when the release should be green signaled or red signaled by the test team. The exit criteria can be of three categories:
1. The first exit criteria are in case when any of the above entry criteria failed.
2. The second exit criteria are in case when the test team has found some major or critical bugs in the system while performing the major testing effort. The number of bugs that will decide the fate of the release should be discussed and mentioned in the test plan.
3. The third exit criteria is when complete testing has been done, bugs has been logged and test report has been sent to the development manager.

If the release fails due to any of the two reasons mentioned in the Exit criteria, a revision kit should be delivered by the development team. And if the release has gone through the third point mentioned in the Exit criteria, a correction kit should be delivered to the test team.

-- Sanat Sharma

Requirements or Bug Database:

Requirements play a major role in developing software under a normal circumstance. Collecting Business, User and Functional requirements is the first activity that should be performed in the initial stage of the software development life cycle. Sometimes, the system engineer (or requirement collector) could not able to collect the complete requirements and due to which nothing can be planned in a proper way. The development team starts coding without having a complete knowledge of the design and consecutively test team have no proper documents to test the release.

In this type of scenario, most of the bugs found by the test team converted into the limitations and remaining bugs are being logged in the Bug tracking system. That is the reason I am saying that our bug database should not be our requirement document.

The point that one should ask from the development is that whatever mentioned in the release notes has been implemented in the release or whatever implemented in the release has been mentioned in the release notes. We should be very careful while answering this question as selecting any of the option against this question will definitely tell everyone what methodology you are following in your software life cycle. Is it a software engineering or a reverse software engineering?

-- Sanat Sharma

The habit of finding bugs
-----------------------------

I'll begin with this blog with an anecdote. Last week, I was going through an incidence published in a reputed magazine. The incidence has been sent by one of the reader of that magazine. I noticed one thing in that. I saw that that guy was claiming that Rs. 1000 note has been introduced in the Indian market in 1997. I was quite confused and discussed it with my family. Everybody said that he must be right as it is mentioned in the magazine. But I still have doubt. At that moment, I stopped the topic. On that night, I was not able to sleep properly as I was sure that the mentioned statement about Rs. 1000 note was somewhere wrong. I checked in internet and got this information that the Rs. 1000 currency has been introduced in Indian market 7 years back. Then only I felt cool and relaxed.

Now what is this? Why I am describing this incident? Is it worth?

Actually this is called the habit of finding bugs. I spent my professional life in testing and quality domain for more than 6 years and still in the same domain. I always tried my best to find bugs in the software. Now this is become a habit in my personal life also. In each and every aspect of life, I try to find bugs in it. Although I believe this is not a bad habit but I definitely want to get rid of this one at least in my personal life. I am used to check for the spelling mistakes in market area, inconsistencies in objects, quality measures in food stuffs, measure each and every task. And the list goes on and on and on.

Last year, I was in Silicon Valley of India. I went to a good hotel for a team lunch with other team members. There the management was too poor. I mean no one was taking care of anything. After having our lunch, when we were just going to leave, I have a chat with the hotel’s manager, who fortunately (or you can say unfortunately) came in front of me. When I said that you have n number of management loopholes in your area, he simply said that we are working on this and by next month, we will get the ISO certification. Then I though that whatever I said was definitely quality issues and those must be addressed for a proper quality work.

Now days, there is one more great advertisement that is being aired in Indian television. There is a product which is being endorsed by a great superstar of Indian film industry. In the advertisement itself, he is claiming that he is using this product from the last 40 years. But the fact is that the said product was launched only 7-8 years back.

One of the great definitions that I have encountered few days back about testing is “Testing means a procedure for critical evaluation”. I have found abundant bugs in my professional experience (and personal also) till date and still on my way. Some of my all time favorite bugs are spectacular crashes. They are fun to watch and rewarding to find.

Applying this into the test team, I believe that if my test team is positive, upbeat, and happy, I can almost guarantee that I've got the wrong people. You need a team to be critical, judgmental, and, well, negative. To be a good tester you've got to be pessimistic ("I know bugs are still in there somewhere"). You've got to be negative ("I'm not sure dev has implemented that functionality quite as well as they could have done"). If your testers are saying things like "I'm sure there aren't any bugs left," then you aren't dealing with a successful test team.

A couple of years back, I was serious when I do my work but I was not serious when I'm home with my family. But at present what is happening that I am more and more serious when I do my work and serious when I’m home with my family. This is because I am still finding bugs, inconsistencies and other quality related stuffs in my day to day life. But one thing I must say that this habit is really working for me in my professional life. And As I look forward, I'm very optimistic about the things I see ahead. I am dam sure that there's something good that will definitely come out of it.

-- Sanat Sharma

Battling against Procrastination
---------------------------------

What is Procrastination? Is it a practice or a psychological state? What does that mean? Actually, it means putting off or delaying or deferring an action to a later time. If you struggle with procrastination, you're not alone. Most of the populace in this world is having this virus. And in our IT industry, this is becoming a ustomary practice for most of our software professionals. This kind of software professionals try to build their image forgetting this fact that they are playing in the dark. As I said before in one of my earlier blog that “Plan is nothing, planning is everything”. Henry Ford also once said, "You can't build a reputation on what u're going to do." Actually Ford statement wires my saying about the “Plan” and gives a better picture of what we should do to be more successful. I believe that to be successful you must learn to close the gap between what you should be doing and what you are actually doing.

In my 6 years of experience in IT industry, I have seen a lot of guys having procrastination bug. But they are under the feeling that they are doing their best to serve their companies. Few days back, I have an encounter with one of my friend and colleague who is 100% hit by procrastination. When I tried to dig out the root cause, he tried to put me on the spot and debate me on this with no concrete facts. Every muscle in his neck and face was tensed at that time. Basically, he tried to confuse me about his act. These types of guys will definitely try to confuse you because they strongly believe that “If you can not convince them, confuse them”.

There is a very widespread say in India. I would like to share it in Hindi with all of you.

“Kaal kare so aaj kar, Aaj kare so ab”

This means that one should do the work today which he has planned for tomorrow. The say continues unfolding that one should perform the task right now which has planned for today itself. This is just the opposite of procrastination. Or we can say Anti-procrastination.

In one of my previous company, my boss was like this only. I mean he was definitely a procrastination man and ironically he always tried to be smart in front of his senior management. Once I asked with that guy a very basic question about this habit in a general status meeting. I could not disclose that question here in my blog because that will directly pin point towards that senior guy and I don’t want to do that. But after that incidence, he tried his best not to act like a procrastination guy and believe me, he recovered a lot.

If any one of you is struggling with procrastination, the following four steps can be followed to brawl against this tendency to some extent.

1. DISRUPT YOUR STANDARD SCHEDULE.

A couple of years back, I was working with one of the biggest IT Company and was inspired with my manager a lot. Once he said to me "Do not tell me how hard you work. Tell me how much you get done." That was the statement that truly stunned as well as shaken me a lot at that time. I kept thinking about this statement and then come to this conclusion that it doesn't matter how hard or long you work if you're not accomplishing what needs to be done.
Sometimes changing how or where you work can increase your output extensively. Start by shuffling the order of your daily tasks. If it makes sense, begin your day with a task you normally reserve for the end of the day, or vice-versa. Also, try changing your work setting. Go to a park or swimming pool. Break out of old familiar patterns. Try to come to your office by the local bus service or by a shared cab. Use your bike (or bicycle if possible) instead of car. Start working early in the morning and leave for the day in the evening instead of late nights. These kinds of acts will definitely be questionable for the management but that will definitely help you to struggle against procrastination. And at the end of day, if you are completing your work in a proper way, no one will raise their hands against your way of working.

2. GET YOUR FIRST FAILURE OUT OF THE WAY.

It is true that first failure always gives you a feeling of sadness and pain. But in my opinion, pain is very interesting because it makes you stronger and deeper. My professional hardship and personal lows have only made me stronger. Plan and execute your first failure so that you no longer have to fear it. If you need to make sales calls, dial up your first potential client and expect rejection. Keep calling until you get that first "no." Don’t expect an instantaneous Yes. If the answer is No, learn from the rejections. If you're brainstorming to solve a problem or complete a project, start by weeding through the bad ideas, and then move on to better ones. Once you've expected—and overcome--one failure, other ones don't look so intimidating.


3. BREAK YOUR BIG TASKS DOWN.

The average person doesn't get seriously down to work on a big project until midway between the start of the project and the deadline, whether an hour or a year away.
If the size of a task causes you to procrastinate or completely shy away, break it into smaller, more manageable tasks. Then, give yourself an immediate deadline for accomplishing each task. Ray Kroc said, "Nothing is particularly hard if you divide it into small jobs." I am also following the same point in my professional carrier. I called this technique as “BST” (Baby Step Technique) and believe me; it is working a lot in my job concerns. This is very true that if you have a huge task to plan and execute, its better to break it into smaller pieces of chunks and then work accordingly. Problems will remain in this technique also (BST), but it will be in the short format and can be resolved further to smaller chunks.

4. STEP BACK AND SEE THE BIG PICTURE.

There is a primary philosophy gap that draws a clear demarcation line between the losers and the winners. The losers lack something vital: a sense of purpose. Often people fail to start or complete a task because they don't see any connection between what they're doing and what they really want to accomplish in life. If you sense that what you're doing is not directing a path toward a desired result, it's probably time to rethink your pursuits. The biggest gap in the world is between 'I should' and 'I did.'". On the other hand, if you know that your work will move you closer to your goals, you will be more inclined to see the task through. Actually in my opinion, we should be more specific about our desired outcome.

The whole case study has turned up to a statement that even if you have procrastinated in the past, you can begin working today with a new outlook on getting things done and use some fresh methods for avoiding procrastination in the future. Make yourself a promise today to put an end to the phrases "woulda, coulda, shoulda" in your life. This is definitely a big challenge but we should make a difference in how we view challenges.

I will end this article with an anecdote: Once I went to onsite for some of my project related tasks. There I met a team that is totally devoted to testing activities. They were 4 guys and three of them are too much roofed by procrastination. They always tried to defer all the actions to a later time. But there was a fourth guy who is just opposite to this. He was too sharp and IR type of guy. IR means Instant Response. Now the main point in this context is that the fourth guy (IR type) was physically challenged and the rest of the three guys are quite well. Once I said in a team meeting that we should learn with this guy (IR Guy) to behave professionally in office. I admired that guy a lot in that meeting and surprisingly when I visited next day there, I felt that the other three guys start working against their normal habit i.e. against procrastination. Although I haven’t seen those guys for a long time after that but I hope they must have changed their attitude.

-- Sanat Sharma

RISK DRIVEN TESTING

In most of the software companies, the time owed by the test team to test a component is fairly less as compared to what the actual time should be to test it. Since this is a very widespread process, the test team should work according to the condition. And the dilemma is when the software cycle shrinks; the management tries to cut down the testing cycle. The management believes that testing phase is the only phase that can be condensed in terms of time and they can deliver the component within the scope of the reduced project plan. Testers are used to working in time-pressured projects, without requirements, using unfamiliar technology in culture that prefer to code first and plan second.

So what and how to proceed in this type of scenarios? The only technique that comes into my mind is Risk Driven Testing (RDT). Whenever there's too much to do and not enough time to do it, we have to prioritize so that at least the most important things get done. So prioritization has received a lot of attention and this approach is called Risk Driven Testing.

What if there isn't enough time for thorough testing? The test team should use risk analysis to determine where testing should be focused. Since it's rarely possible to test every possible aspect of an application, every possible combination of events, every dependency, or everything that could go wrong, risk analysis is appropriate to most software development projects. This requires judgment skills, common sense, and experience.

In one of my previous organizations, it was a routine process to shrink the testing cycle according to the tight timelines of the project. Once I discussed this issue with my management. The simple point they asked me is “What is the time that you required to test this feature?” I said this is not a valid question from a testing team member. This question is same as HR asks you how much salary you want. The answer for both the questions is same. “Give me as many as you can”. Initially, the manager didn’t understand my interpretation. But gradually, he realized that he has asked a wrong question from a right guy.

It is true that testing never ends. I am still testing my Windows Imate cell phone that is having 5 issues in it till date. But that is not the solution in the current tight timelines scenarios. One should prioritize the testing tasks and perform it according to the priority. This is what called “Risk Driven Testing”. As said above, the RDT requires judgment skills, common sense and experience. Once you are completely familiar with the product/project/technology, you can perform RDT in a better way. Effective testing and clear communications of results is an integrated part of RDT.

Following are the consideration that can be included in RDT.

Which functionality is most important to the project's intended purpose?
Which functionality is most visible to the user?
Which functionality has the largest safety impact?
Which functionality has the largest financial impact on users?
Which aspects of the application are most important to the customer?
Which aspects of the application can be tested early in the development cycle?
Which parts of the code are most complex, and thus most subject to errors?
Which parts of the application were developed in rush or panic mode?
Which aspects of similar/related previous projects caused problems?
Which aspects of similar/related previous projects had large maintenance expenses?
Which parts of the requirements and design are unclear or poorly thought out?
What do the developers think are the highest-risk aspects of the application?
What kinds of problems would cause the worst publicity?
What kinds of problems would cause the most customer service complaints?
What kinds of tests could easily cover multiple functionalities?
Which tests will have the best high-risk-coverage to time-required ratio?

-- Sanat Sharma

Bug Reports - Five major issues

Right through my carrier so far, I have seen a lot of hot negotiations between the testers and the developers and that too for Bug Reports. I have fired a lot of bugs in my carrier (professional + personal) and still firing. Some of my all time favorite bugs are spectacular crashes. They are fun to watch and rewarding to find.

If there is a critical bug in released software, one of the two things happened:

Either no one found the bug before release or
Someone found the bug but no one fixed it before release.

None of us likes it when bugs in the first category bite us, but it’s the bug in the second category that hurt the most. There are some reasons that insist this second category. Using this article, I will try to summarize some points that should be taken care before firing the bug reports.

Test team is supposed to file (or I will say “fire”) bugs in the Bugs Tracking System. But normally I have seen that the Bug Report submitted by the tester is not clear and do not give a clear picture of what went wrong while testing. There are some points that should be mentioned clearly in the bug report. And also there are some things that we should ignore while reporting a bug against the product.

Presenting a list of five major problems that is quite common in the Bug reports.

1. Testers do not describe how to reproduce the bug. Either no procedure is given, or the given procedure doesn't work. Either case will likely get the bug report shelved. There should be an exact set of test steps which should clearly convey to the development team that what are the steps to reproduce the bug. Ideally, a tester should try to reproduce the issue thrice and then make a consolidated list of steps to reproduce. That will help the development team to understand the issue in a better way and they will easily reproduce that bug without even taking help with the testing team. When I started my carrier as a tester, no one was able to understand the bug report that I was sending. But gradually, I understood that how important is the clarity of the report for the whole team.

2. They don't explain what went wrong. At what point in the procedure does the bug occur? What should happen there? What actually happened? These are more or less related to the point above. While mentioning the steps to reproduce in the bug report, it should be clearly mentioned that at what step or at what point, the bug enters in the test case execution. It’s better to explain ideally what should happen at that particular step or how the application should handle the scenario at that time. Actual output and expected output should be clearly mentioned. As I said before, I also got this mania in my initial 2 years of testing experience.

3. They are not persuasive about the priority of the bug. Your job is to have the seriousness of the bug accurately assessed. There's a natural tendency for programmers and managers to rate bugs as less serious than they are. If you believe a bug is serious, explain why a customer would view it the way you do. If you found the bug with an odd case, take the time to reproduce it with a more obviously common or compelling case. As a tester, you should assign carefully “priority of fixing” of that bug.

4. They do not help the programmer in debugging. This is a simple cost/benefit tradeoff. A small amount of time spent simplifying the procedure for reproducing the bug or exploring the various ways it could occur may save a great deal of programmer time. Try to dig out the issue and concentrate on “Root Cause Analysis (RCA)” of the Bug. It’s better to raise an issue and simultaneously try to analyze the RCA of that bug. If you have any observation regarding this, you should add it on the bug report. This will definitely help the developers to resolve the issue quickly. I used to mention the detailed observation of the bug and try to dig the issue as far as I can perform. But please don’t forget to add your observations in the Bug Report.

5. They are insulting, so they poison the relationship between developers and testers. A smooth working relationship between developers and testers is essential for efficient testing. As a test team member, you are always a “Bad News Reader”. So we should be polite and diplomatic while writing a bug report. In my 6 years of work experience in testing, I have seen that 80% of time, development team and testing team discusses about the bugs. Or I can say fighting on the issues.

So take care of these points and try to develop a healthy rivalry between the developers and testers. Clarifying the problem can take you a long way toward solving it.

-- Sanat Sharma

Winning Test Team
____________________________

According to the “American Heritage Dictionary”, testing means "a procedure for critical evaluation”. That means as a tester, we need to be skilled at thinking critically.

Defining success for a test team is always difficult. In my opinion, testing never ends. Its just get transfer from the testing team to the customer. Every time your customer uses the program, a test is being conducted. We will always release software with bugs. We will always wonder if our test coverage was as thorough as it could have been. Yet if we are to accept these as part of our job, how do we know if we've been successful? It is quite difficult to analyze the fact that how much successful our testing team is. So to say that we have a most successful test team is a tricky and tough task

Till now, I have work experience of around 6+ years in testing and quality assurance. I believe that as a tester, you have to look for all the negative aspects of the software. But sometimes, you got some very amazing and ignored answers that could kill your spirit of testing

Take, for example, a great test team I worked with a couple of years ago. A well known telecom company has outsourced their testing part to the company where I was working as a Test Lead. Now we have done our task for one of the major release and still I have some doubts that there are still some bugs in the software. When I discussed this issue with that company’s Project Manager, he said that there is nothing as such. You have done your work and it is fine. When I again expressed some doubts in the software, he simply said that your task as an outsourced test team is complete now. Forget about the release and we will take care of further processing.

If your test team is positive and happy, you can almost guarantee that you've got the wrong people. You need a team to be critical, judgmental, and, well, negative. To be a good tester you've got to be pessimistic. You should always think that there are some bugs still in the software. You've got to be negative If my testers are saying things like "I'm sure there aren't any bugs left," then as a Test Lead, I am not dealing with a successful test team. In that case, I will try to convince the team and try to change their mindset.

I've worked with a lot of talented testers and I have seen that those testers are always critical by voice. As a tester, they are always a bad news reader. But I have worked with a number of testers also, who perceive testing as a positive role. While they know that they can't find every bug, they also know that increasing the number of bugs found contributes greatly to the overall quality of the product. Actually, for developers, things come to an end after coding the module. But the problem for many testers – and I’m no exception – is the question of when enough is enough.

The testing team’s goal is to find every feasible bug in a piece of software, even if someone says it isn't feasible. While development may meet its goal, we as a tester should always think that "We haven't quite finished our task yet."

Besides, finding only bugs in the software and acting as a bad new reader always, I think we should also appraise the tasks done by the development team. This will eliminate their belief that whenever we discuss anything with them, we have some bugs in our mind. This method is quite difficult as I have said before that testing means a procedure of critical evaluation. But in my opinion, we should try this once to soften the relationship between us and the development team. Actually I am also working on these points with the development team, and really speaking I have no positive outcome by following these. But I am sure, after some time, this will definitely pay me. I believe that “Efforts may fail, but don’t fail to make efforts”.

1. Highlight the developer’s work and good point in the code.

Make a regular practice to comment on one or two positive points every day of the developer’s work to whom you are working with. It takes a lot of effort to lift the spirits for those developer by a tester who highlight the negative points day in and day out. So help your development team by highlighting positive points daily.
-------------------------------------------

2. Set Clear Goals and define your testing scope.

Setting clear goals is crucial for the test team and the individual, including you. Testing sometimes seems to go on forever, and a team that feels there’s no end in sight is likely to end up despondent. Define test areas, but make sure they have boundaries with clear completion criteria. Try to set the testing goals of your project and clearly define the scope of the testing that you and your team are going to execute. If there is not enough time to test the component, use some risk analysis testing methods to test the component in a better way. Prioritize the test cases and testing. This gives the testers something to aim for and feel good about when they achieve it.
---------------------------------------------

3. Encourage Developers.

Some of the best and most talented developers I've worked with have always been positive and grateful for the testers' efforts. Developers with the strength of mind to encourage and support testers in this scenario really help to maintain a tester's enthusiasm. If nothing else, it's in the developers' interest to help maintain the testers' enthusiasm, as it is likely to lead to more defects found before a product is released.
----------------------------------------------

4. Look for some positives also in the Software.

Number of test cases failed should not be our first criteria to evaluate the work done by the development team. You should also highlight the number of pass test cases. Finding bugs is good from the tester’s view, but highlighting good point is really great from the developer’s point of view. Instead of focusing on the negatives only, we should emphasize the positives also. If development is nearing completion on a certain aspect of functionality and you've completed a test run over this functionality, highlight how well testing has gone. You'll be surprised how your spirits lift when you take the time to compliment others for something they've done well.
----------------------------------------------

To handle yourself, use your head but to handle others, use your heart. While testing may be mostly critical, don't overlook the importance of being positive.

-- Sanat Sharma

Scheduling a meeting. Oh God!!!! Save me.

Now a day, scheduling a meeting is one of most burdensome task in software industry in India. If you planned a meeting at (let’s say) 10:00 AM, 80% of the attendees will come at 10:15 AM or 10:30 AM. And for some of them, you have to bodily go to their seat (or call them) to join.

To resolve this commitment or attitude and time wastage problem, I decided to arrive before the scheduled start time. I encouraged other participants to get there early. I worked to become a meeting leader; and, when I became a leader, I demanded that people appear on time.

A meeting that doesn’t include the following characteristics is not likely to help your project or your team move forward:

1. It starts on time.
2. It ends on time or early.
3. You can leave the meeting if you are not needed.
4. Action items come out of the meeting.
5. The meeting has an agenda and minutes.

So the first agenda for all my meetings became “Hang around for people who turn up late”. All the agenda items in my agenda have durations.

So this agenda item looks like following:

1. Wait for people who arrive late. 10 minutes

Now, after seeing this agenda, I think some definite reactions would be:

1. Some participants will say that the agenda item started the meeting out on a sour note
2. Some participants will think starting late is unacceptable and they wanted to do something about it.
3. And definitely no reactions from most of the participants. They think it is nothing, just a joke of the day.

Publishing the names of the late arrivers in the meeting minutes is also a great idea. But this will again create a knotty situation for the team.

I think if the people who participate in a meeting can't cooperate to start their meeting on time, what chance is there they will cooperate to start a project on time? The same people who participate in meeting are the same people who are responsible for the tasks in a project.

I believe that a person who is not planning his things in a better way can’t join the meeting on time. Most of the time, people plan their schedule but not planning their schedule.

Does starting meetings on time truly matter? I believe it does. I read it somewhere that “If people are the organs of an organization, then meetings are the organization's lifeblood. The more healthy a meeting, the more healthy the organization. And, conversely, the sicker the meetings, the sicker the organization.”

In one of my earlier organization that I worked, we always started meeting on time. There were hardly some late attendees in the meeting. But one thing that was going on there. We started meeting at right time but the meeting ends late. I mean if the meting timings were 10:00 AM to 11:30 AM, it will start at 10:00 AM sharp but ends at 12:15 PM or 12:30 PM. Now what is going on here? Lack of agenda and lack of reformation of the discussions. Actually, what was happening that after the official discussions in the meeting, the team was discussing something else and 80% of times, they were discussing cricket. That is also not a good deal. That is the reason that agenda and end time is also very important.

Profitably starting the meeting with all of the participants required the cooperation of all the participants. If we are not planning our meeting timely and in a proper way, we are just playing in this IT industry and befooling ourselves.

-- Sanat Sharma

Levels of Requirements

Recently I joined a new company. I switched from an US giant MNC to an Indian giant MNC. So everything was new and that is the reason I am publishing my new blog after a long break. I was busy with those shifting activities and other stuffs to make me comfortable. So, let's come to business.

I will start this blog with one of my latest encounter. This time not with the development team (as usual) but with my test team member. Some times back, I asked with one of my tester a very basic question. The question was - What are the documents that you required to start the testing or at least start writing test cases? The answer was - Requirement documents. Then I continue my questioning and asked further -which type of "Requirement documents". I got the answer - "Requirement Documents, Sanat. You don't know what a requirement document is". I keep smiling and said "There are three types of requirement documents - Business Requirements, User Requirements and Functional Requirements. What do you want?” No answer from my counterpart.

Now the key point is that in today's business environment, the requirements can be (or should be) divided into three parts or you can say three phases:

1. Business Requirements
2. User Requirements
3. Functional Requirements

Business Requirement: What is the business perspective of this requirement? This requirement can be a single line also. For example: There is an attendance system in an office where each and every employee has to enter in a register placed in the security. Now I want to automate this process or make it convenient for the employees. In that case, the business requirement would be "Need to automate the attendance process and make it convenient for the employees". This is a single line Business Requirement that is required in this scenario. This requirement can also be elaborated depends upon other matrices.

User Requirement: How the user will interact with the system or what are the user requirements as compared to the business requirement? As the example goes on. In User Requirement, the things that should be covered are - "How the employee will enter the attendance automatically? How the user will interact with the proposed system? What are the most convenient ways to exchange the interactions between user and the system?". And lots of other things also.

Functional Requirement: How the system will be made? What are the functions required to fulfill the user requirements? In this phase, everything related to the development of the Business requirement and user requirement is mentioned.

So to start doing testing, I think Business Requirements should be clear in your mind and based on User Requirements and Functional Requirements, testing can be started.

-- Sanat Sharma

Number of testers needed

One of the most common Classic Testing Mistake is about "Planning the Testing Effort". That means how should the whole testing team's work be assigned?

Test leads (or managers) often need to make an initial estimate of the number of people that will be required to test a particular product, before the information or the time to do a detailed task breakdown is available. One thing that is almost always available is the number of developers that are or will be working on that project. Now the question is how to estimate the total number of people that will test the application.

From the last one and the half year of my testing experience as a Technical Lead (Testing), I also encountered this type of problem. Management always wants to know that how many testers I am going to assign in a particular project for smooth and ontime testing. Initially, I was not sure how to estimate this number but now I am pointing out some facts that needs to be taken care before doing this estimation tasks. In my opinion, number of testers needed for a particular project depends on following points :

1. Tester Efficiency
2. Tester time spent on other matters
3. Values and speed of finding defects.
4. Number of developers working on the project.
5. Amount of functionality
6. Developer efficiency at removing defects before tests.
7. Developers efficiency at inserting defects.

1.Tester Efficiency :

If your testing team members are efficient and sharp, you need less number of testers to test the application. That depends on the experience and the way of working of the tester. In one of my previous company, I was leading a team of three testing engineers. Out of those three, one resource was too good in testing. I always kept that resource with me in each application testing (if possible) for smooth testing. Infact. in my initial years of testing experience, my manager always trust me for testing of any of the application. And I always done my best to keep his trust alive. As a tester, what I believe is that, you should be methodical, systematic, tactful and diplomatic (but firm when necessary).You should be skeptical, especially about assumptions, and wants to see concrete evidence.

2. Tester time spent on other matters

If your testers are busy with different projects (maintenance/deployment phase), then as a test lead, you should consider this point for estimation. This is because if you consider that tester a full resource and he might be busy in some other project, your current application will suffer a lot. And also switching testing tasks from one project to another project frequently reduces the quality of testing. In one of my previous company, as a member of testing team, I was engaged in four different projects simultaneously as a main resource of test team. I tried to convince this point to my management that I am not able to perform well in testing for each application as switching from one project to other project frequently is diverting my mind. Surprisingly, the management agreed on that and done the needful to prevent the testing for all the applications.

3. Values and speed of finding defects

Again, a crucial point for estimation. Although this point is more or less similar to the first point. But there is a difference. If one of your test team member is very quick to find out the bugs in the application, then, definitely that is one of the major resource in your team. That doesn't depend on the efficiency, but on the experience, attitude (Test to Break attitude) and way of working. Now as an experience of around 6 yrs. in testing, I can predict, just after viewing the application, the approximate number of good issues in it.

4. Number of developers working on the project

This is directly proportional to the number of testers in any project. More the number of developers in the project, more the testers you require. Ideally the number of testers should be one-third of the number of developers in any project. i.e. if your application is being developed by 15 engineers, there should be atleast 5 testing engineers for proper testing. Again this equation can be changed if your team have some extraordinary testers. That means if your team have some good and intelligent testers that you can assume as a 1.5 resource (instead of normal 1 resource), you can change the number of testers accordingly. In one of my previous company, I was the only tester for a project where a team of 5 engineers developed the application. I am not saying that was done intentionally but it was due to the management issues. What I have done at that time is to work with developers and tried to get the bugs from them itself. I have done some diplomatic moves at that time and that project was successfully tested and delivered to the customer but not in the required time frame. A smooth working relationship between developers and testers is essential to efficient testing

5. Amount of Functionality

Amount of functionality also decides the number of testers that you have to assign in a particular project. Here amount of functionality means number of functionality that have been implemented for a particular project. This "Amount of Functionality" is somehow related to "Number of developers". More number of functionality that have to be implemented in the project, more number of developers required to develop it and consequently, more number of testers required. As a Testing Lead/Manager, this point should be taken care seriously because the test team member assignment depends a lot on this factor.

6. Developer efficiency at removing defects before test

Ideally, this is the point which should not taken care by the Test Lead/Manager. This is because whatever the efficiency of the developer, as a Test Team, you should work according to your efficiency. This means that you should not take this point as granted and should test the things thoroughly and with your full strength.

7. Developers efficiency at inserting defects

As a Test Lead/Manager, if you are aware of the developers work, then you can estimate the number of testers required to test that specific application.In one of my previous jobs, I worked with a very talented team of developers. Some of the developers (more precisely 3 ) are really brilliant in that team. After completion of that project, I again worked with only those 3 developers for some other project. So at that time, I realized that the development team have worked quite good and they are very less efficient at inserting defects in the application.

Products are better and cheaper to produce when everyone, at every stage in development, is responsible for the quality of their work
If you are not going to identify the defects, the customer would and that will be a gift from the customer that tells you how to test better in the future.

-- Sanat Sharma

Offshore Resources : + or -

Offshore resources are never a quick fix, especially for testing. A 2005 report from AMR Research found that it took between fourteen months and three years before the offshore testers had sufficient familiarity to be effective in finding the root cause of problems. Others have found that the lack of domain knowledge resulted in spurious defects being reported that actually increased development overhead due to review and response times. In fact, one organization identified that as many as 33 percent of reported issues were traceable to tester error. In one of my previous company that I have worked, testing have been outsourced to a different company. And in that scenario, 45 percent of the reported issues found by the outsourced testing team was due to the testing team errors. This is a real time scenario that I have faced. So companies that choose offshore resources as a way to remedy a resource deficiency, or keeping cost cutting in mind, might find themselves with higher costs and resource demands for one or more than one year. Without careful planning and realistic expectations, this confluence may end up eroding quality and extending schedules.

One of the major aspects that is coming out, is the instability of test environments. In almost all testing projects, this is a concern, more so, if environment/development teams are a in different location other than test environment. We have to manage this by placing environment support in the time zone of the offshore test teams and ensure quick turn around time.For the same company that I have worked previously, the testing environment is in the different location from where the testing team was performing. And to resolve this issue, test team has to visit their premises on daily basis spending most of their time in travelling and settling down their. Again not a good practice of offshore testing.

Organizations should not look at offshoring activities from the cost perspective only. Rather, organizations should look at offshore activities where they could develop a 24 hours model of testing/development and other efforts. The change in the mindset would immensely help to decrease the time to release their products to market.For any off-shoring operation, there should be consistent and meticulous planning by the people who are involved. Off shoring cannot fix all the problems. However, with the right push from the management and the right attitude from the people involved, it would be a smashing hit. The first thing that needs to be developed for the people involved in such an operation should be trust and sincerity. The processes,timesheets, effective output, defects tracking index etc., comes next.

Sometimes testing team suggests some improvements to overcome these type of problems. But test process improvements are often rejected simply because the management believe the improvements are nothing more than a self-serving attempt by someone to make a name for himself. They don't believe that the improvements really are meant for the good of the project. I encountered this type of scenario. In one of my previous company, as a senior test team member, I suggested some of the facts that were really helpful to overcome some of the issues that we were facing while testing. And the funny thing was that most of the higher management agreed with my opinion but due to the same point that I have mentioned, (self-serving attempt by someone to make a name for himself) no one respond back for the same. After that, I tried to convince my views in front of the management in other way. I keep producing positive results (rather than focusing on improvements)) with the same processes/infrastructure that they were following. Producing positive results will always be more beneficial than focusing on improvements because it will eliminate the belief that you're offering a new process simply because you don't understand the existing one.With my 6 years of working experience in QA and Testing, I have been involved in QA efforts as part of the off-shore operations for various products. We (myself and my US/UK counterpart) overcame these as challenges and solved everything to a stage where the Off-Shore team could function seamlessly in conjunction with US/UK. The reason behind this is the commitment and sincerity from the both sides to resolve issues. To top all of this we developed mutual trust as the first thing. We did not see each other as problem creators or as competitors, working for the same company.

The outsourced testing team sometimes is not so efficient (The word "efficient" is usually just a code word for "Cheaper" in modern day business environment). The quality of (outsourced) work can also at times be very poor . Some of the reasons for this can be : no domain knowledge, reluctance of offshore team to ask questions (specially when given inadequate specifications), lack of documents, lack of documented (and established) procedures etc. I have worked with developers & testers who are the very best (overseas and in India) and others who can definitely be classified as the 'worst of the worst' (again,overseas and in India). Once I went onsite in one of my project. I met a testing engineer who was physically challenged but that guy was full of energy and a true testing specialist. I really appreciate that guy and his attitude and he is a legend for me in testing domain.

A smooth working relationship between developers and testers is essential to efficient testing. Too much valuable information is unwritten; the tester finds it by talking to developers. Developers and testers must often work together in debugging; that's much harder to do remotely. Developers often dismiss bug reports too readily, but it's harder to do that to a tester you eat lunch with. Remote testing can be made to work - I've done it - but you have to be careful. Budget money for frequent working visits, and pay attention to interpersonal issues.

Software specifications are usually not written to such detail 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.Overall in my opinion, if the management cannot handle the things properly, offshoring resources is a bad idea.

-- Sanat Sharma