How to deal : One resource has raised a concern of work pressure.

How to deal : One resource has raised a concern of work pressure.

Evaluate the data to justify the concern. Try to evaluate the root cause of the problem.

Case 1 - He is overloaded.
  Soln: Rectify the task allocation and plan.

Case 2 - He is less productive due to lack of skills and hence takes more time to finish of the tasks.
  Soln: Arrange for training and coaching. Do some hand holding till he becomes self sufficient.

Case 3 - He is less productive though he has the required skill set and hence takes more time to finish of the tasks.
  Soln: If he is capable then motivate him( how? altogether a new topic to discuss) to get more productivity.

When to delegate? Ask yourself these 30 questions.

When to delegate? Ask yourself these 30 questions.

Delegate your task 'wherever possible'. Free up your time. Focus on the things where your attention is required. Hence your skills are better used.

Advantages:
1) As a leader thus you can help your team members grow and develop and earn their respect.
2) You can expand your work delivery and You would be prepared to take higher responsibility.


Now to explain 'wherever possible':

Right Person:

1. The person whom you are delegating the task, is he capable of doing the task?
2. Can he handle alone?
3. Is little supervision is required while the person executes the task?
4. Is the person a go getter/accountable in attitude?
5. How much knowledege the person already have?
6. What are his goals and interest? How do these align with the delegated work piece?
7.Will the delegated task provide an opportunity to grow and develop his skills?
8. Will the carrer aspiratioin of the person be fulfilled/partially fulfilled by the delegated task?


Right Way:

9.While delegating have you explained clearly your expectation?
10.Have you set the goals?
11.Have you share with him the big picture?
12.Are you going to periodically review about the progress if you are not fully certain about the person's capability?
13.Are you going to make necessary adjustments as and when required?
14.Will you be available for any queries raised ?
15.Have you explained why the job or responsibility is being delegated?
16.What is its importance and relevance?
17.Have you explained why the person has been chosen for the task?
18.Have you discussed about the review process for the progress?
19.Are you going to provide feedback on the delivery results?
20.Based on person's capability have you taken a call how much you can delegate in case you have decided to delegate a particular task?
21.Will he execute as per your instructions?
22.Will he analyse and take a decision on his own?
23.Will he discuss about the analysis and decision taken with you before he can go ahead as per the decision taken?


Right Task:

24.Find out the task which you are going to delegate, is it a recurring task?
25.Is it good enough to build one member to do these types of tasks in future?
26.How much mentoring is required to train the person vs output ?
27.Do you have time and resource to provide the training?
28.Have you thought about the consequences if not done properly - how much time would be left to complete the activity?
29.What is the current workload of the person whom you are delegating?

and last

30. Do you feel overloaded? Can you do better value added job in that time?

How to deal with an Irresponsible Team Member

How to deal with an Irresponsible Team Member


Background Scenario:

You are the manager of a team (onsite offshore model) . Your team members are exposed to the corresponding onsite counterpart i.e. they also interact with onsite team members on daily basis. Few of the projects you are driving from offshore site where team is comprised of both onsite and offshore team members. On the other hand your parallel manager from onsite is driving few projects, that too comprised of team members from both the sites.

Challenges you are facing:

Few of your team members are not responsible enough. Many a time your parallel onsite manager needs to follow up with the these offshore team members about the status update. A number of times it also happened that he got shocked at the last minute that the assigned task has not been completed and no alarm was raised by them. As a result your reputation is also going down as you are the manager of the offshore team and consequently responsible for the whole team.

Despite of few reminders and coaching from your side the team members are seemed to be not correcting themselves and now it is the high time to take some actions more diligently.

Here are few thoughts on this perspective what you can apply based on your situations.....................

Before you implement any of the following action, first and foremost call the team for team meeting and discuss with them that there is some dissatisfaction from the onsite team which you have come to know from the previous day's meeting with the onsite manager. It was raised that there is some lack of responsibility noticed within the team which might be bigger concern in future. Hence you are going to take the below few actions to streamline the process. Also say that it is good that the manager brought this issue to your notice before it could go for higher escalation and things could be completely different in that case. You can also mention about the higher management in the onsite team, how they are more particular about the commitment.

1. Include Manager in the mail loop

