Wake up, Shake up and then test...

You can't master testing unless you reinvent it

This is how one of the lessons of the book "Lessons learned in Software Testing" goes. And this statement is so very true. Just adding to the above statement based on my experience-

You can't master testing unless you reinvent it and you can't reinvent testing unless you reinvent your thinking

Software Testing is a job that requires extensive thinking. And unlike many people's beliefs - thinking is a skill, something that can be acquired and sharpened always. In order to test an application efficiently, we do need to sharpen our thinking skills and mental routine and apply the renewed thinking to test an application. There are many credible ways by which thinking can be enhanced or sharpened. Some ways include mastering Edward de bono's better thinking principles, studying epistemology, understanding cognitive psychology etc. These are the techniques and studies which can be learnt and applied to enhance one's thinking skills and in turn the efficiency of a tester.

Recently, while reading a book- "Instant Analysis" by David J. Lieberman- i came across a different thought line on how our physical routines can affect our thinking and even our thinking outputs. Life does get monotonous, mechanical and predictable as we move on. For example, as the day passes notice certain day-to-day behaviors-

- Once you get into office, look around your desk- you would probably find that picture on the same place as it has been for months or years, same place for a to-do list, same place where you keep your laptop and work.
- Look at the pattern in which you decide your password. Its probably following the same sequence for as long as you can remember.
- Are you in a habit of keeping your desk or your PC desktop unorganized and cluttered ?

There can be a numerous such examples (based on one’s life style) that you can relate to just by looking around your physical world. Probably the list of things that you have been doing the same way for a long time just because they have been part of your habit, something your subconscious mind drives you to do without you realizing it. As Dr. David puts it-
"You see something and you instantly go into a conditioned state associated with your environment."

The idea here is to be aware of such sub-conscious habits and behavior patterns and take a step forward to break the pattern by shaking up your daily routine. By doing so, it helps to jolt your usual thought patterns and open up new avenues of thinking. And it does work! I have tried this in my daily life and this kind of pattern interrupting exercises actually help to open new pathways in your brain eventually affecting the thinking outputs. Here is what needs to be done -

- Based on your life style, make a note of different aspects of your daily routine.
- Slight change any of the ordinary behaviors (e.g. organize your desk, move the stuff and rearrange, slightly change the order of things you do when you reach office etc.)
- Do things that you usually dont do and vice versa (by slightly adjusting the behavior)

Have more awareness of self and age-old pattern and eventually breaking them introduces you to a new thought process. A thought process that has the potential to bring in new ideas to your work, help you in coming up with new ways of testing.
As Software Testing is a job that requires immense thinking abilities, these slight adjustments to the physical routine has a potential to go a long way to bring in necessary change and freshness in a way you have been approaching testing.
I am quite keen to experiment more with this thought while testing and managing the testing in the time to come.

Uncovering Myths about Globalization Testing- 4

Myth 11: Localization - means Localized product on a localized Operating System, Internationalization- means Localized product on English Operating System

One of the readers of my previous Globalization testing related post had commented the following-
I have always heard the below definitions for L10n and I18n:
Localization - means Localized product on a localized Operating System.
Internationalization- means Localized product on English Operating System.
Could you please clarify. As a person who has not done any such testing, I am always in doubt regarding this.

It made me realize that one of the most misunderstood aspects in the world of Software Globalization is comprehension of terms “Internationalization” and “Localization”. I too used to be having a wrong notion about these terms before I started working in this field. I think the major reason for the incorrect understanding about these terms is the lack of awareness and exposure in the field (particularly in India). Moreover, the available definitions and literature also makes it a bit hard for a person with no background in Software Globalization to fathom the basic differences in Software Internationalization and Localization. So, without delving any deeper into text book definitions of Internationalization and Localization, let me attempt to explain these terms as I have experienced while working in the Industry.

Software Globalization:
At the most basic level, Software Globalization= Software Internationalization + Software Localization.
Simply explained, the term “Globalization” relates to all the activities that are required to conceptualize, design, develop, test, maintain and probably sell and market the product in supported International geographies. Globalization is a superset term which constitutes Software Internationalization and Software Localization. Whenever someone uses the term “Globalization testing”, it primarily includes testing of all the changes that needs to be included into the Software to make it fit to be developed in different languages or technically put- Internationalize it. We will look deeper into the phrase “testing of all the changes” (used in previous sentence) in the following points.

