Home

Showing posts with label Management Stories. Show all posts
Showing posts with label Management Stories. Show all posts

Saturday, July 18, 2020

My Journey as a Test Lead: Navigating the Exciting World of Team Management

Hey there, fellow testers and aspiring leaders! πŸ‘‹ I'm excited to share my personal experience as a Test Lead, guiding teams of various sizes through the thrilling world of software testing. Let's dive into my journey, including the mistakes I've made and the lessons I've learned along the way.

When I first stepped into the role of a Test Lead, I was both excited and nervous. I knew that leading a team of testers meant more than just managing tasks and schedules. It was about fostering a collaborative environment, nurturing talent, and driving the team towards success. As I began my journey, I quickly realized that communication was the key to everything. However, I made a mistake by not being as communicative as I should have been. I learned that regular one-on-one meetings with each team member were crucial to understanding their strengths, weaknesses, and aspirations. This not only helped me assign tasks more effectively but also built trust and rapport within the team.

One of the most challenging aspects of being a Test Lead was balancing the needs of the team with the demands of the project. I made a mistake by being too bossy and not delegating tasks effectively. I learned to prioritize tasks and delegate responsibilities based on the team's skill sets and workload. This not only helped us meet our deadlines but also ensured that each team member felt valued and engaged.

Another lesson I learned was the importance of continuous learning. I encouraged my team to attend workshops, conferences, and training sessions to stay updated with the latest trends and technologies. However, I made a mistake by not recognizing their achievements enough. I learned to celebrate their accomplishments and provide them with opportunities to showcase their talents.

As a Test Lead, I also had to learn to be adaptable and flexible. I quickly realized that no two projects were the same, and I had to be prepared to adjust my leadership style accordingly. I made a mistake by not being open to feedback and not learning from my own failures. I learned to listen to my team's feedback and adapt my approach to better suit their needs.

One of the most rewarding aspects of being a Test Lead was witnessing the growth and success of my team members. I took pride in seeing them take on new challenges, develop new skills, and achieve their goals. I made a mistake by not recognizing their hard work and dedication enough. I learned to acknowledge their efforts and reward them with awards and recognition.

In conclusion, leading a team of testers has been an exciting and fulfilling journey. I've learned the importance of communication, prioritization, continuous learning, adaptability, and fostering a culture of growth and innovation. I've also learned that being a Test Lead is not just about managing tasks and schedules, but about nurturing talent, building trust, and driving the team towards success. I've made my fair share of mistakes, but I've learned from them and grown as a leader. I hope my personal experience as a Test Lead has provided you with some insights and inspiration. Remember, leading a team is a journey, and every step along the way is an opportunity to learn, grow, and make a difference. Happy testing, and keep striving for excellence!

🌟Best,
Your Test Lead Friend 😊

Pointers for Recognizing and Rewarding Team Achievements:

  • Celebrate milestones and achievements with the team.
  • Offer public recognition and praise for a job well done.
  • Provide bonuses, promotions, or other financial incentives for outstanding performance.
  • Offer additional training or development opportunities for team members who excel.
  • Encourage team members to nominate their peers for awards or recognition.

Recognizing and rewarding your team's achievements not only boosts morale but also encourages them to continue striving for excellence. πŸ†

Wednesday, March 7, 2012

A Simple Solution of A Common Problem


Problem:

A new aspiring tester in the team was given the test cases and asked him to execute the test cases. This new aspiring tester was just completed his degree in computer engineering. He was one of the brilliant students in his batch. Everybody including the management of the company was expecting him to do well in his job. So this new tester started executing the test cases for the first time and then for the next time and so on. All test cases were passed and no bug was logged.  

After a month the tester was terminated from the project.  As per management the new aspiring tester couldn't become a tester because he didn't have the flame that a tester must have. The Tester was expelled from the team. Now he was sitting on the bench and thinking what went wrong.

How many of you have seen this problem? Actually I have seen a few and I had been also thinking what went wrong in this case.

Understanding the Problem:

Recently I was reading a clinical tale by Oliver Sacks. The tale was about a patient who was congenitally blind with cerebral palsy. The conditions are more pathetic than we can think of – she was suffering of spasticity and athetosis, i.e., involuntary movements of both hands, which was added due to failure of the eyes.

After initial tests and checkup it was found that there was no sensory ‘deficit’. Her hands would seem to have the potential of being perfectly good hands—and yet they were not. They were functionless—’useless’—because she had never used them. Had being protected and looked after since birth prevented her from the normal exploratory use of the hands which all infants learn in the first months of life.