Ask the team members to keep you in loop in each mail exchanged with the counterpart.
Make them understand though you are not contributing anything to the project (as that project is driven by your parallel onsite manager) but your responsibility include to make sure your team members completes their assigned task within stipulated time. Hence you need to be in the scene to know what is happening.

Also make sure that your team members understand that in case they receive a mail from onsite without you in loop, but while replying back they should include you in the mail thread. Also ask them to forward any mail which comes from onsite without you in the loop and the mail does not require a reply, else you will miss the information in the mail. In this way you can get hold of the situation.

Meantime also communicate to your parallel onsite manager that due to the concern raised by him you are going to take few steps to control the situation and you have decided to be in the mail thread so that situation does not go out of control. If you don't communicate this beforehand, chances are there he might get offended to see you in every mail suddenly where as the project is driven by him. Mention that you will act as a passive observer as long as your team members are proactive and acting responsibly and only come into picture if you see your team member lacks any kind of commitment.


2. No follow-up mail from onsite and be proactive


Mention clearly to your team members that immediate objective would be there should not be any follow up mail from onsite henceforth. Also there should not be any status enquiring update from the onsite team as well.

How to achieve that? Each team member should be proactive and update the status. He should communicate to the onsite in case if he is facing some blockage which is hindering him to achieve the assigned task proactively.


3. Daily status report

Ask you team member to send daily status report to onsite team in case this process is not in place keeping you in loop.

You might get a number of arguments that what will be achieved in one day to mention in the status report etc etc. But you be assertive and tell them how they spend the day should go into the status report. Insist that even if they are doing some R&D , mention specifically the same in the status report (Personally I am very scared of this word when a team member says that he/she is doing R&D on a particular issue, it is a very commonly used word by an irresponsible person to dodge the assigned task ! So beware !) .

To give a more clear picture on this what i men to say here....

As for example say in a banking domain project the team members is to validate an issue after it got fixed by the developer on stop cheque payment functionality.
He might say he was exploring what is stop cheque payment functionality before he goes ahead and validate the defect. As a result end of the day towards the activity he does not achieve anything e.g nether reproduce, nor set up the environment, nor validate the issue. What to mention in the status report.
But you insist that he should mention the same i.e. he spend the day exploring the domain knowledge (stop cheque functionality) for the day. At least thus you will come to know how the guy is spending 8 hours in the office!
Hence they will be forced to mention something concrete in the status report which they should achieve in 8 hours time in the office when they have to write in black and white. Else it will be very vivid to everyone there is not proper time utilization.

One more argument you might face that they might also tell that it will take time to report the status report every day.

Mention that, "I think it should not take more than 10 minutes time from you. In case it is taking more than this then I think I need to arrange a training on how to write a status report for you." I am sure after this statement nobody will say anything.

The idea is not to dare them but you should be assertive enough if you yourself belief that it should not take more than 10 minutes or whatever time you feel is justified.


Advantages of asking them for a daily status report are many fold.
It will force them to do some measurable activity by the end of each day which they can site in the status report for the day.

One more thing you should say that the status report must be send from 5:30 PM to 6:00 PM time every day because it will be easier for the onsite manager to see the status for the day with the timestamp as each team member is going to send an individual report and this is not going to be a consolidated one. Never ever go for consolidated report. Irresponsible persons are always look out for combining their status with others. Even if you are going for combined status, make sure each one's contribution is sited separately.
One might also argue that he works late and comes office late, so for him it will not be possible to send the status report by 6 PM. Mind it these all are excuses. Tell it to him that the task achieved after the 6 pm should come for the next day's status. You will also get the idea how they are progressing and can apply any corrective action if required for the next day after going though the status report by 6 PM. This will inculcate a discipline and regularity in the team.

In the status report ask them to mention

1. What they achieved on that day
2. What they are going to do on the next day
3. Anything is blocking them to achieve their assigned task
4. Any risk they foresee which might hinder them to accomplish the assigned task

Last but not the least the most important thing is
5. % completed of the overall assigned task -- it will push the team member to do something concrete every day to make it an incremental figure

So in this way,
In a 20 days project after 10th day all of a sudden you will never get a shock of hearing only 5% done ! Because in this case you are monitoring on daily basis.

Finally Staus as Red/Yellow/Green - This will act as an early flag based on their comfortability of completing the assigned tasks.

Ask them to keep track of their own task. Also mention that if they feel they are behind the schedule to raise an early flag proactively.



4. Availability of Plan B Task