What is Software Internationalization ?:
As we now know, one of the activities that come under Software Globalization umbrella is “Internationalization”. Lets forget about Internationalization testing for a moment and focus our thoughts on “What is Internationalization ?”. The primary thing to keep in mind when we talk about Internationalization is that- Internationalization is a Software Design and Development activity.
One question that comes to mind at this point is- If Internationalization is a Software Design and Development activity then how is it different from Design and Development of base Software product (By base Software product I mean that English language Software assuming the Software gets developed in English language first and then into other languages). Base Software development includes development of all the features and functionalities of the application e.g. Taking an example of Windows Notepad application, Base product development includes- writing code for functionality of File/New, Open, Save, Save-as menu, Edit menu and so on. So base product development ensure that the basic features that a product offers are in place.
So, where does Internationalization come into Picture here ?
When we talk of selling the Software in International market, broadly 2 types of requirements are taken in to consideration
a) The features and functionalities that the base language product offers should be available in International version of the Software (there can of course be some exception e.g. say German market does not need a feature that may be a in demand in US market)
b) International requirements i.e. requirements pertaining to the locale in which the Software is being sold. Consider the following examples-
• For a software being developed for Arabic market, it should provide a provision to write in a Left to Right fashion (as against English- Right to left).
• Traditional Chinese is written from Top to bottom so the Software product being sold in that market should have UI supporting text from Top to bottom.
• For a software being sold in International market, one of the primary requirements is that it should support the character sets for that particular language e.g. German, Japanese text etc. If the product does not support the local character sets, it cannot be sold in those markets as the consumers will invariably reject the Software whose UI is translated but it does not support data entry in translated language.
• If a product supports multiple languages then one of the possible Internationalization feature is ability to changing the language at a run time.
• One of the important Internationalization requirements is that the core binaries of product (having code for product’s core features) should not change when Software is internationalized in different languages i.e. same code base should be used for a Software in English, German, Japanese languages etc. One of the aims of Internationalization is achieve the same code base across all the languages. If the code base differs as we move from one language to another, then the overall cost of product development and testing becomes multifold.
• And there can be many more such requirements.
And relooking at above 2 broad classifications of requirements, the requirement b) comes under scope of Internationalization i.e. these requirements are covered as a part of Internationalization design and development. So an international Software leverages the features developed in base language (requirement a) above) and in addition includes varios International requirements.
I hope the above examples provides some insights into what Design and Development activities comes under the scope of Internationalization, why is Internationalization important and how is Internationalization different from base product development.

What is Software Localization ?
So, where does Software Localization comes into picture in Software Globalization ? As mentioned earlier- Software Localization is one of the activities of Software Globalization. In simple terms, Localization deals with presentation aspects of International Software. So if I ask what is the basic difference one observes after having a look at German language User Interface as against an English Language user Interface ? The obvious answer is “Language”. So, one of the prime tasks of Software Localization is translation of various User Interface elements in target language. Remember- we are not talking about Localization testing here, its just an plain explanation of term “Software Localization”.

Who does what ?
Software Internationalization is carried out by either the base product developers who are well versed with Internationalization concepts or it is done by the Software Internationalization experts. Internationalization is indeed an experts’ job.
Translation activity in Software Localization is carried out by the language experts preferably by the people who are the native speakers of the language (usually not the people who have learnt the target language as a second language).

Where does Software Internationalization and Software Localization meet ?
In an ideal scenario, Software Internationalization is done when the base product development is being done i.e. Internationalization requirements are built into the Software when the base product is being developed. An important point here is that Internationalization is built into the Software much before it is actually translated. This is an important concept to understand.
The translation work starts only after the base product User Interface is finalized i.e. no more changes are planned to the User Interface. After the User Interface Freeze, the language experts get the English text, they work to translate the same and after the entire translation is done , the translated resources files are included in the product.

Keep watching this space, there’s still a lot more to come on Software Globalization!

Uncovering Myths about Globalization testing-3

Continuing from my previous post , here are a few more myths about Globalization testing uncovered.

Myth 8: If a test case works fine in French language, it will work fine in German language as well