Can you correlate the problem with the case mentioned above?

The real problem is that new aspiring tester was being pampered by the management itself. Instead of really doing the testing he was asked to follow the test cases which are most probably written by someone else. Initially, following the test cases made his task easy. He used to execute the test cases and finishes the task early. He couldn’t learn how to test from this exercise and we all know the result. The tester was put on bench (Literally killed the aspiring tester)

Solution:

A new aspiring tester in the team was given the application and asked him to test it for all the functional and usability issues. This new aspiring tester was just completed his degree in computer engineering. He was one of the brilliant students in his batch. Everybody including the management of the company was expecting he would do great in his profession. So this new tester who was hesitant initially started with exploring the application. Think about the infant who reaches for the breast when feeling hungry. Similarly the new aspiring tester took some time but he did some testing and logged few good issues.

Benefits from this Solution:
  • Confident and satisfied tester
  • Better Testing
  • More No. of bugs
  • A lively job
  • Better Self Education
  • Happy Management
What do you think? Does it seem a right solution to you?

Reference: "The Man Who Mistook His Wife For A Hat" by Oliver Sacks

Tuesday, May 4, 2010

Face/Off - A different solution

Few Words:
After reading my previous posts I received mail/comments on two major issues:
1.Few of them suggested me to change my style of writing
- Actually I always loved reading the stories so it has also put impact on my style of writing but I am trying to change it. This post should publish long time back but I couldn’t publish it for few reasons so you will find same old style in this post.
2. Few of the readers complained that I always write hatred things about the management
- This is not true at all but still I tried to change the things here. I hope you like it.


The Story begins Here....
“The situation is out of control now. They fight like cats and dogs.”

“It is common in IT world. The developers and testers always argue over the issues in the project. Don't Panic.”

“No, we need to think about that. Both are good, infect they are very good in their job but their rivalry can cause damage to project.
Yesterday, they were yelling on each other. Dorian was saying that it is easy to find the errors in other's work. You testers don't do anything productive in the project, if you have guts then develop a piece of code.
Trevor was also not behind. He replied that if you hurt then why you not do the things rights. You proud on your cheesy code; even a student can write better code than yours.”

“So, what is your suggestion on the matter?”

“I don't know. I just want to end the grudge developing between the both.”

“Ok, I’ll do something.”

After TL has gone, The Project Manager started to think on the matter and has come with a plan.

Next day, he called Dorian and Trevor in his office.

“I have a small project for both of you. I need it well developed and well tested. All the norms and conventions should be followed during development and testing of the project.”

“Will only we be in project?”

“Yes, this is a sample project for the client. Once the sample is approved, we will get the main project. So, for such a small project I just need two people from the team. Your TL has forwarded your name as Best developer and Best Tester. So I want both of you in my project.”

“Ok Sir. We will do it. How many days we have?”

“Good but there is a twist. Dorian, you have to work as tester in the project and Trevor, you will develop this sample project. In short, you will interchange your role for this project.

What? But why sir? We can't do that. I don't know how to test? I don’t know any testing technique and I am sure Trevor also can't write a single line of code. How can we do that?”

“Trevor stares to Dorian but remains quite. Actually he also has the same thought in mind.”

“Great questions. I already knew that you will have these queries. Actually client wanted to know the capabilities of our team so I promised him that for the sample project our tester will develop the project and developer will test the project. It’s a bet and I don't like defeat. So, just do it.”

“But Sir?”

“You can go now. You have time of Six days. Work together, help each other, all problems will be resolved. And remember don't try to cheat. You can help each other but you can't work for each other.”
While returning from the Manager’s cabin, both are thinking the same.

“Hell!!!! How will I do that?”

Day 1
Both are sitting on their desk and thinking how to start? Trevor knew that if he wouldn’t build the application, he would be blamed for not completing the task and then Dorian may have narrow escape in that case.
But Dorian was also not relaxed. As Trevor is not regular coder, there would be many issues in his build. What if he couldn’t find all issues in the build? He would be blamed for issues in the sample project.

They decided to use the Google to learn the things. Whole day passed but they are not sure how will they do the task.

Day 2
Trevor started with requirements. He gone through the requirements thrice and then started to create HLDs. He was not sure he had designed them correctly.

On the other hand Dorian was still googling. He was not sure yet from where he should start. Things are not going right way. He had to do something.

At the end of the days while Dorian was thinking what to do, Trevor came to him and proposed help to Dorian. In return, he wants the same. First time, Dorian was happy to hear Trevor. They shook their hands and deal was locked.