Ask them to do the part where they have some dependency to the onsite team members e.g. where they will be waiting for some information from the onsite.

Otherwise scenario would be:

5 o'clock you are seeing your team member is very relaxed and playing TT where as a critical issue has been assigned to him. Upon asking him, he will answer in usual way that he is waiting for some information from the onsite. Until he receives the information then he can't progress and his body language reflects that he can't do anything in this world but to play TT !!

So inculcate a habit of keeping plan b task ready in case they are blocked. i.e. complete those tasks where there is some dependency and complete other tasks when you are waiting for the information from others. Encourage them to plan accordingly so that he does not need to sit idle. Idea is to utilize the time properly.


5. Get a buy in


Make them committed. Before assigning a task discuss with them. Make sure they are comfortable and get the buy in from them and thus make them responsible for completing the assigned task.


6. Link appraisal

A very easy way to motivate your team members!

Link appraisal with every commitment failure, every follow up from the onsite, every instance of failure of status update

i.e. Appraisal goal should state that
less than 1 commitment failure/quarter,
2 follow up from the onsite/quarter,
2 instance of failure of status update/quarter


7. Motivate

Praise profusely when they achieve and reprimand when they can not (in case it out of sheer lack of responsibility)


8. Make them commitment driven and goal oriented

Tell them to ask themselves the following question each day
"How can I accomplish the assigned task" and do accordingly.

Tell them to

"Be result driven. Do whatever you feel like doing but you have to achieve some progress by the end of each day. Do research. But you can not do indefinite research and at the end can not say solution is not found. Constantly you have to keep an eye in the timeline as well. You have to raise an alarm if at any point you feel you won't be able to achieve the target. Be goal oriented. "


9. Some preaching in the team meeting - elaborate on each yourself !

More responsibility you handle, more responsibility you will get.

Do not blame others or give an excuse. Rather accept it. Acknowledge your mistake.

Communicate early if you can't deliver but deliver what you have committed to without fail.

Once committed you are answerable.

Samples - How to provide interview feedback - Candidates on Testing

Selected Candidates for next round:

Good concepts on Test Scenario and Test Case derivation from Use cases. Has good understanding of Test Coverage, Test Reporting. Has concepts of different kind of testing. Has high level awareness on different section of Test Plan.
Has got good domain knowledge on Financial - Trading. Shows interest and puts effort to gain knowledge on domain worked.
Has experience on QTP and has got clear concepts whatever he has done so far.
Did not get chance to work on SQL much and hence lacking skill on SQL


Has got fair idea about Test Plan
Has exposure to test case derivation, Bug Life cycle
Has concept of Functional, Regression, Unit and Integration testing
Is aware of Test Suite setup, Test data creation
Has scripting knowledge (VB Script)
Confident about what he has done; Else says clearly does not know; Does not try to bluff
Has got good positive attitude and willingness to learn
Current role is write code to test


Has good concepts on Test Scenario and Test Case Derivation; Well aware on Test Reporting and Test Coverage.
Has got good high level ideas and awareness on different section of testplan with 2.5 yrs of experience
Does not have exposure of creating the Test Environment but Has worked on VMware tools and has clear concepts on it.
Beginner level concepts on QTP- Automation.
Fair knowledge on SQL


Has 1 year experience in development (Oracle 7.3, Developer 200) and 4 years experience in testing
Has fair understanding of Test Plan, used to prepare the draft version of Test Plan
Is familiar with Usability, Regression, Functional and Smoke testing
Has good understanding of Bug life cycle
Has basic concepts of SQL database and fair in writing SQL query.
Has exposure to Blackbox testing but no exposure to whitebox testing
Is familiar with V model of testing methodology.
Has fair understanding of preparing Test Summary Report.
Good in Automation using WATIR tool using Ruby language


1. Good testing concept; Have exposure to Functional, Regression, GUI testing; Has the concept of performance testing but did not get a chance to work on this
2. Has good exposure to deriving test cases and test scenarios; Has not involved in Test Plan preparation but has the awareness of the sections in Test Plan
3. Good communication skill - has ability to express and explain clearly
4. Has knowledge on Status Reporting
5. DBMS - Has basic knowledge on SQL query writing
6. Has worked on scripting and automating using WinRuner and QTP
7. Has got analytical and problem solving skills