This one is little tricky to explain but it is definitely a myth. Some thoughts around this-
1. Lets consider a case of application being Internationalized for the first time. And assume that the application is going to support multiple languages. There are several factors that need to be kept in mind before defining the testing scope-
a. Check with the developer if there are any changes in application binaries between the languages. If the developer confirms the binaries are the same across all the languages, then get the information about what changes have been done to the product from the Internationalization perspective across all the languages. Also, consider the changes that have been done to the product while building the product or creating the executables. If the product is using the same binaries across all the languages AND there are no changes to the product from the Internationalization perspective AND there are no changes done to build the product AND there are no other changes in the application between languages, then one may confidently say that "If a test case works fine in one language, it will work fine in other language as well. "
In practical scenario, the answer to different if’s in previous sentence are usually not known or is not known to an extent to help you make a right decision. In such a case, to assume that a test case will behave the same way across all the languages may turn out to me quite risky.
b. Continuing with the previous point, another important point is the skill of a developer performing the Internationalization changes to the product. Designing and developing a product from I18N perspective is a specialized skill. More often you will see that the developer who does core application development may not be fully well versed with I18N concepts. If this is the case, as a tester one should better take special care when deciding to omit any test case.
c. If the application is Internationalized for the first time, then the testing should be as thorough as possible as chances for mistakes are high.
2. On the other hand, for the applications that have been through multiple Internationalization releases i.e. already support multiple languages are generally going to be more stable and the variations of test results across the languages would majorly depend upon the changes that has gone into the Software between previous releases and the current one.
3. In order to perform the Risk based testing across the different languages that are supported, one thought-line that is usually applied is that all the Single byte languages such as French, Spanish, German usually tend to behave the same way and the testing can be equally distributed across all these languages.
A special care must be taken to handle the testing of multi-byte languages such as Japanese, Simplified Chinese, Traditional Chinese etc. majorly because of the different character-sets that these languages deal with.

Myth 9: If the Foreign text input in application text fields work fine by using the Soft keys, then it means the data input through respective Foreign language key board would also work fine.

Soft keys are the "Soft" key boards layout in different languages that are provided by Windows Operating System. It can be accessed from the following locations-
- Start Menu/Programs/Accessories/Accessibility/On Screen Keyboards
- Start Menu/Programs/Accessories/System tools/Character Maps

Soft keys basically helps one enter the Foreign text without the need of an external keyboard. For majority of the testing with Foreign text, the use of Soft keys should suffice but there are a few situations that i can think of which requires one to use actual hardware-
- For some languages there are a multiple types of Keyboards (with different makes and models) available in the market. The customers of respective locales can use any of those keyboards. In such a scenarios, it is worthwhile checking at the earlier phases on what models of Keyboards are supported by the application under test and use the same for testing purposes.
- In my testing experience with Internationalized applications, i have not come across a situation where i would have found a bug in which a test scenario worked fine on Soft keyboard but not on physical keyboard but reading about other's experience here's what i found after reading the book- "Galileo Computing- Software Testing and Internationalization"
As the book states- I have seen a program in the past where foreign data was able to be entered correctly using an English keyboard on Portuguese system, so the product was shipped. However, when the program was installed by people in Brazil, who were using a Portuguese keyboard, they were not able to enter the C Celidda character(ҁ).

Though i dont know the exact reason for the above experience mentioned in the book, but this experience is a good enough indicator to not treat the tests related to entering foreign text lightly and to use the physical keyboard for different languages for testing International versions of the Software.
Always, remember- do not take chances with features related to handling the foreign text within the program. Always test it thoroughly.

Myth 10: Globalization testing doesn't require the same test setup as is required to do the Base language testing. Globalization testing can be done with a minimum test setup.

This myth came up as a result of one of the discussions i was having with Development manager of one group. This is a myth because Globalization testing too can be as setup intensive as the base language testing can be.
Remember- one of the basic purposes of Globalization testing is to ensure that the International version of the application on the respective language test setup works the same as English language version would work on English test setup. By test setup here, i mean the Operating System, Third party products, any specific hardware etc.
One cannot possibly carry out all the necessary tests if the test setup of Internationalized applications is not same as the base language test setup.

Uncovering Myths about Globalization testing -2

This post is a continuation of my previous post on the same topic and is based on the real time myths about Globalization testing as i have experienced.

Myth 4: A person who doesn't know French cannot test the French version of the Software
The fact here is that except for the testing required to do the Language verification on the User Interface and the documents, every other aspect of Globalization testing can be done by a tester who is not well versed with the language under test. In my experience, I have seen most of the Internationalization testing being done by people who are not language experts. There are a few points that come to my mind regarding this fact-
1. The User Interface of localized Software products is generally consistent with the English language User Interface. A tester first gets trained on the English version of the Software product and then switches to testing on a language specific version of Software. This way the tester is acquainted of the entire User Interface map in English language and thus knows what options is he/she clicking on a language specific build. It’s probably same as using English language say Windows XP as against German language Windows XP. The entire look and feel is the same, so a person who doesn’t know the target language still knows what actions he/she is doing.
2. The language part of testing is best done by the native speakers of that language. There is a difference between native speakers and the person who has learnt a foreign language with his/her's native language being something else. It is generally very difficult to find a person who is technically sound, an Expert in Software testing and a native language expert as well. If at all one manages to find one such person for one supported language, it may not be equally feasible to find such a person for all the supported languages. In such a scenario, the language part of Globalization testing (usually referred to as Localization testing) is the responsibility of native language expert and the Functional part of Globalization testing (referred as Internationalization testing) is done by testing Experts.
3. Having said this much, it must be understood that there will still be some situations in which a person unaware of language and testing the same may get struck especially while troubleshooting things or upon coming up with some sort of error message that requires translation. In such a scenario, the help of language experts or sometimes the freely available text translation tools is required.