Day 3
Dorian checked all the HLDs and LLDs and made the appropriate correction. He suggested Trevor to write the use cases.

Trevor suggested Dorian to go through the Requirements and list the questions and query from the specification. He told him to apply few Heuristics during testing such as 'Mary had a little lamb’; to solve a big problem let it divide into small ones, Rumble Strip etc. Once the list of question is prepared, Trevor told him to go to manager to get the answers of those questions.

When Dorian returned from Manager, Trevor was doing his lunch. He offered his 'Aloo Parantha' to Dorian. Although Dorian don't want to eat anything but he couldn't deny to Trevor. The moment they shared the bite, every hot feeling between them was evaporated.

After Lunch, Dorian informed the Trevor about the changes in requirements after discussion with Manager. Trevor updated his design documents accordingly.

After finishing the changes, they have a peer meeting to set the environment of development and testing. Dorian described him how to set the development environment and Trevor shared how to set the testing environments.

At the end of day, both have set the environment for Development and Testing.

Day 4
Trevor was busy in the development. Sometimes he struck with the uses of syntax and specific commands where Dorian helped him. It was a simple application, but Trevor didn't think so. According to him, it was one of the toughest tasks. He realized that it is never easy to develop the things and maintaining the quality with development is most challenging.

On the other hand, Dorian was writing the test cases and metrices. He never knew that testers have such a challenging job. On wearing the Hat of a tester he realized the responsibility attached with the profession. He was feeling ashamed on the perception he had for the testers.

In the evening they sat together for the peer meeting and discussed the challenges they faced. Each of them helped each other to overcome from the challenges.

Day 5
Trevor has assigned the application to Dorian for testing. Dorian was executing the test cases but unable to find the issues. He was not sure that Dorian didn't leave any issue in the application.

Again they had the peer meeting. Dorian told Trevor that he is unable to find the issues. According to him all the requirement is completed. Trevor suggested him to use the Exploratory approach to find the issues. He made him understand the exploratory approach of testing. He also shared Test Heuristics Cheat Sheet with Dorian.

Dorian again started his work and within two hours he found many issues in the application. He assigned the issues to Trevor. Trevor worked on the issues and resolved them.

Day 6
Most of the work has been completed. Dorian has retested the issues followed by regression test. In between Trevor made the changes in the code suggested by Dorian. The task is completed and it looks really well.

In the evening they went to the nearby bar to celebrate the completion of their challenge within the allotted time. Next Day, they have meeting with the Manager.

One-on-One with PM
Next Day both Trevor and Dorian were called by PM. He wanted to know the status of progress. After getting the project status, he sent back Dorian so that he could do one-on-one with Trevor.

PM: Trevor, you have done a great job? I would like to know how your experience was.
Trevor: Sir, It was not my first time when I developed a product. In my college days I developed few apps but at that time we never bothered about testing or quality.
When I chosen software testing as my career, I have mindset that most of the developers don’t try to develop a quality product but guess, I was wrong. In last few days I learned that developer always tries to give his best, its just human nature that he can’t see the issues in his own developed product as Mothers can never see the faults of her own children

PM: Great Thought!!! So, would you like to go in development?
Trevor: Developing a product is a great feeling but I am more passionate for testing. I would like to remain as a tester always.

PM: Great. That’s all I want to know. Thanks for your time. Can u send Dorian inside?
Trevor: Thanks Sir for great opportunity and teaching a valuable lesson to us.

Trevor leaves the room and sent to Dorian inside.

PM: So Dorian how was your experience as a tester?
Dorian: It was great Sir. Earlier, I always thought that testers do nothing valuable with the project. They just find the errors in the project and report them. I mean we can also do the same if we have sufficient time.
On wearing a tester’s hat I came to know how wrong I was. A developer can just build a product; it is a tester who really makes a quality product. Testing is not an easy task. The testers are brave and have guts to say the truth, no matter who is standing before them.

PM: Good to see your thinking has been changed. So, would like to wear a tester’s hat in forthcoming project.
Dorian: I would love to but I don’t think I can do the justice with the job of a tester. We need skilled testers in the projects. I have learned - A skilled tester can give you a quality product but at the same time a bad tester can horribly ruined a product. I think Trevor is the right person who can test.

PM: I am happy that you understood the value of a tester. This is going to help you in future.
Dorian: Yes Sir.

PM calls on intercom and call Trevor inside.

