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