Has very good knowledge of Testing methodologies and Testing concepts (with 3 yrs experience) Has good concept of Test Plan preparation, deriving test cases
Has good concept of Bug Reporting and Bug Life cycle
Has average knowledge on Status Reporting
Knowledge on SQL Query - Poor
QTP Automation - has knowledge on Record and Playback - no scripting knowledge
Communication - Good - has ability to express clearly


1. Well aware of different SDLC e.g. Waterfall and Agile.
2. Excellent Communication skill
3. Excellent attitude - always looks for how customer expectation can be met and exceeded.
4. Very eager to learn new technologies and tools
5. Testing concepts are very clear and technically good.
5. Very good interpersonal skill and can be very good team player.
6. Has exposure to SQL Database.
7. Has positive attitude.


During the course of the interview I felt he has got good positive attitude and eagerness to learn new things. Given a situation, he shows flexibility by saying that he has no problem acquiring the skills and work on new field where his expertise does not lie. He tries to keep himself aware of the fields even if had not got a chance to do that, as for example though he was not involved in Test Plan writing he is quite aware of the different section of the Test Plan. Otherwise he is clear with general testing concepts, Bug life cycle, status reporting and technical knowledge.
Overall I feel with positive attitude, an eagerness of learning and with minimum guidance he can quickly pick up the skills where he is little low.


Rejected Candidates:

Has no exposure to preparation of Test Plan and Test bed setup
Could not derive effective test cases given a scenario. Does not have concept of Test case prioritization and Testing coverage.
Has average knowledge on different type of testing. Does not have clear concepts.
Test Report knowledge is very minimum
Automation knowledge is below average. Seems only theoretical knowledge, not practical/hands on experience
No knowledge on SQL database
Communication - Average


Does not have much awareness on Test Planning, Test data creation but mentioned in his resume
Could not derive good test cases when given a scenario
Does not have good trouble shooting and analytical skill.
Has average knowledge on Functional and Regression testing
Does not have basic of SQL clear
Limited exposure on Automation - using a tool iTKO Lisa, Does not have exposure on QTP though mentioned in resume
Does not answer to the point of the questions asked
Observed that many things were mentioned in the resume but he does not have exposure and awareness e.g Test Planning, Test Data Creation, Performance testing, QTP etc
Communication - Average


No exposure and awareness of test plan
Average knowledge on test case derivation - mostly theoretical knowledge - could not answer properly if given a scenario to derive from there
Has average knowledge on Functional, Regression Testing and has no concept of Unit and Integration testing but claims he has worked on Unit testing
Average knowledge on Bug life cycle
Poor on SQL database
Test Report knowledge is also very limited
Seems to be not very flexible
Does not know about the concept of prioritizing of the test cases, traceability matrix, necessity of configuration tool etc
Communication - Good


Average knowledge on different type of testing. Could not explain properly functional, system, sanity and smoke testing concepts.
Poor SQL knowledge, could not explain the why primary and Foreign key is required. Also could not answer to simple SQL query
No exposure to Test plan preparation and Test bed setup
Candidate does not answer to the point, even if he is unaware of the answer still says something which not at all asked for
Communication - Average


Limited exposure to preparing test plan, Test cases and Test Bed
Has average knowledge on Functional, Load and Stress testing
Could not answer some scenario based question upto the mark
No knowledge on SQL database
Test Report knowledge is also very minimum
Communication - Ok


Has awareness about different sections of the TestPlan
Has fair understanding of V Model
Has exposure on Functional and Regression Testing and Test case derivation
No exposure in Test environment set up
Has basic understanding of SQL database but not very familiar about query writing
Has experience on QTP 9.2 and QC 9.2
Communication - Average


Limited awareness of test plan preparation and Test case derivation
Average knowledge on test case derivation, testing coverage, prioritization of testing and Test Reporting
Average knowledge on Bug life cycle
Does not have clear concept about the different kind of testing and when it occurs in testing life cycle
Could not explain any testing methodology properly
No exposure on setting up the test environment
Limited knowledge on Automation using Rational Robo
No knowledge on SQL database
Communication - Average


Has average awareness on Test Planning
Has good exposure on Functional and Regression testing. Could derive test cases when given a scenario.
Has average knowledge on Test coverage and Test Reporting
Has good knowledge on Bug life cycle.
SQL knowledge is not upto the mark.
Does not have much exposure in Automation. Undergone training on QTP but not hands on experience.
Communication - Good