Myth 5: A tester only needs to follow the test cases executed for Base language in order to thoroughly test the internationalized applications
International versions of a Software program in majority of cases have the same features and functionalities as the English version of Software. This may not be true if there is a specific feature request for a particular locale. In my experience, I have not generally come across any such instance. Going by this thought, many people new to the Globalization testing tend to believe that the test cases same as English language can be used for testing the International versions of the Software. This is not typically correct. Let me try to put things in perspective here-
1. It is true that for the sizable chunk of Globalization testing, the Base language (usually English) Functional test cases are used. The prime reason of following this approach is that one of the objectives of Globalization testing is to ensure that the localized version of Software works as reliably on localized test environment as English language product does on English language test environment.
2. However, it is very costly and inefficient to run all the English language functional test cases for all the languages being supported. Suppose a Software product supports 4 languages, if one intends to run all the English language test cases for all the languages, then the overall effort would be 400% more. In a usual resource crunch scenario in Software releases, spending this much effort is impractical and often not required. And if at all this much effort is spent, then the Simship is not possible ("Simship" is releasing all the supported languages for a software product on the same date). In order to deal with such a situation, the English test cases are usually striped across languages meaning- running 25% of test cases on say French language, 25% each on say German, Spanish and Italian). The word of caution before agreeing to go for such an approach is basically understanding the code changes that have happened across different languages. Usually, if the product is properly Internationalized- there would be a single code base catering to all the supported languages. If this is the case, there won’t be much risk in basing the testing by dividing the test cases across the languages.
3. However, it is equally untrue that Globalization testing constitutes "just" executing the English language test cases on localized languages. Apart of executing English based test cases on the localized test setup, there is a great deal of testing that needs to be done to test the cultural requirements/International requirements of a particular language under test e.g. If you are testing an German language Software, one needs to focus on German keyboard and testing using German text, test for German date/time format, number formats, Sorting order, printer settings and a list of related things. Usually one ends up testing whole lot of additional things.

Myth 6: There is no scope of exploratory testing while testing internationalized applications
This myth has it's root in the previous myth- A tester only needs to follow the test cases executed for Base language in order to thoroughly test the Internationalized applications
There are quite a few challenges associated with the Globalization testing. Let me summarize a few of these-

1. The localized version of Software works as reliably on localized test environment as English language product does on English language test environment.
2. One of the major activities for Globalization testing is to ensure that the testing touches entire User Interface at least once. In absence of a good methodology to exactly figure out whether the entire UI is covered, this is usually a big challenge.
3. The cultural changes that need to be tested when one switches from one language to other. E.g. the UI layout, Date/time, sorting etc. would be entirely different in German language as compared to say Arabic language.

So considering these challenges and many such other challenges, the testing approach that is defined for Globalization testing may not always be robust enough to find all major defects. In such a scenario, Exploratory testing plays a very important role in uncovering the defects timely.
I have seen James' Bach's Session based Test management philosophy being successfully used to uncover many hidden Internationalization bugs.


Myth 7: The language verification of User Interface can be done by comparing the text on screen with translation outputs of any freely available Online translator.
For all the professionally developed International version of Software, the translation of text is carried out by Language experts. Couple of reasons for this-

1. The Language experts being the native speakers of the language are the best judges as to what is appropriate text for the context in which a message/User Interface element is being displayed. It is a real possibility that a Foreign customer may get annoyed if the text is not localized appropriately. Just think of your case, if you are using any Software product in your native language and some text is not localized properly, it would for sure cause for discomfort.
2. Using freely available Online translators may be useful for doing some sort of troubleshooting if you are unaware of language under test. But it is definitely not advisable to log bugs by taking Online translators as Oracle. First of all, the translator software may not be accurate for your context. Secondly, if you still ask the language expert to fix the bug based on the output of online translators, it is highly likely that you may end up annoying the language expert who translated the text for your application.

Watch out this space again till more myths get uncovered!

Uncovering Myths about Globalization testing -1

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!

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 ?

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 ?