Monday, November 5, 2012

Sample: How to fill up Appraisal Form ( by a Junior Test Engineer)

Sample: How to fill up Appraisal Form ( by a Junior Test Engineer)




A1 - Quality of work:

1. The area I have tested , no bugs were found later from customer side.
2. The customer issues which I verified, no complaints were raised from customer side later.
2. My work has been appreciated by manager, developer. (Attached are the mails)

email 1:"..........."
email2:".............."



A2 - Work Output:

I have worked on the following releases last year.

i. 7.2 Sp3
ii. 7.5 Sp2
iii. PM
iv. 7.2 SP4
v. 7.5 FP3
vi. 7.7 FP1

Major contribution on the above releases

i. 7.2 SP3 - Verified 17 customer issues, mostly Billing side and server side area. Most of the issues were severity 2 issues.

ii. 7.5 SP2 - I did the regression for B module.
Successfully installed and configured this component.
I executed 46 test cases out of 69 test cases.
The challenge was huge and it was completely new area.  Here is the onsite manager's comment "..............."

iii. PM
I single handed managed this module. I communicated with the developer and collected the specification. I also used to prepared status report daily for the test case execution and any issues found. Also communicated to onsite manager directly for the work progress on daily basis.

iv. 7.2 SP4
I verified 8 issues out of which 5 was customer issues. Apart from this i did regression of G (90%) , B(82%) and also did smoke testing of I (Hp-UX), P (Hp-UX, solaris), R (HP-UX, Solaris and Win XP)
and B ((HP-UX, Solaris and Win XP) modules

v. 7.5 FP3
Mentored new people. Helped team members in the regression areas. ( Mr. P - for G module)
I did regression testing for CON module which was new to me.
Verified 6 issues out of which 2 was customer issues.
Raised 10 issues.
Performed Smoke testing of the following modules:

B - Solaris and HP-UX
I - Solaris and HP-UX
P - Solaris and HP-UX
R- Solaris and HP-UX
PT on Win Xp



A3 - Accountability:

I have completed my assigned work within specified time across all the releases as mentioned above. If required i came on weekend and finished off my job and thus met the deadline.
For instance
1..........
2..........
3.........



A4  - Required knowledge base:

My responsibility includes
Regression testing
Issue verification
Raising issue
Writing Test cases
Smoke testing
Installation and Configuration
Mentoring New joinees
Helping other team members in my expertise areas

I am successfully doing all the above responsibilities which imply my knowledge to perform my role effectively.

I am self driven and always prioritized my work and completed as per the schedule. My goal is not only raise the issue but also follow up with the developer and get it fixed and thus deliver a high quality product.



A5 - Team work:

No complains from team mates
I get along with everyone very easily.

I helped below mentioned people on their task apart from my assigned work which implies I am always ready to help my team mates and am very good team player.

Rsdad - GL
Pgfg - B
Sghfh - MC
Rgdgh - B
Dfgdg - AT
Wghgg - Verification of customer issues

Apart from this I have given TOI to following colleagues

Pfgd - GL
Bfdh - B - Showed installation and configuration and explained functionalities of the test cases
Phfh and Vcgcgh - P module - Showed installation and configuration and explained functionalities of the test cases.
I have so far worked with Rfgdg ( 7.2 sp3) ; with Sghfgf (7.5 Sp2); withVfgdfg(7.2 Sp4); with Aghf (7.7 FP1 7.5 FP3) without any problem.




A6 - Communication:

I prepared MOM of weekly status report and published it to my team
For my raised issues, developer never asks for more info which implies i wrote the reproduction steps correctly. (CQ can be referred)
The test cases which i have written are well understood by a new person.

Proactiveness:
When my mail id got removed from the alias I asked my manager and onsite manager to send me mail separately anticipating a risk of missing a mail.
While planning a long vacation i always communicated to my manager well before the time so that in my absence work should not get hampered.




A7 - Flexibility and Ability to change priority:

I have been assigned with a number of regression areas. First  I concentrated on core areas and then the additional modules. Thus i prioratize my work. Also if there is any customer issues , I always  make it a point to complete that task first. I have always been performing multiple tasks successfully as mentioned in A4 point.



A8 - Initiative :

I am part of quality forums and taking part of preparing templates and giving inputs.



Wednesday, October 10, 2012

Sample 1 : How to fill up Appraisal Form ( by a Test Engineer)

Sample 1 : How to fill up Appraisal Form ( by a Test Engineer)



Communication:

Clearly communicated to Team members, Manager.
Provided the status to Manager without fail/followup from Manager.
Asked for guidance to manager clearly whenever needed.
Communicated well to cross team members, lead and manager.
Communicated via email/conf call with onsite team members/leads and managers.


Productivity:

I have exceeded the target in the execution of test cases. Executed x test cases/week, target was y test cases/week
As my responsibilities also include many report generation , follow up and helping the team members ,still I am able to maintain to achieve the target as an individual contributor along with lead activities.
Always try to find out new ways to accomplish the work and thus be more productive. e.g - give few examples.


Process Compliance:

Always followed up the process.
After writing the Test Plan document for WU module sent it for review (internal- Dev team, external -onsite Team)
Followed the Team track process.
Followed up the TD process e.g. changing the status of test cases accordingly to pass/fail/blocked/NA.
Always make sure to put defect id against the Failed test cases. For cross reference please check Test Director.
Creating the User Stories/Tasks in the Xplanner
Regularly updating the Tasks in the XPlanner


Task Effectiveness:

Timely escalated project specific issues to manager,Dev team,Onsite QE counter part.
Towards the end of AU release, module testing came which was not planned earlier. Still maintained the productivity and delivered a high quality while testing Modules as part of AU release.
Few mails attached as proof.


Test Execution:

This year I worked on the following projects and always met the target date.
Core Components:
AU
MA with AU 7.0
Linux support for AU 7.0
License Reporting AU 7.0 SP1
Modules:
O release - WU as individual contributor and guiding OU module


Meeting Deadline:

Always met the timeline.
For AU7.0SP1 could finish the assigned tasks before the scheduled date and took some tasks from onsite QE team which was assigned to them initially.


Quality of Defects raised:

Raised defects with all the details. Zero complaints from offshore and onsite team.
I have filed 69 issues in this year. Attached is the excel sheet. Among these 2 are not a bug and hence actual count is 67.
Severity wise distribution is as follows.
Sev1 - 3
Sev2 - 24
Sev3 - 24
Sev4 - 16
QQ = 3x4+24x3+24x2+16x1=148
I have 2 bugs as invalid i.e 2/69=2.89% which is much below than the limit allowed


Verification of Defects:

Verified the pending_validation issues on time.
Verified and closed 44 issues in this year. Severity wise distribution is as follows. Attached is the excel sheet for details.
Sev1 - 3
Sev2 - 8
Sev3 - 17
Sev4 - 16


Test Plan and Test Case Development:

Regularly updating the Test cases in the Test director.
Adding test cases wherever gap is found.
Passing the relevant test cases after verifying the issue.
License Reporting, AU 7.0 - Created the test cases
For cross reference, Test Director can be checked.
Reviewed the Test Plan created by F and gave comments. (mail attached)
Reviewed the Test Plan created by other team members. (mail attached)
Reviewed the PRD and gave comments to PM. (Mail attached)
Written test cases covering the 100% requirements.
Test cases are detailed enough to be understood by a new person to the product.
No majore issues found in the created TestPlan and TestCases.
Always adhered to the date for submitting Test Plan and Test Cases for review.


Bonding with Team Members:

I have worked with the following people this year.
Zero complaints from team members working with me
Zero complaints from other team members in MA QE team
Zero complaints from Dev team
Zero complaints from Onsite QE and Dev team
[January To March] - [RR ] - [Krishna, P, A and K]
[April To May] - [MA],[Linux Support ]-[K,P,De,R]
[June]-[License Reporting Testing] - [Krishna and Dev by A]
[July To September] - [AU7.0SP1 and support of 6 modules]-[K,A,S]
[October To December]-[O Release]-[K,A,D,R]


Knowledge Sharing:

Imparted trainings to H(xplanner) and B(Test Director, team Track) by scheduled date
Gave inputs on AU Test cases to D and R who joined the team.
Shared environment set up with Dev team to help them to fix the issue. [Feedback from K can be taken]
Helped Doc team to set up the environment from the scratch for some reference. [Feedback from V can be taken]


Extra Achievement:

Received two times MVP [Most Valuable Player] Award in QE Team
1. Got appreciation from onsite QE manager J. [Mails can be produced as proof]
Comment:
 Krishna,
You and your team did a really good job on the MA7.0.1 release.  ..............
Regards,  J
"You are making great strides and I applauded your efforts and your results up to this point.  Keep up the good work.  " -J
2. Got good feedback from L for project report and planning
"Great report K!  " - L
3. Takes interview for QE position.
4. Got good feedback from Manager about understanding the requirement and answering after that. [Attached email]
"Thanks K. This is perfect. You understand requirements correctly and reply to the point. Please keep up this strength."
P

Sunday, October 7, 2012

Sample : Award Nomination

Sample : Award Nomination



K has done a great job in testing & managing the testing team. Not only she has tested this product but 
gained the knowledge which is required to improve the product’s quality in the long run. Because of the 
change in test strategy suggested by K and digging the information in Test Director the product AU is in 
a much better shape as compared to the previous version. Also K has taken care of her team well and 
always exceeded the productivity expectations.


P has done a great job in testing AUS module.  She has raised many issues and thus stabilizes this area as 
this area was never tested thoroughly before. She has always worked beyond expectation and takes 
complete ownership of the tasks. She has also contributed towards M release and delivered a quality 
product. She always comes out with her own strategy to execute the test cases faster and her productivity 
output is much higher. Also she contributed towards license testing which was completely new area to 
explore. 


A has done a great job in testing SI modules.  SI being a complex & high business volume module needed 
special attention and A has done the work beyond expectations. Because of the efforts and hard work put 
in by A, the product was delivered much ahead of schedule to the customer.  
(Appreciation email attached. Customer appreciation snippets can be mentioned here.)





Wednesday, October 3, 2012

1st day of Testing - Breadth vs Depth - Which is important?


1st day of Testing - Breadth vs Depth - Which is important?

Or

Smoke Testing vs Bug Finding - Which is important?



In this article I am trying to project how important it is to execute the Core functional test cases across the application under testing (Breadth testing) vs Finding more no of the defects in detail testing (Depth testing) on the first day of testing after receiving the build or in the beginning of test cycle.

Scenario 1:
---------------------

BACKGROUND:
---------------------------
You are part of testing team. You have completed Test Case writing and also prepared the Test Bed and eagerly waiting for the build from the Dev team. 

You were expecting the build on Monday morning. But build from the Dev team got delayed by 2 days ( as most of the times it happened! Especially happened when the Dev team takes it granted that the Testing Team will absorb the delay and final delivery date to the customer will be met or the Test Manager finds it easy to propagate the pressure to the test team instead of raising a red flag to the Project manager about the delay in build .)

[A case of Onsite and Offshore Model]Onsite team has passed the new release of application XYZ 3.0 to offshore and lot of pressure to the offshore team to prove themselves. Moreover Onsite team also has promised to pass further product lines to offshore for development and testing based on the performance of the team on delivery of XYZ 3.0. Everybody in the project team looking forward to see and feel about the new release of developed application and get a first hand feedback from the Testing team.

Test manager has motivated the team and in each team meeting cited an indication of how many bugs the team can find and also very enthusiastic about projecting all the charts and graphs on defect metrics. Hence he is waiting and hoping that testing team will find enough bugs to make his chart/graph very lucrative while he presents it to the higher management/project manager.

Sounds familiar scenario..

[Assumption:  you don't have automated set of Smoke Testing Cases in place. ]

On a fine Wednesday Morning finally you received the build. After receiving and downloading from the build location and transferring it to your testing machine and after overcoming the hiccup of installation of the software lunch time arrived..After having lunch you are going to start testing and you are left with 4 hours before you can give your feedback about the first hand feedback to your test manager who inturn will present it to higher management/ project manager.


ACTIONS:
--------------------
It is natural tendency of a tester to find out as many bug as possible after receiving the build. Though there in QC you have good number of test cases written by testing team members and also got reviewed by the team/prod manager etc. still how many of you can resist the urge of doing Adhoc testing as soon as you have access to the application instead following the test case execution as written in QC one by one? And while doing Adhoc testing it is very easy to carried away by exploring more and more into / dive deep into the application and see any nook and corner of the application and find a bug in any corner cases. Moreover as per as productivity concerns you feel like its more worth finding maximum number of bug in the team rather than telling x number of test cases passed for the day from your side.

[[[Note:

If you have the expertise of doing exploratory testing well and good..In that case you can do that as in the exploratory testing while you have an eye with as the definition goes while you ensure the core functional test cases and simultaneously you see the behavior of the application to know about the where a defect is lurking.
Exploratory testing : "a style of software testing that emphasizes the personal freedom and responsibility of the individual tester to continually optimize the quality of his/her work by treating test-related learning, test design, test execution, and test result interpretation as mutually supportive activities that run in parallel throughout the project."]]]


A very simple example to understand Ad-hoc testing:

Case1:

Open page 1
Click button1
Page 2 opens up
Do some functional testing and see it is working

Case2:

Open page 1
Click button 2
Page 3 opens up [You did not do activities in the page. You changed your mind and wanted to go to Page 2 and do some functional testing]So clicked the button to go to Page 1
Page 1 opens up
Click button 1
Page 2 opens up
Do some functional testing.
You observe the functionality is not working fine.

[Cause could be : your development friend has setup a boolean variable from true to false while you visited Page3 and because of that variable set in page 2 it is not working...]

but I can bet while Case 1 is part of your test cases Case2 will not be part of your test cases. 


So you can have utilized your 4 hours time of the first day of testing by executing the basic core functional test cases or doing exploratory testing & trying to isolate the bug & thus raising the number of raised bug count & spending time executing some uncommon scenario (which you think your brain has enough intelligence to come up with a particular scenario which might get a bug because you think the scenario must not have come to developer's brain and must missed to take care of coding keeping the scenario in mind) .

Or knowing the appraisal in corner, this urge of finding more bugs could be intensify. After all this is a very easy way how you can sell your capability of testing and you feel you can convince your test manager why you should get more hike ! or already   there is a objective of how many bugs have been raised by a test engineer and this objectives has been set up by your test manager during the goal setting and this particular objective is very active at this moment in your head and you feel this is good opportunity to uncover bugs on the first day of testing before it  is uncovered by your tester friend in your team.
You feel the developer has done some basic functionality testing and chances are less in getting a bug in core functional test cases. and bugs can be found only in exhaustive test cases and in some particular combination..

You stretched your working hours and everybody in the team is staying late to have a meeting end of the 1st day which was scheduled at  7:30 PM: (sounds familiar again !)

At 6:45 PM: Your test manager asks you how many test cases executed and how many Passed and how many Failed. [More interested to hear number of Failed Test cases and How many defects has been raised in Bug tracking system as he is going to give the first day report to the management where every one is eager to know the first hand feedback from the testing team. 

But you know you have not followed the test cases as per QA. You were busy finding the bug and raise your bug count...

So now what do you do : You ask for another 10 minutes to wrap up and give him your count and status report. Now at this point you do  reverse engineering and see how many test cases matched with what you tested. You find out that you went deep into a particular module to uncover more bugs rather paying concentration to core functionality across all the modules.  As a result say you have found 5 cosmetics bugs.

When analyzed the bugs it was found that all the 5 bugs are in a particular combination/scenario. So Developers think that there is no major gap.


Now here is a comparison case.
------------------------

Tester 1 - 
Testing approach:
Tested all the functionality and find 0 bug.

Tester 2 - 
Testing approach:
Raised 5 bugs but did not assure of the core functionality of the application. Dived deep into a particular module and carried out rarest combination/scenario.

Whom would you prefer in your team?

I will hire tester1 who is more reliable to give the correct picture. At least nothing major damage will happen in this case.

In case of Tester 2 , how will you sooth the customer,if he is going to find a major bug tomorrow. Will he be happy to see the uncovered 15 bugs? A big question to ponder over....

You are in safer side if the basic functionality works well but think about the consequences if a major bug is found in the main functionality later on.


Yes I admit as a tester we should uncover as many bug but first of all ensure that all happy paths works as expected. Your image will go in a toss if you somebody else (god forbid somebody else is customer !) find a core functional test case bug in your tested application.  Think about the consequences.

So should not we do more exploratory testing?
yes we should do to uncover more bugs and but concentrate on crucial functional test cases, once that is completed you have the liberty or you are free bird to explore and break the application now.



Tips of the day ----

So I think more emphasis should be put on Breadth testing and cover the entire application each feature and functionality.


Do the Smoke testing first...Even if you don't find any bug... that is far more important than raising your bug count... nobody can save if something is missed in the basic functionality of the application.

Example : You have A, B,C , D , E, F, G feature and each feature has 3- 4 sub features. So it is wise to touch all the feature and then dig in to the application like deep into sub features. 

I think it will give more assurance to know the health of the application from boarder perspective even if i don't have any bug to report rather 5 bugs in one module and rest of the feature untouched completely. 


Count of the bug is not always important. Certification is more important.

Testers are there not only to raise bugs but to certify that the application is working right which is equally important. 


[Note: In subsequent posts I will cover few more scenarios.]

Thursday, September 27, 2012

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.

Friday, September 21, 2012

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?