No exposure and awareness of test plan
Average knowledge on test case derivation - mostly theoretical knowledge - could not answer properly if given a scenario to derive from there
Has average knowledge on Functional, Regression Testing and has no concept of Unit and Integration testing but claims he has worked on Unit testing
Average knowledge on Bug life cycle
Could not answer some scenario based question upto the mark
Fair knowledge on SQL database
Test Report knowledge is also very limited
Communication - Ok
Hence I can say the candidate is below average for QA Concept and will not be suitable for the position.


The candidate is good in Manual Testing. But lack skills in Automation and SQL. Moreover the candidate has a expectation of getting a lead role of managing 4-5 members and also mentioned that the currently he is more into assigning the tasks to junior members. As we are looking for individual contributor role with interest on hands on, the candidate will not be suitable for our team.


Does not know the difference between Functional and Regression testing - carries out same set of testing against all the builds - answered as first time called functional and second time onwards called regression testing
NO concept of configuration management tool - answered as used for only security purpose - authorization purpose
SQL Database - no exposure to SQL Query, did not try to attempt even
Poor knowledge on Windows - does not know how to kill a process, no concept on Registry, does not know how to find out the IP of the machine
Role is only test case writing and execution - no exposure to test environment creation, [separate team deploys the build and pass the test environment to test team]
Could not answer some scenario based question -
what will you do if you raise a bug and dev team is saying this is not a valid bug
what would you do if time does not permit to execute all the test cases
Test Report knowledge is only limited to only bug reporting
No direct interaction with developer - Lead was doing all the interaction.


{Strong points:
The candidate has good exposure to different kind of testing e.g. functional, regression and a little bit of performance testing though he has not carried out in a very structured manner but he has good concepts.
He has good understanding of basic Testing concepts e.g. deriving test scenario/test cases, Test case prioritization, Test coverage, Bug life cycle.

Weak points:
SQL exposure very minimal.
Did not get any chance to work on Automation. Explored QTP on his own interest.

Soft Skill:
Communication - ok. The candidate seems to be very energetic and worked in a close knit project group (dev and QE) in a start up company. Also seemed to be eager to learn new things.

Conclusion: I felt the candidate can be moulded and would be flexible and eager to acquire new skills as the project demands as he is in early in his career.}


Has exposure to deriving test cases. No exposure to deriving test scenarios and no involvement in Test planning (with 4 yrs of experience)
Has average knowledge on different kind of testing
Has good understanding of Bug Reporting and Bug Life cycle
Has average knowledge on Status Reporting
Poor knowledge on SQL Query
Has average knowledge on QTP automation
Communication – Good – has ability to express clearly


Has got experience on working in Onsite and offshore model. Has got experience on transitioning from onsite to offshore being at onsite and taking all the knowledge transfer, planning and preparing transition estimation
Has got experience on QTP and demonstrating automating a subproduct as poc to customer
Has hands on experience on Winrunner and leading a team in automation
Has got experience on Performance testing using WAS
Has got experience on Manual Testing (Integration and Regression testing)
Has got experience in domain Insurance, Education and Internal applications
Is Certified in ISTQB (Advanced – Test Manager)


1. Has good hands on exposure in both Manual and Automation testing. Thinks out of the box and come up with ideas. Open to both kind of testing (manual and automation) . Has also got some experience in Performance Testing, worked on tool e.g. WAS and Load Runner.
2. Has got good understanding of different type of testing.
2. Has got good experience in QTP, .net Framework and VB on automation side and can provide his guidance to the team on automation front.
3. He answers to the point and clearly says where he does not know.
4. Has got experience on Status reporting and interacting with client. Keeps client's perspective in mind.
4. Weak area - Did not get satisfactorily answers on Test Planning, Estimation, Task identification and Scheduling stuff.

Migrating the test cases from unmanageable to manageable

For a large project over the time it is normally found that the test cases grow to a large extent especially release after releases, however often with the tight schedule of ongoing project delivery, the test cases are not maintained properly. Finally one fine morning you discover that the test cases become unmanageable. It has really become cumbersome now and drains a lot of effort to train a new joiner especially when test scripts are not maintained with enough comments / when purpose of writing a test case has not been captured in the test cases / when the functionality the test cases is trying to test is not mentioned clearly. The test cases were just added and added and added during releases based on the requirements without any thought of maintaining it for future.....

