In one my previous organizations’, I worked for 2 different teams during my ~3 years tenure. Let’s call them Team A and Team B. Team A was a vibrant team with highly energetic and motivated people with diversified experience and skill-sets. The team members included fresh college grads, people with couple of years of experience and a handful with good knowledge of customers’ usage of the product we tested.
Team A was led by a manager we’ll call Larry. What struck most about Larry was that he had faith in his team members (note that I don’t use the word ‘team’ here). He would talk to every team member at a regular basis about each one’s work, if there were any obstacles, if there was anything he could help with and so on. He organized team lunches/picnics/movies once in 2 months. He did all this while we worked a 70 hr work week. He came up with ideas to work differently to test the product better, but did not mandate to use his ideas alone. He was fine with people coming up with their own ideas as well. He encouraged people to have Disposable Time during office hours. He led by example.
Good Things don’t last forever. Isn’t it? I was moved to Team B for which I was originally hired. Team B was opposite of Team A. Team B consisted of testers who had been with the organization for 4+ years. People kept to themselves, some of them were short tempered and inaccessible. Some would even yell in public if you went with a question which they found to be silly. Some would never answer though they knew how to deal with it, but always pointed to a person who hardly knew anything about it.
Team B was headed by a manager named Rob who always carried a fake smile. I often wondered if his jaws didn’t hurt at all. I had a tough time getting information about the product in this team. Other than my reporting team lead, no one was willing to help. About 90% of the team members were unhappy with their raises just 1 month before I joined. They were obviously unhappy. What a bad timing it was for me?
To add to these woes, Rob walked around people’s cubicles without saying a ‘Hi’. His eyes were always on peoples’ monitors. Who is browsing what, who is not at their desk, how much time do they take during the allotted 1 hr lunch break, do they answer calls at their desk phone by their colleagues or not and many more.
It was appraisal time again. Cafetaria and the Table Tennis area are the best places to hangout post the performance evaluation phase. One gets to hear so many important things about the organization and its processes. I overheard an employee grumbling ‘My manager says on 11th Jan 2005, he came to my desk three times between 2pm and 3pm, but he didn’t find me at desk. He also says that I have been going for long lunches beyond the stipulated 30 minutes (btw lunch time lasts 1 hour in the employee handbook). He concluded that I am not being productive enough’.
The other employee replied reassuringly, ‘You know what? Your manager is still better. My manager says ‘I called you 21 times between 11am and 11.30am to your desk phone and you did not pick up the phone. Where on earth were you? He has my mobile number. I am surprised why he didn’t call to find out? I was at the hospital tending to my wife who suffered a miscarriage that day’. This is just 2 of the many conversations I have overheard or heard directly from the employees. 1 year later, the rate at which people joined team B was way too less compared to the rate at which people quit that team(and the organization) thanks to Rob.
If you are a team member, which team would you love to be in? A or B? If you are a manager, how do you manage your team? As Larry or as Rob?
Happy Working,
Parimala Shankaraiah
23 January, 2010
13 January, 2010
Book Review: Lessons Learned in Software Testing
About 5 years ago, I bought William Perry’s ‘Effective Methods for Software Testing’ book. I struggled for 2 months to get myself to read that book as it appeared to be too much of theory for me at the time (my first testing book). At the end of 2 months, I gave up. I gave up reading not just this book, but my reading habit itself.
In July 2009, I came across The Secrets of a Buccaneer Scholar by James Bach. I had just started blogging a few months before that and was following James’ blog for a while. There was a free offer to read his book within a timeline which I did. In five days, I had finished reading the book. I enjoyed reading very much after a long time. It was fun. I realized what I had lost in last 5 years.
Lessons Learned in Software Testing is a book that every tester should read to get their basics right. A couple of my friends suggested that this is a book mostly for freshers and not targeted towards experienced testers. I digressed and read the book. I was right. This is a great book meant for every tester.
This book depicts finer nuances of many testing challenges we face on a daily basis. Another good part of this book is that every chapter addresses a topic independent of other chapters. So you could choose to read few chapters earlier than others. If you are a tester, you must read this book.
I bought this book 2 months ago and often stared at it (placed on the dining table) cribbing that I did not have enough time to read it. Around the same time, I came across Anuj Magazine’s post about Reading Skills. I started reading for 30 minutes everyday and it has worked. Who knows, it may work for you too. All you need is to TRY.
Happy Reading,
Parimala Shankaraiah
In July 2009, I came across The Secrets of a Buccaneer Scholar by James Bach. I had just started blogging a few months before that and was following James’ blog for a while. There was a free offer to read his book within a timeline which I did. In five days, I had finished reading the book. I enjoyed reading very much after a long time. It was fun. I realized what I had lost in last 5 years.
Lessons Learned in Software Testing is a book that every tester should read to get their basics right. A couple of my friends suggested that this is a book mostly for freshers and not targeted towards experienced testers. I digressed and read the book. I was right. This is a great book meant for every tester.
This book depicts finer nuances of many testing challenges we face on a daily basis. Another good part of this book is that every chapter addresses a topic independent of other chapters. So you could choose to read few chapters earlier than others. If you are a tester, you must read this book.
I bought this book 2 months ago and often stared at it (placed on the dining table) cribbing that I did not have enough time to read it. Around the same time, I came across Anuj Magazine’s post about Reading Skills. I started reading for 30 minutes everyday and it has worked. Who knows, it may work for you too. All you need is to TRY.
Happy Reading,
Parimala Shankaraiah
08 January, 2010
WOW Moment!
Curious Tester gets published on print for the first time! I was interviewed by the Software Test and Performance Collaborative magazine recently. The January Issue of the magazine is a special edition featuring many women testers across the world whom Karen Johnson calls as ‘Women of Influence’ in her editorial. Fiona Charles asks why there are so few women writers in her guest editorial 'And Now, The Women'.
It's a great honour for me to be featured alongside Fiona Charles, Karen Johnson, Elizabeth Hendrickson, Lisa Crispin, Janet Gregory, Catherine Powell, Sharon Robson, Lanette Creamer, Nancy Kelln, Rosie Sherry, Renu Rajani, Isabel Evans, Mieke Gevers, Dorothy Graham, Dawn Haynes including Andrew Muns, Chris McMahon and Matt Heusser.
Wanna Read?
You have to register (FREE) at the website to read/download the January issue.
1. My Interview
2. Women of Influence
3. Fiona's Guest Editorial
Dedication
Pradeep Soundararajan is a great support in my writing efforts all along and still is. He never gets tired of guiding me through my daily struggles in writing. Fiona Charles was very kind enough to review my work a couple of times before it went public. Karen Johnson, Amy Lipton, Andrew Muns and Teresa Cantwell were helpful in getting my work published. I am indebted to each one of them.
Happy Reading,
Parimala Shankaraiah
It's a great honour for me to be featured alongside Fiona Charles, Karen Johnson, Elizabeth Hendrickson, Lisa Crispin, Janet Gregory, Catherine Powell, Sharon Robson, Lanette Creamer, Nancy Kelln, Rosie Sherry, Renu Rajani, Isabel Evans, Mieke Gevers, Dorothy Graham, Dawn Haynes including Andrew Muns, Chris McMahon and Matt Heusser.
Wanna Read?
You have to register (FREE) at the website to read/download the January issue.
1. My Interview
2. Women of Influence
3. Fiona's Guest Editorial
Dedication
Pradeep Soundararajan is a great support in my writing efforts all along and still is. He never gets tired of guiding me through my daily struggles in writing. Fiona Charles was very kind enough to review my work a couple of times before it went public. Karen Johnson, Amy Lipton, Andrew Muns and Teresa Cantwell were helpful in getting my work published. I am indebted to each one of them.
Happy Reading,
Parimala Shankaraiah
30 December, 2009
Is Questioning in your DNA?
I took part in James Bach's Testing Challenge at Weekend Testing recently. Pradeep Soundararajan reviewed my report and spoke about the gaps in my testing effort as well as the report. As always, I revisited my report to figure out areas that need improvement(read dismal performance report). One of the key problems with my report was that - I did not question the mission that was given to me. I did skype James before the testing session with a few questions that were either too broad or too open ended. James did help me by rephrasing a few questions. However, I did not use this opportunity to its fullest potential.
A little while later, Jonathan Bach & James Bach tweeted on Traps in testing
JBTestPilot: The #1 trap that testers fall into when I ask them to test something: They start testing'.
CuriousTester: I am trapped! din't see testing without questioning as a trap! Traps work that way. This is more often than I would wish to get trapped!
JBTestPilot: No worries... there are many ways out of traps. The trick is, knowing you're IN one.
JamesMarcusBach: Good testing is a questioning process. All tests are questions. But some things are better asked of humans.
Here I am inflicted with lack of good questioning skills. I did not worry much about it until it started affecting my ability to test better. Now you ask ‘Do you mean you never questioned till date?’. Of course, I did. They did not seem to add value to what I already do. They did not appear to bring in new ideas. In short, I am not skilled at questioning yet.
[ Tester ] - [ Questioning Skills ] = [ Unskilled Testing ]
I am wondering why questioning is not in my DNA. Is it really in my DNA and I am unaware? I grew up as an obedient child. I don’t remember saying ‘No’ to my parents, no matter what I was told to do - a very big claim indeed (grins). When I say as a child, I mean the period from which I remember the events of my life to a considerable extent. Being obedient, not breaking the rules, not being demanding and many more blocked my ability to question since childhood.
In general, questions are not encouraged in India (I think so). They are seen as a symbol of revolt. Questions from elders are reprimanded and questions from children are snubbed. Children are taught to be obedient without questioning. If they break the rules, they will be punished. Yes, child beating is quite normal and not violent. Actually, its not even violent as it sounds to you as you read this. A 911 type helpline may flop here. Growing amidst a culture where questioning is a taboo could be one reason why I am not good at it.
Every question adds a new dimension to better understanding through answers. Yet, we don’t question. The sad part is most of us don’t question because we don’t know that we can question. We have the liberty to question, but we don’t.
Question what? Question your product, question your testing mission, question your test strategies question your deliverables. Question anything that you think will make a difference to what you do. Some people are good at questioning and a few others are not so good. The good news is that this skill can be inculcated with constant practice by one and all. It can be honed over a period of time.
Practice questioning skills with your programmers/team members. Play games that help improve your questioning skills. Play Twenty questions game. Playing Dumb Charades might be of great help too. Ask the right questions. To ask the right questions, you will need to ask many wrong questions and learn from them. Open ended questions may be too broad. Close ended questions may be too vague. Probing questions focus on specific areas (can be open or close ended) and are very useful. A good mix of above three types of questions will improve questioning skills. Note taking if coupled with Questioning is a powerful tool for testing.
Wishing You a Prosperous & Happy New Year 2010!
Addendum on 30th April 2010
One way to practice questioning skills is using Q-Patterns by Vipul Kocher.
P.S: The title of this post is inspired by Rahul Mirakhur who made a mention of 'Questioning in your DNA' during one of our informal talks.
Happy Questioning,
Parimala Shankaraiah
A little while later, Jonathan Bach & James Bach tweeted on Traps in testing
JBTestPilot: The #1 trap that testers fall into when I ask them to test something: They start testing'.
CuriousTester: I am trapped! din't see testing without questioning as a trap! Traps work that way. This is more often than I would wish to get trapped!
JBTestPilot: No worries... there are many ways out of traps. The trick is, knowing you're IN one.
JamesMarcusBach: Good testing is a questioning process. All tests are questions. But some things are better asked of humans.
Here I am inflicted with lack of good questioning skills. I did not worry much about it until it started affecting my ability to test better. Now you ask ‘Do you mean you never questioned till date?’. Of course, I did. They did not seem to add value to what I already do. They did not appear to bring in new ideas. In short, I am not skilled at questioning yet.
[ Tester ] - [ Questioning Skills ] = [ Unskilled Testing ]
I am wondering why questioning is not in my DNA. Is it really in my DNA and I am unaware? I grew up as an obedient child. I don’t remember saying ‘No’ to my parents, no matter what I was told to do - a very big claim indeed (grins). When I say as a child, I mean the period from which I remember the events of my life to a considerable extent. Being obedient, not breaking the rules, not being demanding and many more blocked my ability to question since childhood.
In general, questions are not encouraged in India (I think so). They are seen as a symbol of revolt. Questions from elders are reprimanded and questions from children are snubbed. Children are taught to be obedient without questioning. If they break the rules, they will be punished. Yes, child beating is quite normal and not violent. Actually, its not even violent as it sounds to you as you read this. A 911 type helpline may flop here. Growing amidst a culture where questioning is a taboo could be one reason why I am not good at it.
Every question adds a new dimension to better understanding through answers. Yet, we don’t question. The sad part is most of us don’t question because we don’t know that we can question. We have the liberty to question, but we don’t.
Question what? Question your product, question your testing mission, question your test strategies question your deliverables. Question anything that you think will make a difference to what you do. Some people are good at questioning and a few others are not so good. The good news is that this skill can be inculcated with constant practice by one and all. It can be honed over a period of time.
Practice questioning skills with your programmers/team members. Play games that help improve your questioning skills. Play Twenty questions game. Playing Dumb Charades might be of great help too. Ask the right questions. To ask the right questions, you will need to ask many wrong questions and learn from them. Open ended questions may be too broad. Close ended questions may be too vague. Probing questions focus on specific areas (can be open or close ended) and are very useful. A good mix of above three types of questions will improve questioning skills. Note taking if coupled with Questioning is a powerful tool for testing.
Wishing You a Prosperous & Happy New Year 2010!
Addendum on 30th April 2010
One way to practice questioning skills is using Q-Patterns by Vipul Kocher.
P.S: The title of this post is inspired by Rahul Mirakhur who made a mention of 'Questioning in your DNA' during one of our informal talks.
Happy Questioning,
Parimala Shankaraiah
19 December, 2009
Easter Eggs in Software
Easter eggs are specially decorated eggs given to celebrate the Easter holiday. These eggs are often hidden, allegedly by the Easter Bunny, for children to find on Easter morning as per Wikipedia.
Easter Eggs in software refer to hidden features in the program that are intentionally injected into the product by the programmer. These may include hidden commands, animations, funny jokes, games, credits for programmers who built the product etc. The programmers of easter eggs do it for their own personal reasons or for entertainment and are not meant to be harmful. If the programmer intentionally added malicious code to behave as a virus/spam/trojan, it may not be an easter egg. However, if the programmer added some code to behave as an easter egg that accidentally turned out to be harmful, it is still an easter egg.
How to unearth easter eggs?
Programmers Names
Search for the names of programmers who built the product. These are a very common form of easter eggs. These references mean that a few programmers wanted to take credit for the work done by them and inserted their names into the code without the knowledge of the management. More often, programmers resort to this method due to lack of appreciation for their work by the management.
Guidewords
Looking for swear words or expletives helps discover easter eggs. Dissatisfied/disgruntled/quitting employees may add these words in the code to take revenge on people they disliked or hated. I once saw a line reading ‘Thomas is a fool’ as part of a code snippet in one of the products that I tested a few years ago (No offense to Thomas here!).
Personalized images/animations
A few programmers embed their favorite images or animation in the code as they find themselves emotionally bound to the images/animations as much as the code that was written. For eg, a programmer might include icon images to include one of his favorite picture or a scenery.
Magical Keystrokes
A few easter eggs can be found by pressing a magical key combination/shortcut keys on the keyboard. These may be discovered accidentally or based on the knowledge of similar easter eggs in previous versions of the product.
Clusters of Easter Eggs
If an easter egg of any one type as described above was found, there is a high possibility of many more being found in close proximity to the already found egg. Pattern matching with previously found easter eggs helps find a few more surrounding them.
Read the code
Reading the code completely is one of the ways of looking for any unusual code that does not fall in line with the actual code in the product. Any code that is not in sync with the rest of the code may be easter eggs.
Ask the programmers
One of the fastest ways of finding most easter eggs is to ask the programmers themselves about what kind of easter eggs have been injected into the code. Not all programmers would reveal about all the easter eggs. A few of them might reveal theirs, but may not know about other programmers easter eggs. Some of them might be tightlipped to talk about easter eggs for fear of being fired or disciplined by the management.
Easter eggs by definition cause no harm by hiding inside the product. However, If the customers find easter eggs in the production environment, it could raise doubts about the kind of testing done on the product by the testers. The companies become liable for any offensive or illegal content that is shipped in the product and may face legal consequences. It is therefore very important to test for easter eggs as part of the normal testing process to avoid embarrassing situations after the product is shipped to the customer.
Start looking for Easter Eggs – in your software,
Happy Testing,
Parimala Shankaraiah
Easter Eggs in software refer to hidden features in the program that are intentionally injected into the product by the programmer. These may include hidden commands, animations, funny jokes, games, credits for programmers who built the product etc. The programmers of easter eggs do it for their own personal reasons or for entertainment and are not meant to be harmful. If the programmer intentionally added malicious code to behave as a virus/spam/trojan, it may not be an easter egg. However, if the programmer added some code to behave as an easter egg that accidentally turned out to be harmful, it is still an easter egg.
How to unearth easter eggs?
Programmers Names
Search for the names of programmers who built the product. These are a very common form of easter eggs. These references mean that a few programmers wanted to take credit for the work done by them and inserted their names into the code without the knowledge of the management. More often, programmers resort to this method due to lack of appreciation for their work by the management.
Guidewords
Looking for swear words or expletives helps discover easter eggs. Dissatisfied/disgruntled/quitting employees may add these words in the code to take revenge on people they disliked or hated. I once saw a line reading ‘Thomas is a fool’ as part of a code snippet in one of the products that I tested a few years ago (No offense to Thomas here!).
Personalized images/animations
A few programmers embed their favorite images or animation in the code as they find themselves emotionally bound to the images/animations as much as the code that was written. For eg, a programmer might include icon images to include one of his favorite picture or a scenery.
Magical Keystrokes
A few easter eggs can be found by pressing a magical key combination/shortcut keys on the keyboard. These may be discovered accidentally or based on the knowledge of similar easter eggs in previous versions of the product.
Clusters of Easter Eggs
If an easter egg of any one type as described above was found, there is a high possibility of many more being found in close proximity to the already found egg. Pattern matching with previously found easter eggs helps find a few more surrounding them.
Read the code
Reading the code completely is one of the ways of looking for any unusual code that does not fall in line with the actual code in the product. Any code that is not in sync with the rest of the code may be easter eggs.
Ask the programmers
One of the fastest ways of finding most easter eggs is to ask the programmers themselves about what kind of easter eggs have been injected into the code. Not all programmers would reveal about all the easter eggs. A few of them might reveal theirs, but may not know about other programmers easter eggs. Some of them might be tightlipped to talk about easter eggs for fear of being fired or disciplined by the management.
Easter eggs by definition cause no harm by hiding inside the product. However, If the customers find easter eggs in the production environment, it could raise doubts about the kind of testing done on the product by the testers. The companies become liable for any offensive or illegal content that is shipped in the product and may face legal consequences. It is therefore very important to test for easter eggs as part of the normal testing process to avoid embarrassing situations after the product is shipped to the customer.
Start looking for Easter Eggs – in your software,
Happy Testing,
Parimala Shankaraiah
07 December, 2009
Book Review: I am a Bug
I am a Bug is a book written by Robert Sabourin. This is a short book illustrated by his daughter Catherine which explains the software development process using cartoons and live examples from real time projects.
Little Nuggets from the book
1. When a bug is found, we do not ask if the bug is good or bad. We decide if it is important. We guess how much damage it could cause.
2. When we rush too much making new software, our offices and programs can get pretty messed up. We know there will be a lot of bugs!
3. Some bugs have many brothers and sisters (Bug clusters).
4. Bugs much worse than buffer overflows would just walk right by! (Inattentinal Blindness).
5. Some bugs are good friends! (Deferred bugs). A friendly bug is a bug that does not stop users from enjoying and benefiting from the software.
6. If we use the program in a different way, we will avoid some bugs completely (Change in perception).
7. Bugs can be fixed, avoided, or ignored. If a bug won't be fixed, users can be encouraged to use the software in a way that avoids the bug (Workarounds).
8. Sometimes we find bugs a long time after people start to use the program (Sleeping bugs).
9. Salespeople from tool vendors sometimes misrepresent the costs and benefits of tools and their ease of use. For example, they may claim that a test automation tool that can capture actions and play them back will "solve all your problems". They'll say, "Take this tool, and you can write a program that will find all your bugs."
Testers vs. Frogs
1. Frogs like bugs! People, at work, think positively about bugs. We like to find bugs!
2. Frogs eat bugs!
a. When we find bugs we really, really, really like to fix them!!
b. Whether or not a given bug should be fixed depends upon the business context.
c. Just as the frog's stomach can only contain a finite amount of bugs, a development team doesn't usually have the time, effort, and money to fix all of the bugs found in a program.
d. Bug priority and severity need to be established based on a cost/benefit analysis to figure out which bugs are worth fixing. The costs of not fixing a bug can be the damage to a user's computer, the number of support calls generated by a bug, damage to a company's reputation, and so on.
e. Just a few of the potential drawbacks of fixing a bug are the danger of injecting or uncovering more bugs, the developer time and effort spent, and the chance of decreasing adherence to quality goals for availability, performance, etc.
3. Bugs try to avoid frogs - Naturally, when we try to fix a bug, it tries to avoid us!
4. Getting lots of frogs (Crowdsourcing) can help get rid of lots of bugs. Once we decided to get lots of people to help us find and correct all the bugs. but too many frogs in the same place are a big problem too!!! But that didn't help because we got mixed up and confused.
5. How did we catch it? Is it important? Can it hurt us?
6. Quick patches don't solve problems. Fix it right the first time!
7. Think about how the program will be used. The exact same program can be used by many different people in many different ways, and a bug that is a dealbreaker for one user community may be inconsequential to another.
a. This is why I want everyone on a project or specific task within a project to have a common notion about what the answer to the fundamental question is. This way everyone knows what her role in the completion of the task is.
As testers, we are emotionally bound to every single bug that we report to the development. We expect that every bug be fixed in the immediate next build. In reality, it is very hard to fix all the bugs. Any business context demands that a product be released in the quickest time possible, within budget and on schedule. As a result, it is important to realize which bug is important and which is not. Testers are not decision makers, they are information providers. Let the decision makers decide which bug to fix. This book highlights the importance of bugs and the prioritization of fixes for the important bugs. I have documented important points from the book in the ‘Pearls of Wisdom’ section. Do take a look if that helps. Rob Sabourin has been generous to provide a FREE online version of this book on his website Amibug.com.
Happy Reading,
Parimala Shankaraiah
Little Nuggets from the book
1. When a bug is found, we do not ask if the bug is good or bad. We decide if it is important. We guess how much damage it could cause.
2. When we rush too much making new software, our offices and programs can get pretty messed up. We know there will be a lot of bugs!
3. Some bugs have many brothers and sisters (Bug clusters).
4. Bugs much worse than buffer overflows would just walk right by! (Inattentinal Blindness).
5. Some bugs are good friends! (Deferred bugs). A friendly bug is a bug that does not stop users from enjoying and benefiting from the software.
6. If we use the program in a different way, we will avoid some bugs completely (Change in perception).
7. Bugs can be fixed, avoided, or ignored. If a bug won't be fixed, users can be encouraged to use the software in a way that avoids the bug (Workarounds).
8. Sometimes we find bugs a long time after people start to use the program (Sleeping bugs).
9. Salespeople from tool vendors sometimes misrepresent the costs and benefits of tools and their ease of use. For example, they may claim that a test automation tool that can capture actions and play them back will "solve all your problems". They'll say, "Take this tool, and you can write a program that will find all your bugs."
Testers vs. Frogs
1. Frogs like bugs! People, at work, think positively about bugs. We like to find bugs!
2. Frogs eat bugs!
a. When we find bugs we really, really, really like to fix them!!
b. Whether or not a given bug should be fixed depends upon the business context.
c. Just as the frog's stomach can only contain a finite amount of bugs, a development team doesn't usually have the time, effort, and money to fix all of the bugs found in a program.
d. Bug priority and severity need to be established based on a cost/benefit analysis to figure out which bugs are worth fixing. The costs of not fixing a bug can be the damage to a user's computer, the number of support calls generated by a bug, damage to a company's reputation, and so on.
e. Just a few of the potential drawbacks of fixing a bug are the danger of injecting or uncovering more bugs, the developer time and effort spent, and the chance of decreasing adherence to quality goals for availability, performance, etc.
3. Bugs try to avoid frogs - Naturally, when we try to fix a bug, it tries to avoid us!
4. Getting lots of frogs (Crowdsourcing) can help get rid of lots of bugs. Once we decided to get lots of people to help us find and correct all the bugs. but too many frogs in the same place are a big problem too!!! But that didn't help because we got mixed up and confused.
5. How did we catch it? Is it important? Can it hurt us?
6. Quick patches don't solve problems. Fix it right the first time!
7. Think about how the program will be used. The exact same program can be used by many different people in many different ways, and a bug that is a dealbreaker for one user community may be inconsequential to another.
a. This is why I want everyone on a project or specific task within a project to have a common notion about what the answer to the fundamental question is. This way everyone knows what her role in the completion of the task is.
As testers, we are emotionally bound to every single bug that we report to the development. We expect that every bug be fixed in the immediate next build. In reality, it is very hard to fix all the bugs. Any business context demands that a product be released in the quickest time possible, within budget and on schedule. As a result, it is important to realize which bug is important and which is not. Testers are not decision makers, they are information providers. Let the decision makers decide which bug to fix. This book highlights the importance of bugs and the prioritization of fixes for the important bugs. I have documented important points from the book in the ‘Pearls of Wisdom’ section. Do take a look if that helps. Rob Sabourin has been generous to provide a FREE online version of this book on his website Amibug.com.
Happy Reading,
Parimala Shankaraiah
Subscribe to:
Posts (Atom)