I started blogging more than 3 and half years back. Since the time i wrote up that first post of mine, it’s been a constant endeavour from my side to come up with a quality post for my readers sharing my experiences and insights in Software Testing primarily, Management, Life skills and much more. I can assure you that each of the post that i wrote went through a lot of creative cycles and eventually got submitted. Some turned out good, some average and some bad. Some had a lot of comments, some few and some none. It’s actually a part of being a blogger and a writer. Bottom line is that i have been passionate about Software Testing and Writing and that’s what has been naturally driving this blog.
More than three years is a long time and with mind always looking to churn out some remarkable content to write, it can get challenging. I have decided to take a little break from blogging. I always believe that taking downtime is Important in life, be it your work life or even including anything that you love so much doing. This blog and my other interests comes almost as a second nature to me, So it’s quite hard not contributing here, even though briefly. In my experience, sometimes taking a step back often works wonders in your journey forward in a long run.
So Please don’t be disheartened if you don’t see a new content in this blog for a while. In all fairness to my readers, i should be back by or before end of July 2011.
I would be encouraged to see what you feel/think about this blog and also what do you want me to write on. Please do share your thoughts around these.
Monday, May 16, 2011
Friday, April 29, 2011
Of being a Self starter, Receiving Feedback, Mentorship and Michelangelo
I was recently reading thbe book- The Habit of Winning by Prakash Iyer and came across this story
The great painter and sculptor Michelangelo has several masterpieces to his credit. Perhaps at the top of that list is "David", his eighteen-foot-tall statue sculpted in marble in Florence, Italy. Now over 500 years old, this icon of Renaissance sculpture continues to attract- and fascinate- millions of visitors every year, from all over the world. Everyone who sees it goes back impressed by the genius of Michelangelo. But I am not sure if they all also take back the story behind the sculpting of this masterpiece.
The story goes that this mammoth eighteen-foot block of marble had been lying around for several years. In fact, it had been around long before Michelangelo was even born. Some great artists, including Leonardo da Vinci, were invited to create something from the slab of marble. They all looked at it and dismissed it as flawed and worthless. Nothing could come of it, they felt. Several years later, Michelangelo got to work on that 'flawed and worthless' piece of marble, and went on to create a magnificent work of art. Apparently, while he was working on David, a little boy went up to Michelangelo and asked him why he was banging away at the rock of marble, and hitting it so hard. 'Young man,' said Michelangelo. "There's an angel inside that rock. I am just setting him free.".
I did quite relate to this story as this tale is full of powerful lessons that we could apply in our Professional and Personal lives. Some of them below-
Power of Getting Started:
Before Michelangelo many renowned artists were called upon to give shape and life to this rough slab of marble but most of them dismissed the same as worthless even without thinking to try. Beyond all the artistic talent that Michelangelo had, he had a special quality i.e. the Power to initiate, that innate desire to start something.
In our work places, how many ideas (initiated by others or self) do we reject everyday either by saying or within our minds thinking they are worthless? How many times we get scared to ask a question in a large gathering thinking that people will ridicule even a single slip of tongue? How many times our own self stops us from trying something new just because that very something new will break the routine way of doing things ? I salute you if you answer "None" to any or all of these questions. But the fact of matter is that in most of the situations, without realizing, we fail to initiate. Many ideas die a silent death just because they are not allowed to come out, Just because we don’t get started.
I was reading this interesting article on How to measure Initiative ? . Found some great wisdom against which one can measure self on Initiative scale. It talks of following Stages-
1. Wait- People don’t initiate anything from self but keep waiting for Instructions.
2. Ask- Instead of Indefinitely waiting, you Ask your superior to involve you in something of meaning to you.
3. Recommend- This stage is more of not only "just" asking but also Recommending what interests you and the direction in which you would like to proceed.
4. Act Independently but Report Immediately- Think of an Action, Get convinced that it is right for business and take it immediately and report it back to Superior. This is mostly for areas you are delving into for the first time and building trust with your superior.
5. Act Independently and Report routinely- This is a stage when you are completely Independent and has been initiating lot of stuff from your side.
The story doesn’t tell whether Michelangelo had any boss but we certainly do have one. That’s why the above framework helps you know where you stand on an Initiative scale.
As Seth Godin says in his book Poke the Box , The challenge, it turns out, isn’t in perfecting your ability to know when to start and when to stand by. The challenge is getting into the habit of starting.
Start early, Start without someone prompting you- And become Michelangelo of your craft!
Mentorship:
When Michelangelo says those magical words- "There's an angel inside that rock ? I am just setting him free.", what is he actually doing to that rock. In some sense, he is acting as a Mentor to that Rock, chiselling it, correcting it and giving it a World class shape. Without googling for it, if i have to define a Mentor, he or she is someone who shapes your mind towards success in any undertaking. Mentor helps correct your flaws not even when going is rough but even stands to influence you even during normal conversations.
I always feel having a good mentor more important than being in the Influence of good books. It only helps to open up and look for mentor and create a stage for yourself to be a mentor to someone.
Receiving Feedback:
Another learning i gather from this story is that if the Rock was rigid, it would never have transformed into David. Likewise, if we as humans are rigid in receiving feedback, we would turn into a Rock that could never be moulded. Receiving feedback is as much as a skill as is relaying feedback. Hearing a negative feedback about self is sometimes as painful as Rock (if it was living) that Michelangelo chiselled. The ones who absorb this pain becomes better and eventually World class.
Do you have any more learnings from this Story ?
The great painter and sculptor Michelangelo has several masterpieces to his credit. Perhaps at the top of that list is "David", his eighteen-foot-tall statue sculpted in marble in Florence, Italy. Now over 500 years old, this icon of Renaissance sculpture continues to attract- and fascinate- millions of visitors every year, from all over the world. Everyone who sees it goes back impressed by the genius of Michelangelo. But I am not sure if they all also take back the story behind the sculpting of this masterpiece.
The story goes that this mammoth eighteen-foot block of marble had been lying around for several years. In fact, it had been around long before Michelangelo was even born. Some great artists, including Leonardo da Vinci, were invited to create something from the slab of marble. They all looked at it and dismissed it as flawed and worthless. Nothing could come of it, they felt. Several years later, Michelangelo got to work on that 'flawed and worthless' piece of marble, and went on to create a magnificent work of art. Apparently, while he was working on David, a little boy went up to Michelangelo and asked him why he was banging away at the rock of marble, and hitting it so hard. 'Young man,' said Michelangelo. "There's an angel inside that rock. I am just setting him free.".
I did quite relate to this story as this tale is full of powerful lessons that we could apply in our Professional and Personal lives. Some of them below-
Power of Getting Started:
Before Michelangelo many renowned artists were called upon to give shape and life to this rough slab of marble but most of them dismissed the same as worthless even without thinking to try. Beyond all the artistic talent that Michelangelo had, he had a special quality i.e. the Power to initiate, that innate desire to start something.
In our work places, how many ideas (initiated by others or self) do we reject everyday either by saying or within our minds thinking they are worthless? How many times we get scared to ask a question in a large gathering thinking that people will ridicule even a single slip of tongue? How many times our own self stops us from trying something new just because that very something new will break the routine way of doing things ? I salute you if you answer "None" to any or all of these questions. But the fact of matter is that in most of the situations, without realizing, we fail to initiate. Many ideas die a silent death just because they are not allowed to come out, Just because we don’t get started.
I was reading this interesting article on How to measure Initiative ? . Found some great wisdom against which one can measure self on Initiative scale. It talks of following Stages-
1. Wait- People don’t initiate anything from self but keep waiting for Instructions.
2. Ask- Instead of Indefinitely waiting, you Ask your superior to involve you in something of meaning to you.
3. Recommend- This stage is more of not only "just" asking but also Recommending what interests you and the direction in which you would like to proceed.
4. Act Independently but Report Immediately- Think of an Action, Get convinced that it is right for business and take it immediately and report it back to Superior. This is mostly for areas you are delving into for the first time and building trust with your superior.
5. Act Independently and Report routinely- This is a stage when you are completely Independent and has been initiating lot of stuff from your side.
The story doesn’t tell whether Michelangelo had any boss but we certainly do have one. That’s why the above framework helps you know where you stand on an Initiative scale.
As Seth Godin says in his book Poke the Box , The challenge, it turns out, isn’t in perfecting your ability to know when to start and when to stand by. The challenge is getting into the habit of starting.
Start early, Start without someone prompting you- And become Michelangelo of your craft!
Mentorship:
When Michelangelo says those magical words- "There's an angel inside that rock ? I am just setting him free.", what is he actually doing to that rock. In some sense, he is acting as a Mentor to that Rock, chiselling it, correcting it and giving it a World class shape. Without googling for it, if i have to define a Mentor, he or she is someone who shapes your mind towards success in any undertaking. Mentor helps correct your flaws not even when going is rough but even stands to influence you even during normal conversations.
I always feel having a good mentor more important than being in the Influence of good books. It only helps to open up and look for mentor and create a stage for yourself to be a mentor to someone.
Receiving Feedback:
Another learning i gather from this story is that if the Rock was rigid, it would never have transformed into David. Likewise, if we as humans are rigid in receiving feedback, we would turn into a Rock that could never be moulded. Receiving feedback is as much as a skill as is relaying feedback. Hearing a negative feedback about self is sometimes as painful as Rock (if it was living) that Michelangelo chiselled. The ones who absorb this pain becomes better and eventually World class.
Do you have any more learnings from this Story ?
Monday, April 4, 2011
What does Twitter bios say about Software Testers ?
This is meant to be just a fun post. If you are able to figure out any inferences (good or bad), i leave that entirely upto your own Interpretation.
I have included the Twitter bios of some of the people who are making some meaningful contributions to Software testing (except may be the last one in this list :-)). I am no authority to come up with the list of accomplished Software testers, so if you are reading and your name does not appear in the below list, Please feel free to think that i am at fault here.
Here we go, some Twitter Bios:
James Bach: @jamesmarcusbach
Author of Secrets of a Buccaneer-Scholar, high school dropout, unschooling parent, philosopher, neo-pyrrhonian skeptic, software tester
Arunkumar Khannur: @arun_khannur
Arunkumar Khannur, with 23+ years of IT career, is a Leading Advisor, Author, Speaker and Senior Faculty on Software Testing.
Praveen Singh: @vpsingh
Author'Real Startups' http://amzn.to/gqlImq Entrepreneur, Web Enthusiast, Blogger. Founder/CEO of 99tests.com
Michael Bolton: @michaelbolton
I solve testing problems that other people can't solve, and I teach people how they can do it too.
Ajay Balamurugadas: @ajay184f
Software tester passionate to learn to test any software
Jerry Weinberg: @JerryWeinberg
Author of more than 60 books, fiction & non-fiction, Consultant, Teacher
Shrini Kulkarni: @ShriniK
Software Testing Generalist, Systems thinker, Skeptic
Rahul Verma: @rahul_verma
Software Tester, Blogger, Python Enthusiast with special interest in performance testing, security testing and design of test automation frameworks
Vipul Kocher: @vipulkocher
Bhartiya, entrepreneur, Software Tester. Books, History, Movie, Food, ~Lover - TOO MANY INTERESTS, TOO FEW SKILLS
Narayan Raman: @narayanraman
Programmer, Wildlifer, Entrepreneur, CEO - Tyto Software, Author of Sahi (http://sahi.co.in)
Parimala Shankaraiah: @curioustester
Testing Junkie, Wife of a 30 yo kid, Mother of 3 yo kid, loves to read, enjoys long walks, foodie and a horrible cook!
Santosh Tuppad: @santhoshst
Passionate tester, blogger, testing enthusiast, friendly & fun loving. Director at Moolya Software Testing Private Limited.
Pradeep Soundararajan: @testertested
Known for creativity & moving software testing forward in India. Author Speaker Coach Consultant Director @ Moolya Software Testing Pvt Ltd http://moolya.com
Anuj Magazine: @anujmagazine
Passionate about Software Testing,ReadnWrite,Graphology,Running….Lives by- Life is beautiful because you can always do something that you have never done before
Some Inferences:
To me Twitter bio or any other bio for that matter is the manner in which the people want the public to view them. Sometimes, there is an intersection between how you view yourselves as against how you want the world to view you but such an intersection is rare. There is always some good deal of difference between the way the world views you as against who you really are. But lets forget this for sometime and go on and read the inferences i draw from all the above bios.
- For most of these people, they take pride in associating themselves to testing.
- Not for all though, the Testing is not the central theme of their bio as the word "Testing" does not appear in everyone's bio.
- For only a handful, the Years of experience in their respective field is important enough to deserve a mention in the bio.
- Most of these folks have multiple interests i.e. some prominent interests beyond Software Testing.
- For some, they associate themselves with an important event in their lives.
- Very few of these bios make a mention of their personal life in the bio. Most are inclined towards their professional achievements.
- Most of people like to highlight atleast one Achievement that differentiates them or makes them unique.
- Only a very few bios have some sort of numbers in their Bio. precisely, Years of experience, No. of books published and Age.
- While most indicated that they Love testing, very few were clear in their Bio on what type of testing they are keen on.
If you can think of any more inferences from these bios, Please add it to comments. Would love to hear your views.
I have included the Twitter bios of some of the people who are making some meaningful contributions to Software testing (except may be the last one in this list :-)). I am no authority to come up with the list of accomplished Software testers, so if you are reading and your name does not appear in the below list, Please feel free to think that i am at fault here.
Here we go, some Twitter Bios:
James Bach: @jamesmarcusbach
Author of Secrets of a Buccaneer-Scholar, high school dropout, unschooling parent, philosopher, neo-pyrrhonian skeptic, software tester
Arunkumar Khannur: @arun_khannur
Arunkumar Khannur, with 23+ years of IT career, is a Leading Advisor, Author, Speaker and Senior Faculty on Software Testing.
Praveen Singh: @vpsingh
Author'Real Startups' http://amzn.to/gqlImq Entrepreneur, Web Enthusiast, Blogger. Founder/CEO of 99tests.com
Michael Bolton: @michaelbolton
I solve testing problems that other people can't solve, and I teach people how they can do it too.
Ajay Balamurugadas: @ajay184f
Software tester passionate to learn to test any software
Jerry Weinberg: @JerryWeinberg
Author of more than 60 books, fiction & non-fiction, Consultant, Teacher
Shrini Kulkarni: @ShriniK
Software Testing Generalist, Systems thinker, Skeptic
Rahul Verma: @rahul_verma
Software Tester, Blogger, Python Enthusiast with special interest in performance testing, security testing and design of test automation frameworks
Vipul Kocher: @vipulkocher
Bhartiya, entrepreneur, Software Tester. Books, History, Movie, Food, ~Lover - TOO MANY INTERESTS, TOO FEW SKILLS
Narayan Raman: @narayanraman
Programmer, Wildlifer, Entrepreneur, CEO - Tyto Software, Author of Sahi (http://sahi.co.in)
Parimala Shankaraiah: @curioustester
Testing Junkie, Wife of a 30 yo kid, Mother of 3 yo kid, loves to read, enjoys long walks, foodie and a horrible cook!
Santosh Tuppad: @santhoshst
Passionate tester, blogger, testing enthusiast, friendly & fun loving. Director at Moolya Software Testing Private Limited.
Pradeep Soundararajan: @testertested
Known for creativity & moving software testing forward in India. Author Speaker Coach Consultant Director @ Moolya Software Testing Pvt Ltd http://moolya.com
Anuj Magazine: @anujmagazine
Passionate about Software Testing,ReadnWrite,Graphology,Running….Lives by- Life is beautiful because you can always do something that you have never done before
Some Inferences:
To me Twitter bio or any other bio for that matter is the manner in which the people want the public to view them. Sometimes, there is an intersection between how you view yourselves as against how you want the world to view you but such an intersection is rare. There is always some good deal of difference between the way the world views you as against who you really are. But lets forget this for sometime and go on and read the inferences i draw from all the above bios.
- For most of these people, they take pride in associating themselves to testing.
- Not for all though, the Testing is not the central theme of their bio as the word "Testing" does not appear in everyone's bio.
- For only a handful, the Years of experience in their respective field is important enough to deserve a mention in the bio.
- Most of these folks have multiple interests i.e. some prominent interests beyond Software Testing.
- For some, they associate themselves with an important event in their lives.
- Very few of these bios make a mention of their personal life in the bio. Most are inclined towards their professional achievements.
- Most of people like to highlight atleast one Achievement that differentiates them or makes them unique.
- Only a very few bios have some sort of numbers in their Bio. precisely, Years of experience, No. of books published and Age.
- While most indicated that they Love testing, very few were clear in their Bio on what type of testing they are keen on.
If you can think of any more inferences from these bios, Please add it to comments. Would love to hear your views.
Friday, April 1, 2011
Should the testers be responsible for pinponting the cause of Defects ?
A tester works fabulously to find an important bug in an application and raises a bug report with lot of excitement and possibly all the details that he could include. The bug is 100% reproducible. After some days, the bug report gets assigned back to him stating that the Developer needs more information. Upon further analysis of the request, the tester figures out that Developer is actually requesting for assistance to help him "pinpoint" the problem in the code. Of course, the Developer is not asking the tester to go through the code but asking more intricate details that are beyond the scope of a bug report (as the bug is 100% reproducible). The tester is in confused state! He thinks that he provided all the information that was there to be provided and the bug is 100% reproducible, then why on earth would a developer need more Information. Let’s look at a perspective about this problem-
Is pinpointing problem a part of test group's job?
In my view, in an ideal world, in couple of words- It should be. Let me explain my perspective here.
Project teams develop Software to serve the customers. The test teams primarily exist to provide Specialized Services to the overall projects. The extent of Service include “what” and “how” of it and primarily depend upon the overall Testing mission we choose. Generally, one of the common views is to consider testing only as “Detection” and “Reporting” of issues. That certainly leaves out pinpointing activity. To simply put, pinpointing a problem is a activity that helps a developer figure out the buggy part of code.
It’s no wrong in treating testing more alongside the “Detection” and “Reporting” areas but when we talk about the notion of Service, one of the things that get associated with it is Value generation. In my view- In any Service related profession, more than anything else, the overall Value should always be upwardly mobile. Value from the testing group as such is perceived differently by different people who we work with and provide our Services.
Testing all that’s possible, Providing an Accurate flawless defect report, Providing accurate bug related information (metrics) that can help Management make crucial product decision, Helping support team giving crucial information on a customer problem etc. are some Value generating activities that goes beyond the idea of Detecting and Reporting. Of course, Pinpointing problems is another activity that helps add Value as a developer perceives it from the Test group. I know in some cases test teams even helped in fixing the bugs, so essentially it boils down to what “mission” do we commit to.
As Gerald Weinberg also states in his book Perfect Software: And Other Illusions about Testing
Testing (can be) for Discovery, pinpointing, Locating, determining significance, repairing, troubleshooting and testing to learn.
As I mentioned in the beginning, the above description represents and close to Ideal world situation.
Is it really possible to have the clear distinction between pinpointing and testing?
I think No, its not possible to create that distinction especially when we consider the product from a black-box perspective. If we do White-box testing, it is possible to have some sort of clear distinction. I think more or less every good bug report has some level of Troubleshooting done. But “some level of troubleshooting” is often not as accurate as “pinpointing”. Pinpointing just helps the developer to reach the faulty lines of code, identify the problem and fix it. Apparently, in a product with millions of lines of code reaching that faulty line of code is a very tedious job (sometimes a mystery!). If a tester helps a developer do that, then we have a delighted customer (i.e. if at all we treat him/her as a customer. In normal circumstances, we should). From test perspective, it is again the amount of cost we are willing to spend to reach this level of delight. Again, it leads to the eternal question- “what is our mission”.
In short, it is not possible to have that clear distinction between pinpointing and testing in our kind of test setup.
Does the time-limit heuristic usually work always ?
Gerald Weinberg also talks about Time-limit heuristic.
A heuristic that helps untangle who does what for how long states the concept simply:
Nobody on a project should carelessly waste the time of anyone on the project
According to this, the test team member sets a time limit and communicate to the Development team on how much time can they spend on the Development specific investigation. Beyond this time, the onus is on the Development team to figure out.
Since this is a heuristic and not a rule, its quite hard to define the time-limit. Only way it can work is if we make it as a rule i.e. Test team would not spend more than 1 man-day or whatever is the limit and track it accordingly. Doing so (without prior agreement) , will cause some grim repercussions including the relations with Development team.
Having said this, testers don’t have endless time at their disposal. So, till the time there are a formal guidelines around this, it's good to make the Development team (requesting the pinpointing Service) aware of the extent we can help without causing the Testing schedule in Jeopardy.
If the bug is reproducible, to what extent should the test team help the dev pinpoint the bug?
The greater degree of conflict (regarding pinpointing) between Dev and Test arises when the bug is reproducible 100% of time. Ideally, the Dev should Investigate, debug and figure out where the bug is in the code with some help from Test team.
If the bug is non-reproducible then there is even finer distinction between Bug detecting and bug pinpointing. I think Test team should lead the Investigation here whereas for Reproducible bugs the Dev team should lead the investigation.
Closing thoughts:
Considering the above points, I can think of the following points-
• Get in agreement with the Dev team on what level of pinpointing can the test team help with. It should be made clear at the start of project involvement.
• Have a Clear distinction on what Activities include Detection, Troubleshooting and Pinpointing. Possibly, include the same in the Test plan.
• Include Pinpointing activities as a part of Standard Test estimations. It won’t be too high a cost considering the entire span of release but it is worthwhile to consider it as a separate line-item.
• Be aware of impacts of frequent Task-switching for testers (which usually happens when testers switches to Bug investigation away from testing work). Not everyone can do it with an ease. This can be one area specific training can be designed/conducted for testers if there is a need.
Any thoughts ?
Is pinpointing problem a part of test group's job?
In my view, in an ideal world, in couple of words- It should be. Let me explain my perspective here.
Project teams develop Software to serve the customers. The test teams primarily exist to provide Specialized Services to the overall projects. The extent of Service include “what” and “how” of it and primarily depend upon the overall Testing mission we choose. Generally, one of the common views is to consider testing only as “Detection” and “Reporting” of issues. That certainly leaves out pinpointing activity. To simply put, pinpointing a problem is a activity that helps a developer figure out the buggy part of code.
It’s no wrong in treating testing more alongside the “Detection” and “Reporting” areas but when we talk about the notion of Service, one of the things that get associated with it is Value generation. In my view- In any Service related profession, more than anything else, the overall Value should always be upwardly mobile. Value from the testing group as such is perceived differently by different people who we work with and provide our Services.
Testing all that’s possible, Providing an Accurate flawless defect report, Providing accurate bug related information (metrics) that can help Management make crucial product decision, Helping support team giving crucial information on a customer problem etc. are some Value generating activities that goes beyond the idea of Detecting and Reporting. Of course, Pinpointing problems is another activity that helps add Value as a developer perceives it from the Test group. I know in some cases test teams even helped in fixing the bugs, so essentially it boils down to what “mission” do we commit to.
As Gerald Weinberg also states in his book Perfect Software: And Other Illusions about Testing
Testing (can be) for Discovery, pinpointing, Locating, determining significance, repairing, troubleshooting and testing to learn.
As I mentioned in the beginning, the above description represents and close to Ideal world situation.
Is it really possible to have the clear distinction between pinpointing and testing?
I think No, its not possible to create that distinction especially when we consider the product from a black-box perspective. If we do White-box testing, it is possible to have some sort of clear distinction. I think more or less every good bug report has some level of Troubleshooting done. But “some level of troubleshooting” is often not as accurate as “pinpointing”. Pinpointing just helps the developer to reach the faulty lines of code, identify the problem and fix it. Apparently, in a product with millions of lines of code reaching that faulty line of code is a very tedious job (sometimes a mystery!). If a tester helps a developer do that, then we have a delighted customer (i.e. if at all we treat him/her as a customer. In normal circumstances, we should). From test perspective, it is again the amount of cost we are willing to spend to reach this level of delight. Again, it leads to the eternal question- “what is our mission”.
In short, it is not possible to have that clear distinction between pinpointing and testing in our kind of test setup.
Does the time-limit heuristic usually work always ?
Gerald Weinberg also talks about Time-limit heuristic.
A heuristic that helps untangle who does what for how long states the concept simply:
Nobody on a project should carelessly waste the time of anyone on the project
According to this, the test team member sets a time limit and communicate to the Development team on how much time can they spend on the Development specific investigation. Beyond this time, the onus is on the Development team to figure out.
Since this is a heuristic and not a rule, its quite hard to define the time-limit. Only way it can work is if we make it as a rule i.e. Test team would not spend more than 1 man-day or whatever is the limit and track it accordingly. Doing so (without prior agreement) , will cause some grim repercussions including the relations with Development team.
Having said this, testers don’t have endless time at their disposal. So, till the time there are a formal guidelines around this, it's good to make the Development team (requesting the pinpointing Service) aware of the extent we can help without causing the Testing schedule in Jeopardy.
If the bug is reproducible, to what extent should the test team help the dev pinpoint the bug?
The greater degree of conflict (regarding pinpointing) between Dev and Test arises when the bug is reproducible 100% of time. Ideally, the Dev should Investigate, debug and figure out where the bug is in the code with some help from Test team.
If the bug is non-reproducible then there is even finer distinction between Bug detecting and bug pinpointing. I think Test team should lead the Investigation here whereas for Reproducible bugs the Dev team should lead the investigation.
Closing thoughts:
Considering the above points, I can think of the following points-
• Get in agreement with the Dev team on what level of pinpointing can the test team help with. It should be made clear at the start of project involvement.
• Have a Clear distinction on what Activities include Detection, Troubleshooting and Pinpointing. Possibly, include the same in the Test plan.
• Include Pinpointing activities as a part of Standard Test estimations. It won’t be too high a cost considering the entire span of release but it is worthwhile to consider it as a separate line-item.
• Be aware of impacts of frequent Task-switching for testers (which usually happens when testers switches to Bug investigation away from testing work). Not everyone can do it with an ease. This can be one area specific training can be designed/conducted for testers if there is a need.
Any thoughts ?
Tuesday, March 29, 2011
How well do your team members know each other ?
Sometime back i wrote on the topic- How well do you know your team..." which had a prime focus on team work and why knowing the team is a prime tasks for any leader. In today's world, no matter how virtual we may become in conducting our work , the team bonding remains one of the foremost task for a leader. It’s not only important for a leader to know his or her team but it is also of great significance for the team members to know each other. This is especially true of a team in which people have been working together for a while, may be 2-3 years and beyond.
One can always argue that more the team members work with each other-the more time they spend together, the more they "know" each other. While this may be true to an extent, it is equally true that more time people spend working with each other, the more they start taking each other's strengths for granted. And they start considering their egos bigger than relationship and think more of shortcomings rather than positives. I don’t write this to say that this is necessarily right or wrong but this aspect is very human for sure.
It does become challenging to appreciate each other's strengths after a while so there is a constant need to remind each other of the value that each one brings in to the organization and to the team. How can one remind other team member of their Strengths ? He or She can openly appreciate the other person but in true sense this may sound as more artificial than anything else. There can be many ways to address this but i have found one exercise when done with the team quite useful to address this aspect.
Here are the details-
Required:
• blank sheets of paper (same as no. of team members)
• pens (same as no. of teamm members)
• Around 20-30 min in a team meeting
• Paricipants with Open unbiased mind
Procedure:
1. Participants sitting in a sort of round table setting.
2. Each participant gets one piece of paper and write their name on it.
3. As a next step, each participant passes on the paper (with their name) to the person sitting on right of him/her.
4. Each person now has a paper with someone else’s name on it.
5. As a next step, Each participant thinks for a while (1 minute or less) and writes something positive about the person who name appears on the sheet. The participant need not write his/her name with the comment. “Something positive” can be even some good instance, good experience that he/she would have shared with that person, or some personality trait he/she likes about him/her or even some professional achievement, skill about that person. Preferably write it in sentence form rather than a single word. The bottom line is that it should be something positive. If you need more to write, take it but try and be as honest as possible in the praise.
6. After the participant has completed writing, go to Step# 3 till 5 repeatedly till you get the paper with your name back.
7. After you receive the sheet with your name, each person tells any one interesting Positive thing someone has written about him/her.
Benefits:
• Helps people thinking something positive (beyond their egos) about the team members and reinforcing that belief.
• Help people reinforce the fact that irrespective of the personality differences, there is something positive to cherish about.
• The final sheet is something people can keep with them and refer to it anytime later. This can be referred especially when chips are down and looking at the positives helps one regain the confidence.
• Share some light moments within the team especially when everyone is communicating the Interesting Positive fact in a team setting.
Do you know of any other interesting ways ?
One can always argue that more the team members work with each other-the more time they spend together, the more they "know" each other. While this may be true to an extent, it is equally true that more time people spend working with each other, the more they start taking each other's strengths for granted. And they start considering their egos bigger than relationship and think more of shortcomings rather than positives. I don’t write this to say that this is necessarily right or wrong but this aspect is very human for sure.
It does become challenging to appreciate each other's strengths after a while so there is a constant need to remind each other of the value that each one brings in to the organization and to the team. How can one remind other team member of their Strengths ? He or She can openly appreciate the other person but in true sense this may sound as more artificial than anything else. There can be many ways to address this but i have found one exercise when done with the team quite useful to address this aspect.
Here are the details-
Required:
• blank sheets of paper (same as no. of team members)
• pens (same as no. of teamm members)
• Around 20-30 min in a team meeting
• Paricipants with Open unbiased mind
Procedure:
1. Participants sitting in a sort of round table setting.
2. Each participant gets one piece of paper and write their name on it.
3. As a next step, each participant passes on the paper (with their name) to the person sitting on right of him/her.
4. Each person now has a paper with someone else’s name on it.
5. As a next step, Each participant thinks for a while (1 minute or less) and writes something positive about the person who name appears on the sheet. The participant need not write his/her name with the comment. “Something positive” can be even some good instance, good experience that he/she would have shared with that person, or some personality trait he/she likes about him/her or even some professional achievement, skill about that person. Preferably write it in sentence form rather than a single word. The bottom line is that it should be something positive. If you need more to write, take it but try and be as honest as possible in the praise.
6. After the participant has completed writing, go to Step# 3 till 5 repeatedly till you get the paper with your name back.
7. After you receive the sheet with your name, each person tells any one interesting Positive thing someone has written about him/her.
Benefits:
• Helps people thinking something positive (beyond their egos) about the team members and reinforcing that belief.
• Help people reinforce the fact that irrespective of the personality differences, there is something positive to cherish about.
• The final sheet is something people can keep with them and refer to it anytime later. This can be referred especially when chips are down and looking at the positives helps one regain the confidence.
• Share some light moments within the team especially when everyone is communicating the Interesting Positive fact in a team setting.
Do you know of any other interesting ways ?
Wednesday, March 16, 2011
Myths about Globalization Testing
I think i havent contributed to the Myths about Globalization Testing Series in a while. I do intend to write more about this and soon. In the meantime, i thought to just go back in time a little and list all myths that i have worked to uncover in the previous blogs. Here's the list-
Uncovering Myths about Globalization testing -1
Myth 1: G11n testing is not technical enough
Myth 2: G11n testing is majorly about testing the UI
Myth 3: G11n Testing can start only after the base product is translated
Uncovering Myths about Globalization testing -2
Myth 4: A person who doesn't know French cannot test the French version of the Software
Myth 5: A tester only needs to follow the test cases executed for Base language in order to thoroughly test the internationalized applications
Myth 6: There is no scope of exploratory testing while testing internationalized applications
Myth 7: The language verification of User Interface can be done by comparing the text on screen with translation outputs of any freely available Online translator.
Uncovering Myths about Globalization testing -3
Myth 8: If a test case works fine in French language, it will work fine in German language as well
Myth 9: If the Foreign text input in application text fields work fine by using the Soft keys, then it means the data input through respective Foreign language key board would also work fine.
Myth 10: Globalization testing doesn't require the same test setup as is required to do the Base language testing. Globalization testing can be done with a minimum test setup.
Uncovering Myths about Globalization testing -4
Myth 11: Localization - means Localized product on a localized Operating System, Internationalization- means Localized product on English Operating System
Uncovering Myths about Globalization testing- Demystifying MUI Packs
Myth 12: Testing International applications using "Microsoft's MUI Pack" or "Localized OS installation" means one and the same thing
Uncovering Myths about Globalization testing- Input validation testing 2
Myth 13- A tester can perform tests specific to text inputs for Localized applications using the similar approaches as the English language testing
Uncovering Myths...."Security Testing is from Mars and Globalization Testing is from Venus"
Myth 14- Security Testing is from Mars and Globalization testing is from Venus
Uncovering Myths about Globalization testing- English version on Localized setup
Myth 15: There is no use testing the English version of a product on Localized Operating systems
Uncovering Myths about Globalization testing- MUI Packs in Win XP and Win Vista
Myth 16: There is no difference between MUI technology being used in Win XP and Win Vista
Uncovering myths about Globalization Testing- Reusing Test Automation
Myth 17: The test scripts meant for English language automated tests cannot be reused for Internationalization testing
Uncovering myths about Globalization testing- Context driven planning
Myth 18: There is one standard way of Test Planning the Globalization testing, which is applicable to all the contexts.
Uncovering Myths about Globalization Testing- Websites with localized addresses
Myth 19: There is no need to include localized web addresses as a part of your test data as Web addresses are always in English
Uncovering Myths about Globalization Testing- Knowledge of Native Language
Myth 20: If i dont know German at all, i can still effectively test a German application
Uncovering myths about Globalization Testing- Finding Localization bugs before actual translation takes place
Myth 21: It is not possible to find the Localization bugs before actual translation takes place
Uncovering myths about Globalization Testing- Testing MUI feature
Myth 22 : A tester testing Globalization features need not pay any special attention towards testing MUI feature.
Uncovering myths about Globalization testing- Approach to generate Localized test data
Myth 23: It is possibly the right strategy to randomly pick the test data specific to the localized language you are testing
Hope you enjoyed going over these again. Would appreciate your comments, suggestions!
Uncovering Myths about Globalization testing -1
Myth 1: G11n testing is not technical enough
Myth 2: G11n testing is majorly about testing the UI
Myth 3: G11n Testing can start only after the base product is translated
Uncovering Myths about Globalization testing -2
Myth 4: A person who doesn't know French cannot test the French version of the Software
Myth 5: A tester only needs to follow the test cases executed for Base language in order to thoroughly test the internationalized applications
Myth 6: There is no scope of exploratory testing while testing internationalized applications
Myth 7: The language verification of User Interface can be done by comparing the text on screen with translation outputs of any freely available Online translator.
Uncovering Myths about Globalization testing -3
Myth 8: If a test case works fine in French language, it will work fine in German language as well
Myth 9: If the Foreign text input in application text fields work fine by using the Soft keys, then it means the data input through respective Foreign language key board would also work fine.
Myth 10: Globalization testing doesn't require the same test setup as is required to do the Base language testing. Globalization testing can be done with a minimum test setup.
Uncovering Myths about Globalization testing -4
Myth 11: Localization - means Localized product on a localized Operating System, Internationalization- means Localized product on English Operating System
Uncovering Myths about Globalization testing- Demystifying MUI Packs
Myth 12: Testing International applications using "Microsoft's MUI Pack" or "Localized OS installation" means one and the same thing
Uncovering Myths about Globalization testing- Input validation testing 2
Myth 13- A tester can perform tests specific to text inputs for Localized applications using the similar approaches as the English language testing
Uncovering Myths...."Security Testing is from Mars and Globalization Testing is from Venus"
Myth 14- Security Testing is from Mars and Globalization testing is from Venus
Uncovering Myths about Globalization testing- English version on Localized setup
Myth 15: There is no use testing the English version of a product on Localized Operating systems
Uncovering Myths about Globalization testing- MUI Packs in Win XP and Win Vista
Myth 16: There is no difference between MUI technology being used in Win XP and Win Vista
Uncovering myths about Globalization Testing- Reusing Test Automation
Myth 17: The test scripts meant for English language automated tests cannot be reused for Internationalization testing
Uncovering myths about Globalization testing- Context driven planning
Myth 18: There is one standard way of Test Planning the Globalization testing, which is applicable to all the contexts.
Uncovering Myths about Globalization Testing- Websites with localized addresses
Myth 19: There is no need to include localized web addresses as a part of your test data as Web addresses are always in English
Uncovering Myths about Globalization Testing- Knowledge of Native Language
Myth 20: If i dont know German at all, i can still effectively test a German application
Uncovering myths about Globalization Testing- Finding Localization bugs before actual translation takes place
Myth 21: It is not possible to find the Localization bugs before actual translation takes place
Uncovering myths about Globalization Testing- Testing MUI feature
Myth 22 : A tester testing Globalization features need not pay any special attention towards testing MUI feature.
Uncovering myths about Globalization testing- Approach to generate Localized test data
Myth 23: It is possibly the right strategy to randomly pick the test data specific to the localized language you are testing
Hope you enjoyed going over these again. Would appreciate your comments, suggestions!
Saturday, February 19, 2011
Have you defined your Body of Work ?
I tried searching for Software Testing Records, could not find anything. Why dont Software Testers have any records ?
This was one of the questions raised by one of the participant in an Open session of recently concluded Bug-De-Bug conference . Honestly, a part of me thought of dismissing it as one of those naive questions usually asked in the public forums/conferences. Luckily, another (and better) part persisted in giving this question a more thought in-depth.
During my early days in the profession, i often used to wonder- Why cannot Software Testing be as glamorous a profession as Cinema or Politics or may be like Soccer or Cricket ? What aren't Software Testers as popular and as famous as people involved in these fields ? As the time has passed and if i look back to find the answers to these questions, i see it in different ways listed below-
- Everything that is Glamorous and popular isn’t necessarily always great. We have had several example of High profile Politicians, Actors and even Sports personalities who are involved in larger than life scams thereby signifying a sort of ethical deficit. All that Glitters is certainly not Gold!
- With time and energy of people, Software Testing profession has evolved into a larger ecosystem, which is large enough to have its own Celebrities. It was not very long ago that Jerry Weinberg got chosen as a Testing Luminary by a democratic voting process. Is Jerry any short of a Testing Celebrity ? There are a lot of media coverage associated with Software Testing and its practitioners. And all this attention is well-deserved for a profession that is expected to have a market of $56 Billion by 2013. Yes, you heard that number right, its $ 56 Billion. The future of testing is going to see a lot of new Celebrities evolve and who knows it may become a sort of Glamorous profession (in literal sense) when someone comes up with a concept of Reality Show on Software Testing possibly having real time testers working in time-bound interval to test a challenging Software. Wow, the future looks exciting!
Thinking over both these questions again- there may be many reasons why dont we have records for Software Testing like there is no historian taking care of maintaining the record (like we have in various Sports, Politics), Nobody has attempted to apply in Guinness Book of World records or may be testers are not really fascinated by records or by being Glamorous and like to silently add value to the product.
Now, that raises a very Interesting question- What are Software Testers really fascinated by ? What defines the body of work for a Software Tester ? One of the Art blogs defined Body of Work as something that is comprised of multiple pieces that are cohesive in nature.
Robin Sharma in one of his books mentions this anecdote about the Body of Work-
Art Buchwald, the writer, who was around 80 and battling Kidney failure was once asked, "What is your idea of perfect happiness ?" "Being Healthy" was his reply. He was asked, "Which talent would you most like to have ?" "Living" was his reply. Then he was asked, "What is your most treasured possession ?" "All of my writing- my 32 books and all of my columns".
The point of wisdom that you and I can take away ? Greatness comes when you create something with your life that is not only bigger that you but outlasts you. Legitimacy and recognition and prestige and material things are all fine and are very human pursuits. But there is something far more important: Legacy. Making a difference. Having an impact. Creating something special. And meaningful.
What Body of Work will you create over your life so that the generations who follow will know that you've been here ? What will your "most treasured possession" look like ?
If you as a Software Tester are at the fag end of your career, what kind of things do you want to look back with pride ?
If you were to do a paragraph about your accomplishments in Software Testing, how would it look ?
Have you defined your Body of Work ?
This was one of the questions raised by one of the participant in an Open session of recently concluded Bug-De-Bug conference . Honestly, a part of me thought of dismissing it as one of those naive questions usually asked in the public forums/conferences. Luckily, another (and better) part persisted in giving this question a more thought in-depth.
During my early days in the profession, i often used to wonder- Why cannot Software Testing be as glamorous a profession as Cinema or Politics or may be like Soccer or Cricket ? What aren't Software Testers as popular and as famous as people involved in these fields ? As the time has passed and if i look back to find the answers to these questions, i see it in different ways listed below-
- Everything that is Glamorous and popular isn’t necessarily always great. We have had several example of High profile Politicians, Actors and even Sports personalities who are involved in larger than life scams thereby signifying a sort of ethical deficit. All that Glitters is certainly not Gold!
- With time and energy of people, Software Testing profession has evolved into a larger ecosystem, which is large enough to have its own Celebrities. It was not very long ago that Jerry Weinberg got chosen as a Testing Luminary by a democratic voting process. Is Jerry any short of a Testing Celebrity ? There are a lot of media coverage associated with Software Testing and its practitioners. And all this attention is well-deserved for a profession that is expected to have a market of $56 Billion by 2013. Yes, you heard that number right, its $ 56 Billion. The future of testing is going to see a lot of new Celebrities evolve and who knows it may become a sort of Glamorous profession (in literal sense) when someone comes up with a concept of Reality Show on Software Testing possibly having real time testers working in time-bound interval to test a challenging Software. Wow, the future looks exciting!
Thinking over both these questions again- there may be many reasons why dont we have records for Software Testing like there is no historian taking care of maintaining the record (like we have in various Sports, Politics), Nobody has attempted to apply in Guinness Book of World records or may be testers are not really fascinated by records or by being Glamorous and like to silently add value to the product.
Now, that raises a very Interesting question- What are Software Testers really fascinated by ? What defines the body of work for a Software Tester ? One of the Art blogs defined Body of Work as something that is comprised of multiple pieces that are cohesive in nature.
Robin Sharma in one of his books mentions this anecdote about the Body of Work-
Art Buchwald, the writer, who was around 80 and battling Kidney failure was once asked, "What is your idea of perfect happiness ?" "Being Healthy" was his reply. He was asked, "Which talent would you most like to have ?" "Living" was his reply. Then he was asked, "What is your most treasured possession ?" "All of my writing- my 32 books and all of my columns".
The point of wisdom that you and I can take away ? Greatness comes when you create something with your life that is not only bigger that you but outlasts you. Legitimacy and recognition and prestige and material things are all fine and are very human pursuits. But there is something far more important: Legacy. Making a difference. Having an impact. Creating something special. And meaningful.
What Body of Work will you create over your life so that the generations who follow will know that you've been here ? What will your "most treasured possession" look like ?
If you as a Software Tester are at the fag end of your career, what kind of things do you want to look back with pride ?
If you were to do a paragraph about your accomplishments in Software Testing, how would it look ?
Have you defined your Body of Work ?
Subscribe to:
Posts (Atom)