Hence it becomes difficult now to identify and pick up some test cases from the test case lot for the purpose of testing/regressing functionality xyz for Release xxxx (say).

Sound familiar in your project too!

So managing the test cases becomes an important task to make a testing team more effective.

The problem seems to be more severe when you discover that the higher management will not be willing to deploy resources for this kind of activities which were not done correctly in past and you have no other choice but to take up this activity of cleaning the test cases (which itself is a major effort itself ) along with your critical project delivery without hampering it a bit. After all you can not jeopardize your ongoing project delivery at any cost. Can you :-)

Here I have cited few of the ways what you can try in your project once you are at similar condition and you want to take up the task of cleaning and properly managing the test cases for future then on.

1. Prioritize test cases

First of all it is required to identify the Test cases as priority 1, 2 and 3 if it is not already done.
It is not at all possible or not feasible to take up all the test cases at one go along with your regular project work and clean up. So the best way is to prioritize them and take them up in phase wise.

Suppose 1000 test cases are there. e.g. Identify 200 odd test cases as priority 1, 400 as priority 2, 400 as priority 3. Prioritizing is the first and foremost task.

Priority 1 test cases are test cases which test the very basic functionality/core functionality of the product.

e.g. for a mobile handset testing test cases should include
Whether you can make a call/ receive a call, send and receive message, save a number etc,
dial the number and call, pick up a number from the saved list and call etc etc.

2. Categorize test cases

Also categorize you test cases in different folder such as

Negative testing
Stress testing
Load Testing
Functional testing
Usability testing

If for a particular release customer is expecting only enhanced look and feel of the product, then you don't need to break your head and search test cases at Stress/load testing test cases at all...

3. Brainstorming and finalization of the standards/approach

Give one week of time to your team members. Ask them to come out with the ideas how to approach on cleaning and maintaining the test cases better for future.

You could also charge them up by linking this activity with rewards, e.g. the person who adds maximum value will get 1000/- voucher etc etc..[Do not make mistake of deciding whose contribution is best by yourself. Ask your team only to decide. Best option would be deciding by voting system.]

Once all the ideas are submitted, brainstorm on those ideas as a team. Book a conference for 3-4 hours and brainstorm exhaustively. Take up an idea and see the applicability, pros and cons etc and finalize the approach. With those finalized ideas set a guideline on what are the approaches you will take while cleaning/managing the test case for future.

Modify 2-3 test cases according to those guidelines. Now sent the guidelines and the modified 2-3 test cases for review. Review should be done from the junior most engineer to senior most manager (from inside or outside the team - whomever you think can add value). Most importantly give it to a new joiner and see whether he/she can understands on his/her own i.e. whether the test cases are self explanatory ( i.e. the test cases are elaborated enough and captured enough info and the new joiner can understands on his/her own).

Receive your review comments. I am sure you need to do a lot of follow up to get your review comments!

Once you receive the review comments, modify the guidelines accordingly. Now set the baseline for the guideline.

4. Set the guideline as Bible for your team now on. (Whenever a new test cases being added this bible should be followed).

5. Take up the whole effort as a project in phase wise

Take up the whole effort of migrating the test cases from unmanageable to manageable as a complete project.

Divide the project effort in 3 phases. You can take up priority 1 test cases in phase 1 and try to implement the standards/guidelines first. That is, Try putting a small investment and see how the investment is paying off.

6. Resource utilization (keeping in mind the ongoing release activities)

You can try this model of utilizing the resources.

You can deploy 1-2 full resources in this Test case management project depending upon the bandwidth and the criticality of your ongoing project delivery activities (basically what makes sense based on your ongoing project delivery condition).

Rest of the resources who are completely deployed on ongoing project delivery, can be given a long term deadline e.g. every two months 5 test cases needs to be modified /person. Thus later point of time you may find out that a significant effort can be absorbed along with the ongoing projects and also thus you can inculcate a sense of responsibility of maintaining the test cases properly by all the team members in your team.

7. Educating new joiners

Modify 1-2 test cases with max comments/info.
Explain the flow of the code to make them understand and record your explanation.
Give the recorded file to the new joiners and see whether they are facing any difficulties in understanding those on their own.

Thus you can save significant time of the existing team members who do not repeatedly explain the test cases every time a new member joins the team.

Also record how your test cases are segregated and how you are managing your test cases in the recorded file so that the new joiner need not ask for any kind of info from the existing team members.


