In continuation with one of my previous posts , I am sharing some of my experiences with Globalization testing.
Software Globalization (abbreviated as G11n), simply put is a combination of 2 activities- Internationalization and Localization
Internationalization is planning and implementing products and services so that they can easily be localized for specific languages and cultures. So for any product to be successfully localized in to different languages, it is imperative that it has to be internationalized properly. Internationalization is abbreviated as I18n.
Localization is the aspect of development and testing relating to the translation of software and its presentation to the end user. Localization is abbreviated as L10n.
The extent and the quality of Internationalization and Localization are tested by means of Globalization (G11n) testing. G11n testing is a specialized field in itself and it requires specific skills and expertise to be successful at this form of testing. Because of surface level similarity this testing has with Functional testing, it is often wrongly compared leading to false conclusions. In this write-up, I intend to uncover some of the common myths around the G11n testing.
Myth 1: G11n testing is not technical enough
This is a myth because it is more based on Ignorance rather than a thoughtful observation. As G11n testing is a separate form of testing altogether, there is a lot of scope of learning new and specific technologies. Organizations which are serious about developing and selling the products for an International market usually have a separate group which takes care of the Globalization aspects of the product. A person testing internationalized version of the Software needs to be detailed in his knowledge in the following areas-
- An I18N tester needs to have to have an in-depth knowledge of features and functionalities of the application under test. He/she needs to understand the product under test as well as Functional tester does.
- An I18N tester needs to be well versed with the technical concepts of Internationalization such as Single base binary, Unicode, Multi-lingual support, different encoding systems, code-pages, Locale awareness etc. Without the knowledge of these concepts, a tester will never be able to find good I18N bugs.
- Troubleshooting the I18N related issues requires additional skills and knowledge of the Internationalization concepts.
- An I18N tester needs to have a fair bit of knowledge about the Technical architecture of the product under test. Without this knowledge, he/she will not be able to accurately assess the impact any change in software product would have from the Internationalization perspective.
- An I18N tester is usually an interface to the Translation experts. It is very likely that the Translation experts because of the nature of their job may not be technically proficient. Usually, I18N test teams help the Translation experts in their unit testing involving complex product setups.
Apart from the purely technical knowledge needed by an I18N tester, it is imperative for a person to have knowledge about the cultural considerations for different countries including (but not limited to)- understanding the date/time formats, number formats, preferred printing options, currencies etc. This makes the job of an I18N tester even more interesting and challenging.
Myth 2: G11n testing is majorly about testing the UI
This is a myth because- to the majority of people, the translation of UI text and labels etc. are the only changes that get done when a product is internationalized.
There is no doubt to the fact that whenever an application gets localized (aka translated) to any other languages, the UI changes are the most prominent in the product. All the text/labels that were originally displayed in the base language (which are usually English), now gets shown in the translated language. Though UI changes are prominent but technically these are only one of the changes that get done as a part of Globalizing the Software. A few examples of activities involved in internationalizing the software include-
- Externalizing the UI.
- Design UI so that strings can expand.
- Ensuring that the product can support international character sets.
- Eliminating strings corruption.
- Ensuring that Regional settings are read from OS.
- Support for bidirectional text.
And many more..
A typical G11n testing cycle might have more UI issues logged than the actual functional issues depending upon the quality of Globalization but that doesn’t mean that majority of testing efforts were spent to find UI issues as there is a considerable testing effort spent to verify the other aspects of Internationalization as well.
Myth 3: G11n Testing can start only after the base product is translated
This is one of the common misconceptions for the people completely unaware of Software Globalization concepts. To give a brief background, Globalization of software happens appropriately in different phases when the base product (The English language product) is being developed. In an Ideal development scenario, the software development consideration from Internationalization perspective begins alongside with base product development. So, when the feature complete build gets released for testing, it has all the Internationalization features built-in but point to note here is that the Localization of software hasn’t happened yet. Localization of the software product usually happens after the User Interface for the base product is frozen. Before UI Freeze, the Globalization test team's focus is testing the Internationalization aspect of the product. So, the testing for Globalization starts much before the translation of the Software happens.
Watch out for more such myths being uncovered in this space!
Saturday, June 14, 2008
Sunday, June 8, 2008
Designing effective Test status reports
"You are the headlights of the project"- Sounds something familiar? Yes, it is the very first lesson of the landmark Software Testing book- "Lessons learnt in Software Testing". The intent of this lesson is simple- Testing is done to find information . This is infact the essence of testing group. The project stakeholders always rely on the results of the testing effort to get a feel of how the project is coming along. And it is this information that helps executives take important decisions about releasing and positioning the product under test in the market. That is probably one of the important reasons why organizations invest in an independent testing group.
There is no doubt that finding information is one of the premier role of the Testing group in an organization but what is equally important is how effectively the data is actually presented. I was reading an article on Metrics by Mr. L.R.V Ramanna and the below mentioned quote took my attention-
Test metrics are like corporate balance sheets. What they show is important but what they hide is vital.
So Test status, depending upon the way it’s presented- can help take Critical decisions with ease or rather than answering questions, raise more questions. Consider, a project is 2 day away from the release and the testing status report tells only about the Open defects and the defect trends and misses vital information such as Test coverage etc. may cause decisions to be made without enough considerations to the facts unless somebody raises the hidden questions
Here i am sharing some tips based on my experience on how the status reports can be made more effective.
Identify the audience of status report:
Knowing the audience who will read the report is an important exercise. More often, i have seen that the Test status reports are sent to distribution lists containing large number of people without a thought to who the recipients are. Having knowledge does not mean to know the people personally, which may not always be possible if you are working in an organization distributed world wide but it means to understand their role in the project. This always helps to anticipate the expectations people have from the status report.
It is always preferable to list the role of people receiving the status report which may be as diverse as the following-
- Product Manager
- Project Manager
- Development Manager
- Development Director
- Test Team
- Development team
- Vice President etc.
If the status reports are sent without knowing who is receiving it, then it often leads to majority of recipients ignoring the report upon receiving it and you take the blame of unnecessarily spamming their inboxes.
Anticipate what questions the recipients would have:
This step is the basis of Test status reports.
The key purpose of Test project status reports is that it answers the wide variety of status related questions that the project stakeholders might have. An effective status report would always answer the diverse questions clearly. Depending upon the phase the project is, the stakeholders have different status requirements. In an example below, i have listed a few questions that the different project stakeholders might have at Test execution phase.
Phase: Test Execution
Development Manager:
- What is the incoming bug rate ? Is the bug find rate declining or increasing?
- Which components have the most high severity bugs?
- Which components have the bugs that are blocking the testing?
etc.
Project Manager:
- Is the testing currently happening on track?
- Are there any major blockers to testing?
- Is there any risk to meeting test deliverables and milestones?
- If there are risks, what are the plans to mitigate the same?
etc.
Product Manager:
- Are there any defects that need Product Management attention?
- What is the list of deferred defects?
etc.
Test Manager:
- What is the percentage of test coverage completed?
- What is the percentage of defects found based on Test methodology- Scripted testing vs. Exploratory testing?
- What is the reason if the defects are trending up?
- What is the defect fix rate?
etc.
The above list is definitely not an exhaustive list but gives some pointers to varying status needs. There may also be overlap of questions that different stake holders needs answer for. These questions vary as the context and the project phase changes but it makes report more effective if these are anticipated in advance.
It saves a lot of time in the meetings when the status report answers the questions appropriately.
Answer each question in an objective manner:
Once the list of questions are thought of and finalized, the next step is to design the metrics. Pick up each question, assess each with the help of the data. It is important that answer to each question should be as fact based as possible. Refrain from adding emotional responses to the questions.
Position most important information at the beginning of the report:
The positioning of data in the Test status report is quite vital. Sometimes, i have observed the status report begin with all the positive information and has the risks listed somewhere at the bottom of the report. Such an organization of the report may cause oversight of important information. Effective status report should alert the recipients with any important information within one glance.
It’s always good to Summarize the status at the beginning of the report before getting into the details section.
Don’t get intimidated with mentioning the Risk items-
Test teams should not fear giving bad news. If the project is in the bad state, it should stated in a way that everyone understands the risks and the situation properly. Use forceful language if needed to pass the message properly but the language used should be professional.
Any more thoughts ?
There is no doubt that finding information is one of the premier role of the Testing group in an organization but what is equally important is how effectively the data is actually presented. I was reading an article on Metrics by Mr. L.R.V Ramanna and the below mentioned quote took my attention-
Test metrics are like corporate balance sheets. What they show is important but what they hide is vital.
So Test status, depending upon the way it’s presented- can help take Critical decisions with ease or rather than answering questions, raise more questions. Consider, a project is 2 day away from the release and the testing status report tells only about the Open defects and the defect trends and misses vital information such as Test coverage etc. may cause decisions to be made without enough considerations to the facts unless somebody raises the hidden questions
Here i am sharing some tips based on my experience on how the status reports can be made more effective.
Identify the audience of status report:
Knowing the audience who will read the report is an important exercise. More often, i have seen that the Test status reports are sent to distribution lists containing large number of people without a thought to who the recipients are. Having knowledge does not mean to know the people personally, which may not always be possible if you are working in an organization distributed world wide but it means to understand their role in the project. This always helps to anticipate the expectations people have from the status report.
It is always preferable to list the role of people receiving the status report which may be as diverse as the following-
- Product Manager
- Project Manager
- Development Manager
- Development Director
- Test Team
- Development team
- Vice President etc.
If the status reports are sent without knowing who is receiving it, then it often leads to majority of recipients ignoring the report upon receiving it and you take the blame of unnecessarily spamming their inboxes.
Anticipate what questions the recipients would have:
This step is the basis of Test status reports.
The key purpose of Test project status reports is that it answers the wide variety of status related questions that the project stakeholders might have. An effective status report would always answer the diverse questions clearly. Depending upon the phase the project is, the stakeholders have different status requirements. In an example below, i have listed a few questions that the different project stakeholders might have at Test execution phase.
Phase: Test Execution
Development Manager:
- What is the incoming bug rate ? Is the bug find rate declining or increasing?
- Which components have the most high severity bugs?
- Which components have the bugs that are blocking the testing?
etc.
Project Manager:
- Is the testing currently happening on track?
- Are there any major blockers to testing?
- Is there any risk to meeting test deliverables and milestones?
- If there are risks, what are the plans to mitigate the same?
etc.
Product Manager:
- Are there any defects that need Product Management attention?
- What is the list of deferred defects?
etc.
Test Manager:
- What is the percentage of test coverage completed?
- What is the percentage of defects found based on Test methodology- Scripted testing vs. Exploratory testing?
- What is the reason if the defects are trending up?
- What is the defect fix rate?
etc.
The above list is definitely not an exhaustive list but gives some pointers to varying status needs. There may also be overlap of questions that different stake holders needs answer for. These questions vary as the context and the project phase changes but it makes report more effective if these are anticipated in advance.
It saves a lot of time in the meetings when the status report answers the questions appropriately.
Answer each question in an objective manner:
Once the list of questions are thought of and finalized, the next step is to design the metrics. Pick up each question, assess each with the help of the data. It is important that answer to each question should be as fact based as possible. Refrain from adding emotional responses to the questions.
Position most important information at the beginning of the report:
The positioning of data in the Test status report is quite vital. Sometimes, i have observed the status report begin with all the positive information and has the risks listed somewhere at the bottom of the report. Such an organization of the report may cause oversight of important information. Effective status report should alert the recipients with any important information within one glance.
It’s always good to Summarize the status at the beginning of the report before getting into the details section.
Don’t get intimidated with mentioning the Risk items-
Test teams should not fear giving bad news. If the project is in the bad state, it should stated in a way that everyone understands the risks and the situation properly. Use forceful language if needed to pass the message properly but the language used should be professional.
Any more thoughts ?
Saturday, May 3, 2008
Introversion at a work place: boon or bane?
A typical work place consists of people with different personalities.True to their differences, people at work react or behave differently to similar situations faced. This article aims at one such type of personality type i.e. Introversion. Introvert employees are different than the Extrovert employees in many different ways. Here, i present an unedited version of my article that got published in the May month of "TheSmartTechie" magazine. Happy Reading and i would really appreciate any thoughts/comments here-
Consider the following situations at a workplace
- There's an employee who prefers to work and contribute a lot behind the scenes without coming into limelight.
- In a team meeting situation, there's a discussion on the project related topic and you find an employee who's widely regarded as a proven performer and usually comes up with excellent solutions when working alone, just sits calmly in the meetings with a great deal of reluctance to speak.
- As a manager handling a large team- you notice that majority of employees blow their own horn and take credit for the good work that has been done by them but there is this employee who just presents the facts without exaggerating his role.
- In a teleconference with offshore team, while talking to a person for the first time, you notice an employee almost at a loss of words or even stumbling.
- You have this employee in your team who is considered good for nothing as he/she does not prefers to talk like others. And then when this employee speaks up on the topic of his expertise, he/she leaves everyone amazed at his depth of knowledge.
There are many such situations that happen in the work place. Of course, there can be lot of other personality aspects leading to these situations but more often this is related to Introversion. In the work place situations as mentioned above, most of the times the behavior exhibited by the Introvert employees is treated as unusual by other employees. The primary reason for such a misconception is that according to a study, the Extroverts on this planet outnumber the Introverts by the ratio of three is to one. One can appreciate this as a fact more upon looking around the work place or even in the personal lives. Extroverts, being in majority- relates well to other extroverts rather than to the Introverts.
Understanding the basic difference between Introversion and Extroversion:
In their book, “Type talk at work”- Otto Kroeger and Janet Thuesen differentiates Introversion and Extroversion as follows-
"Unlike Extroverts, who always wears their personalities on their sleeves, introverts often keep their best to themselves. With Introverts, you see only a portion of their personality. The richest and the most trusted parts of an introvert's personality are not necessarily shared with the outside world. It takes up time, trust and special circumstances for them to begin to open up." Thats the reason, as Marti Oslen Laney (a psychotherapist and author on books on Introversion) puts it- Extroverts often always get good press and Introverts are often left asking for more.
The Introverts draw their energy from their internal world of ideas and emotions whereas Extroverts gets energized by external world by socializing, meeting people, going places, doing outward bound things.
Career options for Introvert employees:
As a general perception of people outside the Software field, most of the techies are introverted given the nature of their job. That’s simply not true given the diverse nature of the jobs in the Software arena e.g. Project Management professionals, Product management, Software testing, Software development etc. Introvert employees stand fair chance to be successful in any of these diverse jobs. May be a job dealing with less people and more computer interaction suite them better but that definitely does not indicate that they cannot adapt to other jobs. Being true to their nature, Introvert employees often find themselves dealing with the situations that require them to go out of their comfort zones. The key here is to adapt.
Other common misconception is that Introvert employees cannot be good managers. Contrary to this, in my experience i have observed that introvert managers infact are better at anticipating things and understanding their employees. Again, Introvert managers have to learn to empower employees, delegate work effectively and give timely feedback as these aspects of manager’s job may not come as naturally and effortlessly to introverts as it does to extroverts. Some of the situations that typically a manager faces can be very demanding both emotionally and mentally for an Introvert so, it is important for such a person to understand his/her energy requirement to deal with a particular situation and the necessity to recharge and regroup.
This, being an Introvert does not limit an employee to be successful in chosen career path- be it Technical or Managerial as long as necessary adjustments are made to deliver what is expected of a chosen job.
Handling Introvert employees at work:
Introvert employees are often a misunderstood lot. A manager can do a lot to clear misconceptions around Introversions and get the best out of the employees. Take a look at the following instances-
- Introverts may often seems not being team player because of their quiet nature. As a manager, before labeling them as averse to team environment, take a step further to understand how they are aligned. Quietness does not always mean lack of team spirit.
- Introverts love to contribute silently without blowing their own trumpet but this should not stand in the way of them getting the appreciation they deserve. As a manager, take special effort to recognize these individuals.
- Even though an introvert employee would have best of ideas, he/she will always feel uncomfortable to present these in front of large audience. As a manager, understand the anxiety of such employee and motivate him/her to prepare hard to overcome the inherent apprehension.
- In large group situations, introvert employees usually find it hard to absorb all the information and present their opinion about the situation swiftly. This is usually treated as a lack of intelligence whereas the fact is that if a manager gives some additional time post meeting to these employees to give their inputs, you will more often be surprised at kind of valuable suggestions introvert employee comes up with.
- Introvert employees would always resist coming up to you as a manager to share their grievances. As a manager, It would always help to keep your eyes open to capture the necessary hints if such an employee is not happy with something and initiate a talk.
Introvert employees are often great at work. All that is needed from a manager is just a little care to bring the best out of them.
In common society norms, Extroversion is considered as good and Introversion as bad. Introversion should never be treated as inability of an individual, its just a preference that gets formed with some people as they grow up in their life. Infact, in most of the cases Introvert employees possess some extroverted qualities and vice versa. Having the apt understanding of these preferences and being sensitive towards the basic differences in these two types of individuals can help a big way in resolving work place related conflicts. Though most of the organizations claim to treat all their employees equally, it would require quite a change in perception to treat Introversion and Extroversion with equal dignity at the work place.
Are we ready for this change ?
Consider the following situations at a workplace
- There's an employee who prefers to work and contribute a lot behind the scenes without coming into limelight.
- In a team meeting situation, there's a discussion on the project related topic and you find an employee who's widely regarded as a proven performer and usually comes up with excellent solutions when working alone, just sits calmly in the meetings with a great deal of reluctance to speak.
- As a manager handling a large team- you notice that majority of employees blow their own horn and take credit for the good work that has been done by them but there is this employee who just presents the facts without exaggerating his role.
- In a teleconference with offshore team, while talking to a person for the first time, you notice an employee almost at a loss of words or even stumbling.
- You have this employee in your team who is considered good for nothing as he/she does not prefers to talk like others. And then when this employee speaks up on the topic of his expertise, he/she leaves everyone amazed at his depth of knowledge.
There are many such situations that happen in the work place. Of course, there can be lot of other personality aspects leading to these situations but more often this is related to Introversion. In the work place situations as mentioned above, most of the times the behavior exhibited by the Introvert employees is treated as unusual by other employees. The primary reason for such a misconception is that according to a study, the Extroverts on this planet outnumber the Introverts by the ratio of three is to one. One can appreciate this as a fact more upon looking around the work place or even in the personal lives. Extroverts, being in majority- relates well to other extroverts rather than to the Introverts.
Understanding the basic difference between Introversion and Extroversion:
In their book, “Type talk at work”- Otto Kroeger and Janet Thuesen differentiates Introversion and Extroversion as follows-
"Unlike Extroverts, who always wears their personalities on their sleeves, introverts often keep their best to themselves. With Introverts, you see only a portion of their personality. The richest and the most trusted parts of an introvert's personality are not necessarily shared with the outside world. It takes up time, trust and special circumstances for them to begin to open up." Thats the reason, as Marti Oslen Laney (a psychotherapist and author on books on Introversion) puts it- Extroverts often always get good press and Introverts are often left asking for more.
The Introverts draw their energy from their internal world of ideas and emotions whereas Extroverts gets energized by external world by socializing, meeting people, going places, doing outward bound things.
Career options for Introvert employees:
As a general perception of people outside the Software field, most of the techies are introverted given the nature of their job. That’s simply not true given the diverse nature of the jobs in the Software arena e.g. Project Management professionals, Product management, Software testing, Software development etc. Introvert employees stand fair chance to be successful in any of these diverse jobs. May be a job dealing with less people and more computer interaction suite them better but that definitely does not indicate that they cannot adapt to other jobs. Being true to their nature, Introvert employees often find themselves dealing with the situations that require them to go out of their comfort zones. The key here is to adapt.
Other common misconception is that Introvert employees cannot be good managers. Contrary to this, in my experience i have observed that introvert managers infact are better at anticipating things and understanding their employees. Again, Introvert managers have to learn to empower employees, delegate work effectively and give timely feedback as these aspects of manager’s job may not come as naturally and effortlessly to introverts as it does to extroverts. Some of the situations that typically a manager faces can be very demanding both emotionally and mentally for an Introvert so, it is important for such a person to understand his/her energy requirement to deal with a particular situation and the necessity to recharge and regroup.
This, being an Introvert does not limit an employee to be successful in chosen career path- be it Technical or Managerial as long as necessary adjustments are made to deliver what is expected of a chosen job.
Handling Introvert employees at work:
Introvert employees are often a misunderstood lot. A manager can do a lot to clear misconceptions around Introversions and get the best out of the employees. Take a look at the following instances-
- Introverts may often seems not being team player because of their quiet nature. As a manager, before labeling them as averse to team environment, take a step further to understand how they are aligned. Quietness does not always mean lack of team spirit.
- Introverts love to contribute silently without blowing their own trumpet but this should not stand in the way of them getting the appreciation they deserve. As a manager, take special effort to recognize these individuals.
- Even though an introvert employee would have best of ideas, he/she will always feel uncomfortable to present these in front of large audience. As a manager, understand the anxiety of such employee and motivate him/her to prepare hard to overcome the inherent apprehension.
- In large group situations, introvert employees usually find it hard to absorb all the information and present their opinion about the situation swiftly. This is usually treated as a lack of intelligence whereas the fact is that if a manager gives some additional time post meeting to these employees to give their inputs, you will more often be surprised at kind of valuable suggestions introvert employee comes up with.
- Introvert employees would always resist coming up to you as a manager to share their grievances. As a manager, It would always help to keep your eyes open to capture the necessary hints if such an employee is not happy with something and initiate a talk.
Introvert employees are often great at work. All that is needed from a manager is just a little care to bring the best out of them.
In common society norms, Extroversion is considered as good and Introversion as bad. Introversion should never be treated as inability of an individual, its just a preference that gets formed with some people as they grow up in their life. Infact, in most of the cases Introvert employees possess some extroverted qualities and vice versa. Having the apt understanding of these preferences and being sensitive towards the basic differences in these two types of individuals can help a big way in resolving work place related conflicts. Though most of the organizations claim to treat all their employees equally, it would require quite a change in perception to treat Introversion and Extroversion with equal dignity at the work place.
Are we ready for this change ?
Sunday, March 30, 2008
All you wanted to know about “Tester Tested”….
Sometime back, i had been introduced to Mr. Pradeep Soundararajan. He is one person I know who is intensely passionate about his profession i.e. Software testing and this is pretty much evident by just having a look at his blog on Software testing. It is quite easily one of the successful blogs on Software testing and each and every paragraph of his posts will give an idea on how much he loves his profession. To add to this having a look at his 2007 achievements , one will get a fair idea about his intensity and single-mindedness to achieve what he has set for himself.
In one of my email conversations with him, i asked him to share his handwriting with me. My purpose of asking him about the same was to gain more insights into personality of a person who is so passionate about his profession and as a part of larger objective it was to help me in my interest to understand the correlation between Software Testing and the science of handwriting analysis. He gracefully agreed to share with me and then started my yet another journey to deep dive and understand his personality by the stokes of his pen.
I had shared my analysis with Pradeep and he seemed to agree with all the findings. In this post though, i would like to share those aspects of his personality that has helped him be so good at testing. Here are a few snippets from his overall analysis. (Please remember that the text that follows is only on the basis of Pradeep's handwriting and its not diluted with anything that i know of him by little interaction I had with him over email)
In one of my email conversations with him, i asked him to share his handwriting with me. My purpose of asking him about the same was to gain more insights into personality of a person who is so passionate about his profession and as a part of larger objective it was to help me in my interest to understand the correlation between Software Testing and the science of handwriting analysis. He gracefully agreed to share with me and then started my yet another journey to deep dive and understand his personality by the stokes of his pen.
I had shared my analysis with Pradeep and he seemed to agree with all the findings. In this post though, i would like to share those aspects of his personality that has helped him be so good at testing. Here are a few snippets from his overall analysis. (Please remember that the text that follows is only on the basis of Pradeep's handwriting and its not diluted with anything that i know of him by little interaction I had with him over email)
Analytical and Investigative Thinker:
Pradeep is having analytical thinking pattern in his personality. Being analytical has nothing to do with speed at which one processes information- Instead being analytical deals with how one processes information. He interprets all the facts by separating them, breaking them down, and organizing them from a critical point of view. He has a strong reasoning ability. He also has the tendency to be investigative in his thinking approach.
Such a thinking pattern is ideal for Software testing as it helps the tester to think about all the facts and possibility and then get to an informed decision about a defect or any other work situation and can further help in effectively troubleshooting issues on own. Being Investigative helps a tester to carry out the Exploratory testing effectively.
Fluidity of thoughts:
Pradeep possess a great deal of Fluidity of thoughts. Fluidity of thoughts denotes the ability of a person to move from one thought to other or from one thought pattern to another with ease. With the help of this trait, he has the ability to write or express your ideas with graceful fluidity. This in turn helps him take people along with him when he conveys something- a sure-shot sign of a good speaker and writer.
Being effectively able to communicate what is intended is one of the key requirements of being an good tester. One can imagine a situation of a tester who is very good at finding bugs but when it comes to communicating bugs, he/she fumbles. Such a person will have a huge difficulty in advocating the bug. With the fluidity of thoughts comes effective communication, which distinguishes an average tester from a great one.
Planning:
Pradeep is practical person whose goals are planned. He has the need to see end of the project at the beginning (before the start).Everything is mapped out- the entire route he is going to take- even if he is just going across town. He plans everything in advance and finds joy in anticipation.
Effective testers are good a planning and organizing things. Imagine a state of tester who starts his/her day or a project without any goal in mind. It is definite that such a person is going to lose his way in between. Effective testers begin with the end in mind and have a great clarity of what is expected of them.
Perfectionism:
Pradeep has a lot of structure. He spends a lot of time putting everything in place and reviews work trying to make it more precise.
Effective testers do believe in the precept- "Doing the things right the first time, every time". Testers are employed to find mistakes that developers make or the ones that happen at the early stages of project life cycle and in doing so if tester again makes a mistake- it costs organization a lot and put questions on the need of Software testing. Therefore, Perfectionism is indeed a desirable trait for Software testing profession.
Concentration:
Pradeep has a tremendous ability to concentrate and focus on project/any task that he takes. If he is concentrating and focusing very hard on some project then he tends to forget everything else around him. He has the ability to eliminate all outside noises, thoughts, interference, and ability to concentrate fully on one subject.
It goes without saying- who will be an effective tester, the one whose mind wanders and keeps jumping from one focus area to other or the one who focuses intensely on task at hand ?
As I talked briefly about the strong co-relation between the science of handwriting analysis and Software profession in one of my previous posts , this analysis goes a step further in proving the same.
Thanks very much Pradeep for helping me out with this activity.
Friday, February 15, 2008
Managing Software Personnel by the Stroke of the pen
Wishing all of you a rather delayed Happy New Year! After being offline from my blog for quite some time, here I am- Refreshed and Recharged.
I would like to begin the New Year with a post on a subject that is quite close to my heart. I have been passionate about the science of Graphology (Handwriting Analysis) and hold a professional qualification in the same. Over a period of last few years, I have found out an interesting co-relation or rather a very powerful way in which the science of Graphology helps in the day-to-day life as a Software tester, lead and a manager. I am hereby posting an un-edited version of my article that recently got published in the print and the web version of “TheSmartTechie” magazine in the month of Feb 2008.
Introduction:
“Factual Approach to decision making”- This principle is an integral part of Quality Management System offered by ISO 9001: 2000, any TQM recognition award such as Malcom Baldrige National Quality Award or a Quality initiative like Six Sigma.
It can be concluded from the above principle that effective organizations involve decision making based on analysis of data and information. In above context, the “Factual approach to decision making” principle mostly deals with decisions about products, processes, sales, profits etc. as there are proven statistical techniques that aid decision making in these areas.
An area that is often neglected while considering data driven decision making is the one involving human related decisions.
Every Leader, Manager or Supervisor in Software arena has a responsibility of human resources in addition to the successful launch of product and processes. Further, in Software field, every leadership, Managerial position requires an individual to possess certain capabilities of a Human Resource Manager because people in these positions are involved in important human related decisions such as Selection of right candidate for the job, Ideal team formation, Ideal resource and work Allocation etc. It is often noticed that such decisions are made out of gut feel and intuition without effectively considering the personality traits an individual possesses. This can lead to wrong human related decisions being taken and that eventually affects goals of team, productivity, Return of Investment from a particular team. Thus, there’s always a need of more realistic approach to decision making in human related areas.
Graphology is one such tool that accurately reveals one’s personality traits. Graphology is a scientific method of identifying, evaluating, and understanding a person's personality via the strokes and patterns revealed by a person’s handwriting. Handwriting is a visual representation of one’s thought process. Consider the following situations-
Case study 1- Hiring the right candidate:
As a Manager of the Software group, you intend to hire Engineers with diverse Technical skill sets. As a general Interview process that is followed in most of the organizations, the Technical skills gets evaluated by series of Interviews by experts and practical tests would give fairly accurate insights into candidate’s technical competencies. Every job requires an applicant to posses certain soft skills that ultimately plays an important part in success or failure of an individual in the profession. E.g. a Software Developer, in addition to strong technical skills, would require soft skills such as Analytical, problem solving skills, creative in approach etc. On the other hand, a Software tester might require skills such as Good attention to details, persistence, Organizational ability etc. Importantly for the organization hiring an individual, adequate time should be spent evaluating these skills in the candidate along with the technical skills. The usual way this is done in most of the organization is at the tail-end of the Interview process when an experienced manager or an HR manager asks the questions. The whole method of evaluating the soft skills of an individual sometimes turns out to be more a subjective exercise. How can Graphology help here? With the help of Graphology, one can get to know a lot of personality traits about an individual even without meeting him/her once just by having a look at the handwriting. It would definitely be unfair here to make hiring decisions simply on the basis of candidate’s handwriting but this powerful medium can be used to ask right questions to candidate in the Interview thereby helping to bring out the necessary personality information and making more informed decisions E.g. by means of handwriting one can easily know about the Thinking Patterns of a person. A Software Developer may require Comprehensive Thinking ability for most part of his job whereas a Software Tester involved in manual testing would do well with Cumulative thinking ability. Having this knowledge before-hand, the Interviewer can ask right questions to judge the Thinking patterns in an individual.
Case study 2- Relaying the right feedback:
Feedback sessions or a One-on-One meeting between Employee and Manager is one of the most important conversations that eventually defines the success or failure of Employee-Manager relationship. Of the many traits that Graphology helps one know is an individual’s Sensitiveness to Criticism. The people who are sensitive to criticism do not always take feedback in right way as they become quite defensive during such sessions. Knowing this information in advance through Graphology can help a Manager handle feedback sessions more effectively.
Conveying an employee what he needs to improve upon should obviously be based on the facts but the role of Manager does not end there. It is equally important for the Manager to help the employee improve upon a certain aspect under discussion. Having accurate understanding of employee’s personality traits helps the Manager drive the necessary improvements in an objective and effective manner. This is where Graphology can be of immense help.
Likewise there are innumerable number of situations where knowing the personality traits of a person accurately before-hand can add enormous value. Graphology is indeed a useful tool that helps achieve exactly the same. I am sure by this time you might already have a lot of questions about credibility and working of the science of Graphology. Let me try to address some of these-
How does Graphology work?
Handwriting is instantaneous photograph of your mind. Your nervous system acts as a wire from brain to hand. Your muscles are coordinated in a more or less writing movement. It begins with a thought in your brain, which is transmitted to central nervous system and then to your hand and fingers, the latter of which are only the vehicles that put in writing.
Handwriting is driven by brain and since hands are the natural vehicles to write something, it is called as “Handwriting”.
Does Graphology accurately reveal one’s personality characteristics?
Graphology does not work on intuition or guess work- it is a science. The accuracy of this science in revealing the personality traits depends upon the skill of the practitioner. In my experience, I have found this to be as accurate as 95%. It’s not my claim but the admittance of the people whose handwriting got analyzed.
What kinds of personality traits can be revealed using Graphology?
In general more than hundred individual personality traits can be revealed accurately using Graphology. It becomes much more when one considers precisely the impact one trait has on others.
Handwriting Analysis provides glimpses into subconscious mind, emotional responsiveness, intellect, energy, and traits such as Thinking patterns, Self esteem, ambitions, concentration, attention to details, Ego strength, Diplomacy, Enthusiasm, Fear of success, Fear of failure, Self consciousness and many more.
Is there anything one cannot tell using Handwriting?
Handwriting cannot reveal one age, gender, nationality, religion, whether writer is left-handed or right-handed and Future of an individual.
Graphology has a great potential to become a powerful tool in Managers’ toolbox. It definitely helps in better understanding of people and minimizes, to a large extent, the intuitive approach in dealing with human resources. It’s not something that is too difficult to learn as more than anything else it involves desire, passion and interest.
Welcome to the wonderful world of Graphology!
Disclaimer:
The views in this article are my personal thoughts on the subject and it does not depict these being a practice in my current or previous organization.
I would like to begin the New Year with a post on a subject that is quite close to my heart. I have been passionate about the science of Graphology (Handwriting Analysis) and hold a professional qualification in the same. Over a period of last few years, I have found out an interesting co-relation or rather a very powerful way in which the science of Graphology helps in the day-to-day life as a Software tester, lead and a manager. I am hereby posting an un-edited version of my article that recently got published in the print and the web version of “TheSmartTechie” magazine in the month of Feb 2008.
Introduction:
“Factual Approach to decision making”- This principle is an integral part of Quality Management System offered by ISO 9001: 2000, any TQM recognition award such as Malcom Baldrige National Quality Award or a Quality initiative like Six Sigma.
It can be concluded from the above principle that effective organizations involve decision making based on analysis of data and information. In above context, the “Factual approach to decision making” principle mostly deals with decisions about products, processes, sales, profits etc. as there are proven statistical techniques that aid decision making in these areas.
An area that is often neglected while considering data driven decision making is the one involving human related decisions.
Every Leader, Manager or Supervisor in Software arena has a responsibility of human resources in addition to the successful launch of product and processes. Further, in Software field, every leadership, Managerial position requires an individual to possess certain capabilities of a Human Resource Manager because people in these positions are involved in important human related decisions such as Selection of right candidate for the job, Ideal team formation, Ideal resource and work Allocation etc. It is often noticed that such decisions are made out of gut feel and intuition without effectively considering the personality traits an individual possesses. This can lead to wrong human related decisions being taken and that eventually affects goals of team, productivity, Return of Investment from a particular team. Thus, there’s always a need of more realistic approach to decision making in human related areas.
Graphology is one such tool that accurately reveals one’s personality traits. Graphology is a scientific method of identifying, evaluating, and understanding a person's personality via the strokes and patterns revealed by a person’s handwriting. Handwriting is a visual representation of one’s thought process. Consider the following situations-
Case study 1- Hiring the right candidate:
As a Manager of the Software group, you intend to hire Engineers with diverse Technical skill sets. As a general Interview process that is followed in most of the organizations, the Technical skills gets evaluated by series of Interviews by experts and practical tests would give fairly accurate insights into candidate’s technical competencies. Every job requires an applicant to posses certain soft skills that ultimately plays an important part in success or failure of an individual in the profession. E.g. a Software Developer, in addition to strong technical skills, would require soft skills such as Analytical, problem solving skills, creative in approach etc. On the other hand, a Software tester might require skills such as Good attention to details, persistence, Organizational ability etc. Importantly for the organization hiring an individual, adequate time should be spent evaluating these skills in the candidate along with the technical skills. The usual way this is done in most of the organization is at the tail-end of the Interview process when an experienced manager or an HR manager asks the questions. The whole method of evaluating the soft skills of an individual sometimes turns out to be more a subjective exercise. How can Graphology help here? With the help of Graphology, one can get to know a lot of personality traits about an individual even without meeting him/her once just by having a look at the handwriting. It would definitely be unfair here to make hiring decisions simply on the basis of candidate’s handwriting but this powerful medium can be used to ask right questions to candidate in the Interview thereby helping to bring out the necessary personality information and making more informed decisions E.g. by means of handwriting one can easily know about the Thinking Patterns of a person. A Software Developer may require Comprehensive Thinking ability for most part of his job whereas a Software Tester involved in manual testing would do well with Cumulative thinking ability. Having this knowledge before-hand, the Interviewer can ask right questions to judge the Thinking patterns in an individual.
Case study 2- Relaying the right feedback:
Feedback sessions or a One-on-One meeting between Employee and Manager is one of the most important conversations that eventually defines the success or failure of Employee-Manager relationship. Of the many traits that Graphology helps one know is an individual’s Sensitiveness to Criticism. The people who are sensitive to criticism do not always take feedback in right way as they become quite defensive during such sessions. Knowing this information in advance through Graphology can help a Manager handle feedback sessions more effectively.
Conveying an employee what he needs to improve upon should obviously be based on the facts but the role of Manager does not end there. It is equally important for the Manager to help the employee improve upon a certain aspect under discussion. Having accurate understanding of employee’s personality traits helps the Manager drive the necessary improvements in an objective and effective manner. This is where Graphology can be of immense help.
Likewise there are innumerable number of situations where knowing the personality traits of a person accurately before-hand can add enormous value. Graphology is indeed a useful tool that helps achieve exactly the same. I am sure by this time you might already have a lot of questions about credibility and working of the science of Graphology. Let me try to address some of these-
How does Graphology work?
Handwriting is instantaneous photograph of your mind. Your nervous system acts as a wire from brain to hand. Your muscles are coordinated in a more or less writing movement. It begins with a thought in your brain, which is transmitted to central nervous system and then to your hand and fingers, the latter of which are only the vehicles that put in writing.
Handwriting is driven by brain and since hands are the natural vehicles to write something, it is called as “Handwriting”.
Does Graphology accurately reveal one’s personality characteristics?
Graphology does not work on intuition or guess work- it is a science. The accuracy of this science in revealing the personality traits depends upon the skill of the practitioner. In my experience, I have found this to be as accurate as 95%. It’s not my claim but the admittance of the people whose handwriting got analyzed.
What kinds of personality traits can be revealed using Graphology?
In general more than hundred individual personality traits can be revealed accurately using Graphology. It becomes much more when one considers precisely the impact one trait has on others.
Handwriting Analysis provides glimpses into subconscious mind, emotional responsiveness, intellect, energy, and traits such as Thinking patterns, Self esteem, ambitions, concentration, attention to details, Ego strength, Diplomacy, Enthusiasm, Fear of success, Fear of failure, Self consciousness and many more.
Is there anything one cannot tell using Handwriting?
Handwriting cannot reveal one age, gender, nationality, religion, whether writer is left-handed or right-handed and Future of an individual.
Graphology has a great potential to become a powerful tool in Managers’ toolbox. It definitely helps in better understanding of people and minimizes, to a large extent, the intuitive approach in dealing with human resources. It’s not something that is too difficult to learn as more than anything else it involves desire, passion and interest.
Welcome to the wonderful world of Graphology!
Disclaimer:
The views in this article are my personal thoughts on the subject and it does not depict these being a practice in my current or previous organization.
Monday, December 24, 2007
Software Testing Certifications- Does the Industry need them?
I have been one of the testers who had got caught up with the Software Certifications trend early in my career and have also managed to "Pass" a few of them. As a general format, these certifications (provided by many private vendors) has its own Body of Knowledge for Software Testing and follow a certain format for evaluating candidates. Some of these certifications have been really popular among the testers as well as some of the big organizations. Some organizations even have these certifications as a part of their "must-have" or "good to have" skills for particular Software Testing jobs. I have even come to know of a few organizations in which one of the criteria for promoting the people to a new role is to successfully pass one or few of these certifications. All these signify the lack of standardization of education on Software testing. With no available benchmark to appropriately judge testers, the authorities providing these certifications have turned this situation to a successful business idea. These certification cost the applicants a few hundred dollars or thousands of Rupees and have thus turned out to be huge money spinners needed to sustain the profits of these organizations. Moreover, all these certifications comes with a certain Expiry date after which the candidate is required to "renew" the same (meaning spend more Dollars).If the applicant wants the additional study guide which incidentally is required to pass the certification exam, then one is required to shell hundreds of dollars again. Shelling money for a cause that helps you gain knowledge is good but over the years what I have found is that the whole process of gaining the Certification is no good than learning the skills required to pass the examination. There is a little one really gains about Software Testing in the whole process. I believe that all the people who have reached a stage in their lives to called as "Software Testing Engineer" would have already "passed" many examinations in the journey of being called the same and are smart enough to understand what is the difference between passing the exam and gaining the knowledge on the subject. In the current context, these are two different things. Being certified doesn’t not mean that one is an expert in the field. Being certified simply means that one has met all the defined criteria set by the Certification authority which incidentally is only passing the exam in most of the cases. The fact -of-the-matter is that there are many people who would struggle to define "Software Testing" or even present their perspective of Software testing even after being Certified. As the one who has worked at the ground level, there are few reasons that I could think of on why there is a mad rush among the people to be certified-
1. People perceive "being Certified" by a certain body as a means of being recognized in the profession.
2. The role models/Seniors in their respective organizations have got certain certifications, so people would want to emulate the role model.
3. Certifications are often seen as the Status Symbols. Some use it as a means to make their Signature more impressive.
4. Most organizations promote these certifications as a part of Continuous education of employees.
5. Managers put it as one of the goals for their subordinates to complete a certain certification in a review year.
6. Some junior testers would want to do the certifications to "improve" their job prospects.
7. Since most of the published jobs in the market today have a mention of some certifications as a required or desired skills, people opt for these.
8. People interested in going out of the country for the job perceive these certifications as important to have.
9. People want to learn something new, something meaningful that they can apply in their jobs.
10. Want to become experts in Software Testing.
These reasons are not cooked by me but are as result of opinion I have formed upon meeting the different people. The percentage of entire population that I have come across who wants to go for certification for the last reason (point#9, 10) is quite less.
Having being Certified myself, I can tell that personally I do have gained some good things from these certifications. Apart from knowledge, the concept of re-certification has helped me plan my career in some ways. Instead of going for exams for recertification I chose to collect the Credit points (honestly!) in different suggested areas. It really helped to broaden my horizons and helped me to take the road less travelled. But of course, one doesn't need to be certified to do such things; it can be a part of one's career planning only.
Further views on Software Testing certifications at- here
1. People perceive "being Certified" by a certain body as a means of being recognized in the profession.
2. The role models/Seniors in their respective organizations have got certain certifications, so people would want to emulate the role model.
3. Certifications are often seen as the Status Symbols. Some use it as a means to make their Signature more impressive.
4. Most organizations promote these certifications as a part of Continuous education of employees.
5. Managers put it as one of the goals for their subordinates to complete a certain certification in a review year.
6. Some junior testers would want to do the certifications to "improve" their job prospects.
7. Since most of the published jobs in the market today have a mention of some certifications as a required or desired skills, people opt for these.
8. People interested in going out of the country for the job perceive these certifications as important to have.
9. People want to learn something new, something meaningful that they can apply in their jobs.
10. Want to become experts in Software Testing.
These reasons are not cooked by me but are as result of opinion I have formed upon meeting the different people. The percentage of entire population that I have come across who wants to go for certification for the last reason (point#9, 10) is quite less.
Having being Certified myself, I can tell that personally I do have gained some good things from these certifications. Apart from knowledge, the concept of re-certification has helped me plan my career in some ways. Instead of going for exams for recertification I chose to collect the Credit points (honestly!) in different suggested areas. It really helped to broaden my horizons and helped me to take the road less travelled. But of course, one doesn't need to be certified to do such things; it can be a part of one's career planning only.
Further views on Software Testing certifications at- here
Saturday, December 1, 2007
A perspective on Lesson# 67 and 75- Bug Advocacy
Yes, I am talking here about the book that must be on every Tester's desk for myriad of reasons. It's "Lessons learnt in Software Testing" by Cem Kaner, James Bach and Bret Pettichord. I have been following this book for a while now and have experienced that this book not only provides valuable Testing lessons by super experienced trio of authors but quite a few lessons in effective book writing.
This book is all about Context driven testing approach and summarizes valuable lessons in different areas. The best way that i have found to enhance learning from this book is to read a particular lesson and then close the book and co-relate the learnt lesson to your experience or context. Here's some of my comments (based on context of my experience)-
Lesson# 67: Report Defects Promptly
Lesson# 75: Do follow-up testing on seemingly minor coding errors
Both these lessons are self-explanatory as the title suggests but a particular thing that i wanted to highlight here is that in some of the situations that i have been-it is typically challenging to get both these lessons going together in a context. Take a look at following experience snippets-
1. In the past, i have been involved in testing a networking product that had a huge dependency on setup and at the same the product had a very short release cycles. In such a product, the testing involved used to be quite setup intensive and understandably it was very time consuming. Every bug found would involve a lot of investigation which would typically take a lot of time (running into hours and sometime a whole day). And since the release cycles were short, everyone expected test team to report bugs as early as possible to give development team ample time to fix it. And to further add to this situation, the development and test teams were located in separate location geographically (separated by almost 12 hours time zone wise).In this situation, following the above lessons(#67 and #75) used to be quite challenging. Some of the challenges include-
a. If a tester is new (i.e. hasn’t yet established a reputation with the developer), then it was imperative for him/her to write complete bug report with all the investigation. If he/she fails to do so, it would result in damaging the equation with developer who sits remotely. This is a typical issue with a "faceless culture" i.e. the organization culture in which you need to team up with people who you haven’t met or seen. In such a culture, a tester would be judged solely on the basis of his work products i.e. Defect report. So a new tester would typically need more time thereby, delaying the defect logging time.
b. Even for an experienced tester in such a situation, it would take more time if he/she comes across a non reproducible kind of a bug which would take a lot more Investigation.
In such situations, we found it to be typically wise to contact developer with all the details. This has a people management challenge as It definitely means the tester work late hours to contact with offshore development team and have a talk and get into agreement to report a bug with available information and continue with further Investigation the next day.
If the development team and testing team work in the same time zone, it becomes easier to collaborate in these situations.
2. There is one more situation in which i have found the follow-up testing to be typically time consuming. This situation occurred during the Internationalization testing of a Client/Server product in 5 languages. As a part of bug information, sometimes the developers would expect the testing team to report results of the bug in all the 5 languages. What this would mean for testing team is to prepare a setup in all the languages under test and reproduce the defect 5 times and report in the bug. Being a client/server product would make preparing such a setup even more time consuming, thereby increasing the bug
logging time. It is always good in these situations (typically Internationalization testing) to get in the agreement with developer during the planning phase to understand the expectations because such a testing is indeed time consuming and would have impact on test schedule.
This book is all about Context driven testing approach and summarizes valuable lessons in different areas. The best way that i have found to enhance learning from this book is to read a particular lesson and then close the book and co-relate the learnt lesson to your experience or context. Here's some of my comments (based on context of my experience)-
Lesson# 67: Report Defects Promptly
Lesson# 75: Do follow-up testing on seemingly minor coding errors
Both these lessons are self-explanatory as the title suggests but a particular thing that i wanted to highlight here is that in some of the situations that i have been-it is typically challenging to get both these lessons going together in a context. Take a look at following experience snippets-
1. In the past, i have been involved in testing a networking product that had a huge dependency on setup and at the same the product had a very short release cycles. In such a product, the testing involved used to be quite setup intensive and understandably it was very time consuming. Every bug found would involve a lot of investigation which would typically take a lot of time (running into hours and sometime a whole day). And since the release cycles were short, everyone expected test team to report bugs as early as possible to give development team ample time to fix it. And to further add to this situation, the development and test teams were located in separate location geographically (separated by almost 12 hours time zone wise).In this situation, following the above lessons(#67 and #75) used to be quite challenging. Some of the challenges include-
a. If a tester is new (i.e. hasn’t yet established a reputation with the developer), then it was imperative for him/her to write complete bug report with all the investigation. If he/she fails to do so, it would result in damaging the equation with developer who sits remotely. This is a typical issue with a "faceless culture" i.e. the organization culture in which you need to team up with people who you haven’t met or seen. In such a culture, a tester would be judged solely on the basis of his work products i.e. Defect report. So a new tester would typically need more time thereby, delaying the defect logging time.
b. Even for an experienced tester in such a situation, it would take more time if he/she comes across a non reproducible kind of a bug which would take a lot more Investigation.
In such situations, we found it to be typically wise to contact developer with all the details. This has a people management challenge as It definitely means the tester work late hours to contact with offshore development team and have a talk and get into agreement to report a bug with available information and continue with further Investigation the next day.
If the development team and testing team work in the same time zone, it becomes easier to collaborate in these situations.
2. There is one more situation in which i have found the follow-up testing to be typically time consuming. This situation occurred during the Internationalization testing of a Client/Server product in 5 languages. As a part of bug information, sometimes the developers would expect the testing team to report results of the bug in all the 5 languages. What this would mean for testing team is to prepare a setup in all the languages under test and reproduce the defect 5 times and report in the bug. Being a client/server product would make preparing such a setup even more time consuming, thereby increasing the bug
logging time. It is always good in these situations (typically Internationalization testing) to get in the agreement with developer during the planning phase to understand the expectations because such a testing is indeed time consuming and would have impact on test schedule.
Subscribe to:
Posts (Atom)