PM: If you have any issue with each other, you can say it now?
Dorian: No Sir
Trevor: I have one issue, He promised to get me a beer three days ago but still he didn’t get me a beer.
PM: :) Come over to my home in the evening. We will have a drink together.

Disclaimer:
The story written above is purely a work of fiction and imagination. It doesn't belong to anybody living or dead.

Wednesday, March 31, 2010

What is your sentence?

Scene -1

Sir, there is an issue here.

What issue?

We are populating the date and time by default; but the date and time is already scheduled for another appointment. What’s the use of populating the data if user needs to change the data?

So what do you want? We are displaying the current date and time here. Client has gone through the module and he didn’t complaint about it, then what’s the problem?

Earlier we don’t have the functionality to display the next available schedule. Now when we have the function, we can implement the function here. It will increase the usability.

Hmmm…. Ok, we will see later.

Scene -2

Hey Jags, There is an issue?

What issue?

Look at this buddy. In the month view of the appointment scheduler, you are displaying the appointments for each day. User is able to create the appointment by clicking on a day. But when user clicks on the days of next month in the current month view, the appointment form doesn’t open although you are displaying the appointments for that day.

It’s not possible. To create the appointment for next month you have to go to the next month view.

But if you are displaying the appointments of next month here then user wishes to create the appointment from here too.

It’s not possible.

But the same functionality is already implemented in Google calendar then why it’s not possible.

Client didn’t complaint about this issue. We will do it when client will ask.

If it is not possible then how will you do it then?

Everything is possible what client wants. We have other tasks too so we can’t do it just for your satisfaction.

You are not developing the things to satisfy me. We all here are working for client satisfaction.

Tester went to his Project Manager. He detailed the issue to PM.

Hmmm…. Ok, we will see later.

Scene -3

Sir, the module is still under test. There are few issues which need to be fixed before uploading the client site.

Is there any show stopper?

No Show stopper is there but there are many minor issues which can not be ignored.

Hmmm…. Ok, Let us upload the module today as we promised him. You carry on your test, find the bugs and assign them. After bug fixing we will upload the changes.

Next day, Client logged the issues.

Scene -4

Why did you disclose the issues to client when he was unaware?

He wants to know the issues in the module.

He was not aware of those issues. You could hide them easily. We could fix them afterwards.

Later if he finds the issues, he can conclude that I am not a good tester for his project.

We would handle the situation in that case. Now he is demanding for the major changes in the module which can cause late delivery and hence deduction in billing. You are on responsible designation. I was not expecting this from you. Well, never repeat the same.

Scene -5

Hey Jags, This is not right. Client wants to do the things in this fashion. What you are doing is incorrect. Do it in this way

Hey man, we are the developers, not God. Why you don't accept the simple things.

It is not simple. It is buggy. Client is asking for a dinner chair and you are giving him Potty Chair. Do as I said, it is the right approach.

Hmmmm....

After three days:

Congrats Jags, Client has really liked the module. Well Done boy. I was not sure that he would like the module. Good Job.

What does your Manager say:

On Scene -1

I am agree that it increase the usability but as I said Client didn't ask for implement the changes here. There is lot of work in the project, we can't spend time for the things for which client doesn't care. So I put the things on hold.

On Scene -2

This is a valid issue but if client didn't make a complaint it means he is satisfied with the current feature. In the limited time line we can't provide everything to client. We have put the issue in our To-Do list and if we can get enough time, we will surely fix the issue.

On Scene -3

Bad things are better than nothing. I have promised to client that I would deliver the module on particular date. Postponing the delivery can cause the bad credibility. So I decided to upload the module.

On Scene -4

Due to your stupidity, Client has known the issue which we could deal later. He gives us a long list of changes which has put us back from the schedule. The client will deduct the payment if project is not delivered on scheduled date and you'll be the only one responsible for the situation.

On Scene -5


I never knew that you also contributed so much in the module. I thought it was Jags who developed the module alone. I really appreciate your efforts but you must also agree that Developers are the real contributor in a project; if they are not there no project could take a shape. Your work depends only on their work.

What is your sentence?

Now as a tester what is your response? Are you agree with the Project Manager or you have different sentence. Share your point of view as Comments.

Saturday, March 20, 2010

I know I was right.....

