Earlier in the month of July, i was involved in presenting a TechTalk at Aditi Technologies in Bangalore. The TechTalk was on the topic- "Uncovering myths around Globalization Testing".
This talk was as a result of Invitation by one of the Testing community members Ravisuriya . Thank you Ravisuriya.
The presentation for this talk can be found here .
The overall Presentation setup was good and there were quite a few questions in the end about the topic discussed. One of the questions that caught my attention was-
"Is it possible to eliminate Globalization testing altogether?”
Although as a passionate professional, i may be biased in my views and opinions around this but this one is good to think further and investigate. I did respond with a "No" with some reasons around external dependencies and Product architecture and lot of other variable factors but this one certainly deserves a little bit more thought.
There was one more good question on what is the right ratio of Globalization testing vs English Testing.
I would write about my perspective to these questions sometime soon.
Friday, July 29, 2011
Sunday, July 24, 2011
One Effective way to learn about Software Globalization Engineering
If you want to Learn about Software Globalization Engineering, one of the practical tools that i have come across is "World Ready Software Example", which can be found here .
Originally designed to support only Windows 2000 and Windows XP, this tool actually works on Windows 7 to a good extent. You can actually try out several features of a fully Globalized application.
What can you do with this tool ?
- You can check the Local formats like Date, Time, Currency, Calendar, Numbers from the loads of different locales.
- You can input any Unicode characters and see how a truly Globalized application processes the characters,\.
- You can check the Multilingual User Interface feature and change the current language to any listed language at the run-time.
- You can simulate Pseudo Translation.
- You can simulate Pseudo Mirroring. Mirroring is the process of simulating the RTL (Right-to-Left languages like Arabic etc.).
- And much more.
How does this tool look like ?
Originally designed to support only Windows 2000 and Windows XP, this tool actually works on Windows 7 to a good extent. You can actually try out several features of a fully Globalized application.
What can you do with this tool ?
- You can check the Local formats like Date, Time, Currency, Calendar, Numbers from the loads of different locales.
- You can input any Unicode characters and see how a truly Globalized application processes the characters,\.
- You can check the Multilingual User Interface feature and change the current language to any listed language at the run-time.
- You can simulate Pseudo Translation.
- You can simulate Pseudo Mirroring. Mirroring is the process of simulating the RTL (Right-to-Left languages like Arabic etc.).
- And much more.
How does this tool look like ?
Sunday, July 3, 2011
Presented at the SofTec 2011 Software Testing Conference
I am back and on the time that i promised. Breaks are always good and this one was no different.
I got the invitation to present at Silicon India's SofTec 2011 Software Testing Conference and completed my presentation yesterday. The stage was not new for me having presented in 2010 edition as well(on the same stage). When i got the call to present at the conference, i had in mind to speak about Cloud phenomenon for some reasons-
- In 2010, i presented on "Globalization Testing- Getting your Software World Ready". This year it had to be different.
- Cloud is more of an in-phenomenon and more relevant to talk about in the Conference.
- I had developed a fascination for the similar topic earlier this year and thought i could build upon that.
Summary of my talk:
So my Topic for SofTec 2011 was- "The Emergence of Cloud Computing and Software Testing- A Perspective". I primarily talked broadly on the following areas-
- Importance of Learning by Association.
- Associating the origin of Cloud computing with the Advent of Electricity.
- Basics of Cloud computing including Grid and Utility computing.
- Covering the business models around Cloud Computing- including IaaS, PaaS, SaaS.
- The inter-relation between Cloud Computing and Software Testing.
- What are the different ways Testing could be moved on to the cloud- Public cloud, Private Cloud, Hybrid clouds.
- Explaining the Fundamental shift from the testers owning Physical machines to test Software applications traditionally to now testers owning raw computing power. All this made possible with Virtualization.
- How could Cloud's elasticity be used effectively in Software testing ?
- How does cloud amount to Green Software Testing ?
- How can Snapshot features help the Software Testing ?
- How is the Virtual lab automation make Software Testing effective ?
- Then i discussed some Live examples primarily featuring-
- Test Management on the Cloud.
- Test data generation on the Cloud.
- On demand usability testing using Cloud.
- Mobile handset testing
- Blogging
- Followed by presentation around the Security and Availability concerns around Cloud and some perspectives around that.
Question and Answers:
Overall it went good and flawless to an extent. Post presentation there were quite a few offline questions. One of the Intriguing questions from a participant was- "When i use Virtual test environment, i am not seeing some of issues that my customers are seeing on the Physical hardware". Upon Investigation, it appeared that the code base of application under test was more than a decade old and that might have some dependency on the results that were seen/not seen. However, i will be exploring this question in a bit more detail and would like to blog about the same in the near future.
Other Interesting Sessions:
I liked the Panel talk involving Quality heads of Companies such as Tata Global Beverages, BIOCON, Mahindra Reva Electric Vehicles, and moderated by T.Ashok from STAG Software. This was one of the unique session in which people from Non-Software fields discussed their experiences around Testing as it relates to their Industries. I am surprised (having attended many conferences) nobody thought of engaging such a panel in the past. The discussions were enriching and most of the non-software people agreed to the fact that there is much more focus on prevention than defect detection as is the case with most of Software Testing. Also, there was stringent focus on Design and testing the Design itself. Reliability testing takes altogether a new dimension as the representative from Reva Electric car rightly said- "Software can afford to crash and hang but cars cant"
I quite liked the session "Software Fault Patterns – A Narrative from the Operation Theatre " by Dr. Sukanta Bhatt. His presentation style is unique and hilarious. Again, he stressed the importance of Accuracy, UI design, and understanding the perspective of On field Doctors. He really made audience laugh and drove home the point that Software Testing career cannot be considered complete unless one has a real life experience of testing a Medical Software. Period.
Overall a great experience. Time permitting, i really wish to record the video of the presentation and put in on Youtube sometime.
I got the invitation to present at Silicon India's SofTec 2011 Software Testing Conference and completed my presentation yesterday. The stage was not new for me having presented in 2010 edition as well(on the same stage). When i got the call to present at the conference, i had in mind to speak about Cloud phenomenon for some reasons-
- In 2010, i presented on "Globalization Testing- Getting your Software World Ready". This year it had to be different.
- Cloud is more of an in-phenomenon and more relevant to talk about in the Conference.
- I had developed a fascination for the similar topic earlier this year and thought i could build upon that.
Summary of my talk:
So my Topic for SofTec 2011 was- "The Emergence of Cloud Computing and Software Testing- A Perspective". I primarily talked broadly on the following areas-
- Importance of Learning by Association.
- Associating the origin of Cloud computing with the Advent of Electricity.
- Basics of Cloud computing including Grid and Utility computing.
- Covering the business models around Cloud Computing- including IaaS, PaaS, SaaS.
- The inter-relation between Cloud Computing and Software Testing.
- What are the different ways Testing could be moved on to the cloud- Public cloud, Private Cloud, Hybrid clouds.
- Explaining the Fundamental shift from the testers owning Physical machines to test Software applications traditionally to now testers owning raw computing power. All this made possible with Virtualization.
- How could Cloud's elasticity be used effectively in Software testing ?
- How does cloud amount to Green Software Testing ?
- How can Snapshot features help the Software Testing ?
- How is the Virtual lab automation make Software Testing effective ?
- Then i discussed some Live examples primarily featuring-
- Test Management on the Cloud.
- Test data generation on the Cloud.
- On demand usability testing using Cloud.
- Mobile handset testing
- Blogging
- Followed by presentation around the Security and Availability concerns around Cloud and some perspectives around that.
Question and Answers:
Overall it went good and flawless to an extent. Post presentation there were quite a few offline questions. One of the Intriguing questions from a participant was- "When i use Virtual test environment, i am not seeing some of issues that my customers are seeing on the Physical hardware". Upon Investigation, it appeared that the code base of application under test was more than a decade old and that might have some dependency on the results that were seen/not seen. However, i will be exploring this question in a bit more detail and would like to blog about the same in the near future.
Other Interesting Sessions:
I liked the Panel talk involving Quality heads of Companies such as Tata Global Beverages, BIOCON, Mahindra Reva Electric Vehicles, and moderated by T.Ashok from STAG Software. This was one of the unique session in which people from Non-Software fields discussed their experiences around Testing as it relates to their Industries. I am surprised (having attended many conferences) nobody thought of engaging such a panel in the past. The discussions were enriching and most of the non-software people agreed to the fact that there is much more focus on prevention than defect detection as is the case with most of Software Testing. Also, there was stringent focus on Design and testing the Design itself. Reliability testing takes altogether a new dimension as the representative from Reva Electric car rightly said- "Software can afford to crash and hang but cars cant"
I quite liked the session "Software Fault Patterns – A Narrative from the Operation Theatre " by Dr. Sukanta Bhatt. His presentation style is unique and hilarious. Again, he stressed the importance of Accuracy, UI design, and understanding the perspective of On field Doctors. He really made audience laugh and drove home the point that Software Testing career cannot be considered complete unless one has a real life experience of testing a Medical Software. Period.
Overall a great experience. Time permitting, i really wish to record the video of the presentation and put in on Youtube sometime.
Monday, May 16, 2011
I will be back
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.
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.
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 ?
Subscribe to:
Posts (Atom)