8. Few ideas (subject to applicability to your project)

a. Capture as much info as necessary in the test script
who has written
what purpose it is done
CQ id
Requirement ID
functionality - what it is going to test etc etc

b. Create reusable modules / scripts - thus managing them would be easier and also writing new script would be easier

c. Version control might help; you can go back to previous version and can run if the necessity arises

d. Always keep an eye how you are developing the test script /test cases and how you can reuse in future (the already existing scripts)

e. Give proper access control for maintaining the test cases.
who will have read permission
who will have read/write permission
who can add new test cases etc etc.

f. Discard not relevant test cases / invalid test cases

g. Look back after each release and clean the system. Transfer not relevant test cases to an obsolete folder

h. Do a cost benefit analysis before diving into changing the whole suite.

i. Map Requirement with Test cases
You will be able to know for a particular requirement how many test cases are there at a glance. Also based on the requirement you can pick up the relevant test cases

j. Keep executed Test cases release wise in Quality Center - Test Lab Tab.

k. Collaborate with developers for minimum user interface change in order to minimize the rework effort of test case/ script change (of course without compromising with quality)

l. Last but not the least; Put a process in place for adding new test case. Say one person is in charge of reviewing the new test cases. i.e. the newly added test case needs to be reviewed and accepted by the person before it gets added into the Quality center which will ensure standards/guidelines are followed correctly till the process gets streamlined by all the team members.

Else who knows , you might end up doing the same kind of cleaning activity again in near future !

QA/Testing Team’s Goal

A: stands for Objectives
B: stands for Measurement Criteria


1. Work Delivery and Process Compliance