2 days ago:
The phone was ringing continuously. Nobody was ready to pick up the phone. Everybody was enjoying the party thrown on the occasion of successful delivery of the product. It had been more than one week since the product was delivered. We were just waiting for the client's confirmation about the product, yesterday he gave the confirmation that he was satisfied with the product. After confirmation the management thought to celebrate the success and thrown a party on the workplace. The beer is flowing like water in the river. Everybody was dancing on remix version of song being played on one of the system:
I am a champion, a blue ribbon, gold medal kid.
I am a champion, a blue ribbon, gold medal kid.
I am a champion, I know in my heart.
I am a champion, I've known it from the start.
You are a champion, a blue ribbon, gold medal kid.
You are a champion, a blue ribbon, gold medal kid.
You are a champion, you know in your heart.
You are a champion, you've known it from the start.
We are all champions, we're a blue ribbon, gold medal team.
We are all champions, we're a blue ribbon, gold medal team.
We are all champions, we know in our hearts.
We are all champions, we've known it from the start.
Champion, champion.... I'm a champion.
Champion, champion.... you're a champion.
Champion, champion.... we're all champions!!

In such a toxic ambiance nobody bothered to pickup the phone. When the ringing was not stopped,The ProjectManager picked up the phone. During conversation, his colors of face has started to change. Something was very serious.

437 days ago:
Today I had interview with "XYZSquare Solutions Pvt. Ltd." for the position of Test Engineer. It was a great opportunity for me as I was looking for a change since last 3 months and this company also has big name than previous one. Anyway, the interview was great and they offered me 70% hike from my current package. I immediately accepted the offer.

385 days ago:
Today a new project was assigned to me. There were 15 members in the team - 1 Project Manager, 1 Delivery Manager, 1 Technical Consultant, 1 Team Leader, 10 Developers and 1 Tester (i.e. me). This was one of the critical product with very tight scheduling. The work has started with pace and lot of enthusiasm. Everybody was trying to put all his efforts.

129 days ago:
I was sitting in the cabin of Project Manager watching the kites in the sky outside from the window. My Manager was busy in reading the report submitted by me. After going through the report he asked me the motive of coming ( Indirectly, he was asking about the urgency for which I had awaken him from his nap). I described him the situation, 312 issues were already open and I was still counting but nobody was bothered to fix them as everybody was busy with some development activity. There were some critical issues. He assured me that once the development is completed, all the issues would be fixed. I was not able to understand his strategy because bug fixing at later stage would definitely cost more but I needed to agree with him.

20 days ago:
The delivery manager called me and asked about the status. Just 10 days were remaining in the delivery and it was first time when Delivery Manager asked about the product. I was wondering "Had he been sleeping for one year?". Anyway, i told him that there were few issues which must be fixed before delivery.

10 days ago:
The delivery manager came to me and asked about the status. He was looking worried. I told him that still 2 high severity bugs were there and must be fixed before delivering the product. He gazed at me for few moments and asked me about the issues. I gave him a brief summary and told him the impact of those two bugs. After lot of consideration and calculation (?) he declared that these issues could be deal in next release as the scenario was very rare in real world and the probability of client meeting with this issue was 1/10000.

According to him the product was ready to deliver. He also deleted the bugs from the "Known Issues" list to show the delivery of bug free product.

9 days ago:
Today the team were very happy. Its a big day after all. All their efforts which they put in the product were going to live today. Everybody was planning about their holidays. Everybody was expecting some reward from the management. I was also happy but a doubt was there in my mind - What if the client finds the issue in 1st attempt instead of 10000th attempt? At 9 P.M. all the files has been uploaded on the client site. It has taken complete 3 hours to upload.

Now the ball was in the client court. The delivery manager told us that for a week the client is going to perform acceptance testing on the product and then if he gives us clean chit then there would be a party from the management.

Yesterday:
I was sitting in front of COO of the company. The delivery manager and my project manager were also there. The COO was angry with us (specially me) because the client has called him in the midnight and shouted on him madly. The client was really angry because one of his client has refused to accept the product due to some error and client has declared not to pay the remaining balance. It was one of the issues which I want to be fixed before delivering the product.

The COO wanted to know why the issue was not found during the testing. I tried to tell him that Issue was found and I also put the issue in front of delivery manager but he allowed the delivery of the product without fixing of the issue.

He asked me if issue was found then why it was not there in the list of 'known issues'. I told him the truth again. But, according to him it was a lame excuse. If the issue was very serious then I should make it fixed before delivery, as it was totally my responsibility. I opposed him as the quality is the responsibility of everybody in the project. He was blaming me for the mistake made by the delivery manager. It was he who deferred the bug. While having these words with COO, my Project Manager was signaling me to shut my mouth but I was on high drive. Perhaps the effect of beer was still there or it was the pride of a tester, whatever, hearing this the COO was pissed of me. He found me very arrogant and decided that no reward bonus or salary hike will be granted to me.

Today:
I have resigned from the company today and now I am jobless. There is no repentance on the decision which I have made because I know I was right.

Epilogue

After 3 years:
Now a days I am working as Testing Consultant and testing a project for the "XYZSquare Solutions Pvt. Ltd." and charging them double the amount of what I charge from others :)

***************************
Credentials:
The Song "Champions" is written by Debbie Clement. Debbie Clement is an Arts Enrichment Specialist serving young children and their families, often children with special needs. Her twenty years of experience demonstrate her passion for teaching and her love of children. An educator as well as a singer-songwriter, in 1998 Debbie was awarded the Ella Lyman Cabot Trust award for preschool music serving children with special needs.
Sources:
http://www.songsforteaching.com/debbieclement/champions.htm
http://www.songsforteaching.com/store/debbie-clement-c-631.html
***************************
Disclaimer:
The story written above is purely a work of fiction and imagination. It doesn't belong to anybody living or dead.

Saturday, July 11, 2009

Be honest with your job

Today I have a story to share. The source of story is not important so I am not discussing about it, what really matters is the moral of the story and that’s the only reason I am sharing it with you.

There was an aspiring IT company in India with good Development team, Media team, Marketing team, Managers and Testing Team. Sorry I said Testing team but actually there were only two testers in the team :)

So there was a product on which a fully development team of 6 developers, one team leader and a tester was working. The product was running from last 10 years and has gone through many stages and changes. During the last 10 years the team has been changed many times but the product was still there. The product was under development as well as maintenance stage. So sometimes there was new development otherwise most of the time it was under maintenance.

Once there was request for an enhancement in Search module of the product from Client. There were two different search screens for two different entities. Now Client wanted to combine both the search screens i.e. when a user made a search for a keyword, the result should appear in single search for both entities in two different tabs.

The task was assigned to development time. The development team has started their job on the new task. But they took more time in completing the task than the allotted time. In fact there was no time for testing and debugging.

In this situation team leader decided to upload the task on client site without testing and debugging. He uploaded the task on client site and then assigned the task for testing. The tester completed his job and reported the bugs to development team. The development team started to fix the bugs. They have fixed all the bugs and the task is reassigned to tester. All the issues had been closed except one. He again reported the same issue. Development team worked on it but unable to fix it. Every time development team fixed the issue, the tester reassigned the issue back to them. The development team was really in trouble. They told team leader about the problem.

In between Client reported issues in new enhancement. The Client reported all issues except the one which was reopened many times. The issue was regarding search time taken by application in searching the records. According to tester the application is taking too much time in giving result.

After discussing with development team, team leader called the tester for discussion on issue. According to team leader there was not any issue. They had already applied all their tactics to make the search fast and there was no way to make it faster. According to team leader there was hundred thousands number of records so application was taking time in searching.

The tester was not agree with his team leader. According to tester the search was slow and it would really irritate the user in future. He told to team leader that if number of records was reason of slow search result, in that case Google should take hours to display the result and they had long debate on issue.

At last, team leader asked tester to close the issue as the issue was not reported by Client and he decided to upload the remaining changes on client site. The tester refused to close the issue. He didn’t want to dishonest with his job to please his team leader. The team leader felt it as his insult.

After discussion the team leader uploaded the changes on the client site and reported to Manager that the tester was not good team player, irresponsible about his job, never listen his senior and always does useless debate. The result was tester had been put on bench for indefinite time.

More than 5 days have been passed; there was not any complaint from Client. He had used the new feature many times and he seemed happy with new feature. The development team was happy with their job but the tester also was not upset with his decision. He always knew he was right.

After 13 days, a mail was received from Client regarding same issue and he was really unhappy. According to him the search was taking too much time to produce the result. After this mail, manager called the team leader in his room for meeting. What they discussed behind the doors was always a secret but after the meeting the tester was back in team. He was working on the same product and development team including team leader started to take him seriously.

Moral of the Story

For Aspiring Testers:
(i) Be honest with your job as Honesty is the best policy.
(ii) Don’t change your views, ideas, ethics or heuristics to please anyone.
(iii) Never take back steps from an argument if you are right. Doesn’t matter who is in front of you. Just believe in yourself.

For Management of Companies:
(i) Testers are assets to the company. Let them do their work with honesty.
(ii) Testers view the things with Clients perspective. Believe in them.
(iii) Never release a product with issues to client. Little delay is much better than a buggy product.