A: Maintaining productivity
B: x% increase in productivity for the whole year
A: Delivering on or before the scheduled date with high quality.
B: # of instances not meetingQuality : less than x% Sev 1 & Sev2 defects from TS / customer.
A: Adherance to process laid down in the team
B: # of instances of not following
A: Timely escalation of Project specific issues.
B: # of instances done
A: Quality of Test Plan and Test Cases -
B: # of defects found in Test Plan & Test Cases.
A: Test Case writing
B: Number of test cases written per week
A: Test case execution
B: Number of test cases Executed per week
A: Defect Validation
B: Number of defects validated per week
A: Proactively add test cases wherever gap is found.
B: # of instances done
A: Updating test cases end of every day after the execution
B: # of instances found not updated
A: 100% coverage of requirements in Test cases
B: # of instances found not done
A: Number of defects filed - Quality Quotient (# of Sev1 * 4 + # of Sev2 * 3 + # of Sev3 * 2 + # of Sev4 * 1)
B: Rating obtained
A: Invalid defects should not be more
B: Among the raised defects not more than x % should be invalid (Duplicate, Not a Bug, User Misunderstanding/Working as designed)
A: Clarity of the defects logged which should include clear description, steps to reproduce and appropriately filled other relevant details.
B: Query raised by Dev team
A: Timely review of the docs.
B: Number of instances not giving review comments
A: Status report should reach in time without follow up
B: # of instances required follow up
A: Action item needs to be tracked and completed in stipulated time
B: # of instances not done
A: Shows flexibility to work (willing to work on different workstream, different kind of testing)
B: # of instances done

2. Test Environment Creation

A: Take backup once the test environment is ready
B: Time taken to backup the environment
A: Ability to restore the backedup environment at any point of time
B: Time taken to restore the environment
A: Contributes to intranet and the information are up to date
B: Number of contribution and quality of the contribution
A: Optimally use of Software and Hardware resources
B: Report on effective use of resources

3. Product Knowledge

A: Ability to simulate close to the production environment as possible with the available software and hardware resources
B: Time taken to set up the environment
A: Ability to set up the end to end environment for testing and deploy the components
B: Time taken to set up the environment
A: Ability to diagnosis the customer issues and thus helps customer support people
B: # of times helped to diagnosis the customer issues
A: Ability to draw a comparison of the product feature against the competitor's product on the same line
B: Depth of value added
A: Document the steps of installation with the screenshot and a document on how to configure, how to overcome the problems faced during installation and configuration and thus create a knowledge base
B: # of documents prepared
A: Ability to make judgments on adequacy of testing coverage and quality of defects
B: Reports on testing coverage
A: Ability to prioritize the test cases, identify blocking issues which is must fix before the product goes live
B: Reports on this and # instances done
A: Ability to optimize decisions pertaining to test execution based on the areas needing focus and available timelines, identifying areas needing improved test coverage
B: # of instances done
A: Ability to strategizing the test automation
B: # no of times taken the initiative to automate
A: Keep a track of own learning about the Product knowledge gain. Must increase in every quarter
B: Progressive increase in product knowledge

4. Domain Knowledge

A: Ability in writing test scenarios in line with the business work flows
B: # of instances done
A: Read online resources and come up with presentation
B: # of instances done
A: Ability to suggest new functionality which will help the end user
B: Suggestion made v/s accepted
A: Be aware of the upcoming functionality/technology on domain front
B: Shares knowledge among team members
A: Ability to understand the entire business workflow , not only about the functional knowledge
of products owned by the team
B: Clarifying queries
A: Ensure that QA team analyze the defects filed by customer for the previous releases and make sure that same scenarios are converted to test cases for the upcoming release and gain domain knowledge on how the customer are actually expecting out of the product.
B: # of instances done

5. Communication & Team Player

A: Communications should be timely, clear, concise and readily understood by intended recipient
B: No further clarification required
A: Clear and concise status reporting
B: No further clarification required
A: Timely escalation of issues / problems
B: # instances done
A: Maintaining good relationship with team members
B: Complaints from team members
A: Proactively helping the team members/cross team members in Project related activities.
B: Feedback needs to be taken from the cross team members
A: Activley participate in the meetings and contribute.
B: # of instances done
A: Not disclosing confidential information (salary and appriasal rating etc)
B: # of instances done
A: Extending help to other teams in need within team / organization level.
B: Feedback from others
A: Number of presentation given within Team/organization
B: # of instances done
A: Knowledge sharing and mentoring new joiners
B: Feedback needs to be taken from the person mentored

6. Training and Knowledge Sharing

A: Giving detailed trainings to new joinees by scheduled date.
B: Feedback Mechanism
A: Training on tool/Technology
B: Feedback Mechanism
A: Attend trainings as per the identified training need
B: Shows increase in productivity/understanding on the related fields after attending the training
A: Participates in knowledge sharing session in team level
B: Feedback Mechanism

7. Ownership and Commitment

A: Showing a sense of ownership, takes complete ownership of the tasks given
B: # of instances done
A: Have a can do attitude, if can not be done in certain way suggests alternatives
B: Suggestions made
A: Come out with some constructive ideas which can be achieved in the period while waiting for the dependent task to be completed and thus add value by utilizing the time effectively
B: # of instances done
A: Proactively acts on tasks, informes about the advanced leave plan, Takes responsibility to to educate the team members to handle in case of his/her absence
B: # of instances not done

8. Innovation

A: Exploring Innovative ways to accomlish work. Come up with innovation/improvement areas
B: Number of suggestion made vs Accepted
A: Helps to define new process and putting the process in place. Tries to improve the process efficiency
B: Number of suggestions given
A: Publish white papers on areas of interest
B: # instances done

9. Client Management

A: Client satisfaction
B: Accolades from client
A: Client communications and relationship
B: Bonding with client
A: Client negotiation
B: Negotiating effectively with client for win-win relationship
A: Awareness of client roadmap and strategy
B: Project planning and risk planning

Unusual ways to find bugs quickly

Have informal chat with developers and try to find out
1. What are the functionalities/functional areas they are struggling to code?
2. What are the functionalities for which coding effort has been shared by more than one developer?
3. What are the last piece of functionalities they are stretching themselves to finish it off within the deadline?
4. What are the functionalities where the requirements are not that clear and developers are having more discussion with the product manager to know the expected behaviour to write the code accordingly?
5. What are the functionalities they have coded after coming back from the long vacation?
6. What are the functionalities which was assigned to Developer A and later transferred to Developer B with a short notice?
7. What are the functionalities coded by the developer who is actively looking for a job outside?
8. What are the functionalities coded by a developer who has already resigned?
9. What are the functionalities coded by a developer who is technically not very strong/disorganized in nature?
10. What are the functionalities coded by a developer who is not focused enough (who goes to have a cup of coffee, tea a number of times in a day / always on chat/ social networking sites)
11. What are the functionalities coded by the developer who is not very confident about his code and keeps asking the tester whether any bug has been found out in periodic basis?