Its been a while that i have been writing about uncovering various myths associated with Globalization testing. While there is a lot of relevant information on Globalization testing already listed in this blog, i am inclined to think about and work towards consolidating this information and much more in the form of an ebook in the time to come. Though i dont have definitive timelines in mind at the moment, this is something i have started working towards already. For the benefits of the readers, while i work to uncover more myths around Globalization testing, i have consolidated all the previous posts on this topic below.
[Just to remind that all these myths are the real time myths that i have experienced while working on Globalization testing]
Uncovering Myths about Globalization testing -1
Myth 1: G11n testing is not technical enough
Myth 2: G11n testing is majorly about testing the UI
Myth 3: G11n Testing can start only after the base product is translated
Uncovering Myths about Globalization testing -2
Myth 4: A person who doesn't know French cannot test the French version of the Software
Myth 5: A tester only needs to follow the test cases executed for Base language in order to thoroughly test the internationalized applications
Myth 6: There is no scope of exploratory testing while testing internationalized applications
Myth 7: The language verification of User Interface can be done by comparing the text on screen with translation outputs of any freely available Online translator.
Uncovering Myths about Globalization testing -3
Myth 8: If a test case works fine in French language, it will work fine in German language as well
Myth 9: If the Foreign text input in application text fields work fine by using the Soft keys, then it means the data input through respective Foreign language key board would also work fine.
Myth 10: Globalization testing doesn't require the same test setup as is required to do the Base language testing. Globalization testing can be done with a minimum test setup.
Uncovering Myths about Globalization testing -4
Myth 11: Localization - means Localized product on a localized Operating System, Internationalization- means Localized product on English Operating System
Uncovering Myths about Globalization testing- Demystifying MUI Packs
Myth 12: Testing International applications using "Microsoft's MUI Pack" or "Localized OS installation" means one and the same thing
Uncovering Myths about Globalization testing- Input validation testing
Uncovering Myths about Globalization testing- Input validation testing 2
Myth 13- A tester can perform tests specific to text inputs for Localized applications using the similar approaches as the English language testing
Uncovering Myths...."Security Testing is from Mars and Globalization Testing is from Venus"
Myth 14- Security Testing is from Mars and Globalization testing is from Venus
Uncovering Myths about Globalization testing- English version on Localized setup
Myth 15: There is no use testing the English version of a product on Localized Operating systems
Uncovering Myths about Globalization testing- MUI Packs in Win XP and Win Vista
Myth 16: There is no difference between MUI technology being used in Win XP and Win Vista
Uncovering myths about Globalization Testing- Reusing Test Automation
Myth 17: The test scripts meant for English language automated tests cannot be reused for Internationalization testing
Hope you enjoyed going over these again. Would appreciate your comments, suggestions!
Saturday, September 26, 2009
Thursday, September 17, 2009
Key professional lessons from a Long distance run
The title of this blog may sound intriguing for a blog focused primarily on Software testing. I hope that by the time i reach the end of this post, i would have justified the inclusion of it here. For close to around 2 years now, i have quite actively taken up running. The prime reason that attracted me towards running was experiencing the feeling of reaching the finish line after persevering a long distance run. Before i started running, i used to think of it as quite a magical feeling but after crossing the finish line close to a dozen times now, it only substantiate my original perception of crossing a finish line. Its not just magical, its simply unbelievable.
I participated in Kaveri Trail Marathon last weekend. It was a 10 Km run on a day of sweltering heat and very rough, uneven terrain. While the run was pretty challenging and as i crossed various milestones, there were quite a few valuable life lessons that i learnt. Please read ahead to know more (the points below are not necessarily in order of importance)-
When your body says "Give up"- Just don’t give up. When a random thought in your mind says "You can’t do it", Just laugh it off.
The start of every run is always full of energy and optimism. The initial moments of a long distance run pass on with ease as legs and mind are fresh and usually (if it starts early in morning) the weather is favorable. It’s only after one has travelled a few kilometers especially near the half way point, the mind start playing games. It is often surrounded with casual thoughts that tend to discourage the runner from competing further. It is at this time, the body starts getting tired as well and tends to listen more to easy thoughts that prevent you from completing the run. The key here lies in being mentally strong and laugh off the negative energies and persevere till you reach the end. Infact, in my experience, one cannot reach the finish line carrying negative, confused thoughts.
Quite similarly, in the professional world, there are often the difficult projects/situations that bring an individual out of his/her comfort zone. There is always such time in these projects/situations when one starts doubting their abilities. The key here like in a marathon is to believe in yourself and shun all the negative thoughts and keep moving forward. Just remember- "When your body says "Give up"- Just don’t give up. When a random thought in your mind says "You cant do it", Just laugh it off."
Every small step towards the goal counts
The key principle in running a long distance run is that Each and every single step adds up in you completing the run successfully. Long distance runs cannot be completed in one step. Likewise in professional life, each project decomposes in to various steps that need to done right to attain the success. One cannot achieve the end goal without performing the smaller goals to perfection. Irrespective of conditions, Always put your best foot forward.
Key to success lies in staying in present
Our mind's ways are never static and even the well trained Long distance runners often face this dilemma i.e. while on the run, the mind tend to always think ahead i.e. picture of the runner reaching the Finish line starts framing up and all this makes the runner believe that he/she has already achieved the goal whereas the runner would not have even reached the half way mark. Or it may even happen that mind takes you back to thinking about ease and freshness at the start of a run. These are the biggest distractions for a runner and has a potential to distract the runner from reaching the summit. What is important in given context is to think only about the next step and not worry about the Finish line because if the next step is taken in the right direction in a right way, you are going to reach the finish line sooner or later. So, the key lies training your mind to stay in present and be there only. In the professional life, there is a great deal of importance in Staying in present. I have tried to capture the essence of it in my post- Software Testing and art of Staying in present .
If you fall down, thats not the end of the race- there is always a better option to get up and run
It happened in the most recent long distance run i took part in. It can happen in any long distance run that gets organized. People stop either because of minor accidents or because they suffer from cramps or they get tired or any other reason. Whatever may be the reason, Falling down is the part of the game. Its not an ideal world that we live in, things usually do not always go as we plan or as intended and Failures are a part of life. The idea here is to treat failures as a minor speed bumps that slow you down but not knock you off completely. Failures should be treated as learning opportunities and not the reasons to drift away from your goals. Any one who faces failure, ideally has 2 choices- either quit or continue. The ones who have strong conviction in their goals never quit. Failing faster holds the key. Remember- If you fall down, that’s not the end of the race- there is always a better option to get up and run.
Cheering your peers gives you momentum
Long distance running usually constitute of people from different backgrounds, age groups, gender etc. There can be a 70 year old participating as against a 14 year old boy or 25 year old female or anyone running alongside you. The diversity of participation makes the run even more wonderful. It happened in my recent run also. The fun lies in treating the running participants as your peers and continually cheering and encouraging them. In the entire run, there will be many phases where you face difficult time and the thought of giving up starts to play around. If in this situation, your fellow runner comes, pats your back and says "Good job", it just helps one defeat the negative emotions and just helps you regain back the momentum. In the real life also, professionally there are tough situations which may pull you down mentally and when someone acknowledge your efforts, it does gives a great sense of assurance to move forward. This act just spreads positive energy.
Taking a break and rethinking your strategy helps more than you expect
Well organized Long distance running events have the break points where in the participants can take very short water, energy breaks to refresh the participants. The refreshment time is very vital for the participants to successfully complete the run. This not only give the opportunity to the participants to hydrate themselves but also rethink strategy to complete the remaining part (thinking about speed, moving with long steps or short steps etc.). Without these breaks, it would really be hard to complete the run. Similar analogy in our professional lives- Generally people who work very hard to attain their and organization's objectives forget about the importance of taking sufficient breaks and this leaves them at a risk of a burnout leading to shortage of problem solving ideas. This situation neither helps them nor their organizations. The key here lies in realizing that you are getting in a rut and need to slow down. The focus and overall output after a well thought out break is far enriched.
I think being out of your comfort zone helps one learn quite a bit and the above write-up is a result of many such running experiences. Do share what you think and share your experiences!
I participated in Kaveri Trail Marathon last weekend. It was a 10 Km run on a day of sweltering heat and very rough, uneven terrain. While the run was pretty challenging and as i crossed various milestones, there were quite a few valuable life lessons that i learnt. Please read ahead to know more (the points below are not necessarily in order of importance)-
When your body says "Give up"- Just don’t give up. When a random thought in your mind says "You can’t do it", Just laugh it off.
The start of every run is always full of energy and optimism. The initial moments of a long distance run pass on with ease as legs and mind are fresh and usually (if it starts early in morning) the weather is favorable. It’s only after one has travelled a few kilometers especially near the half way point, the mind start playing games. It is often surrounded with casual thoughts that tend to discourage the runner from competing further. It is at this time, the body starts getting tired as well and tends to listen more to easy thoughts that prevent you from completing the run. The key here lies in being mentally strong and laugh off the negative energies and persevere till you reach the end. Infact, in my experience, one cannot reach the finish line carrying negative, confused thoughts.
Quite similarly, in the professional world, there are often the difficult projects/situations that bring an individual out of his/her comfort zone. There is always such time in these projects/situations when one starts doubting their abilities. The key here like in a marathon is to believe in yourself and shun all the negative thoughts and keep moving forward. Just remember- "When your body says "Give up"- Just don’t give up. When a random thought in your mind says "You cant do it", Just laugh it off."
Every small step towards the goal counts
The key principle in running a long distance run is that Each and every single step adds up in you completing the run successfully. Long distance runs cannot be completed in one step. Likewise in professional life, each project decomposes in to various steps that need to done right to attain the success. One cannot achieve the end goal without performing the smaller goals to perfection. Irrespective of conditions, Always put your best foot forward.
Key to success lies in staying in present
Our mind's ways are never static and even the well trained Long distance runners often face this dilemma i.e. while on the run, the mind tend to always think ahead i.e. picture of the runner reaching the Finish line starts framing up and all this makes the runner believe that he/she has already achieved the goal whereas the runner would not have even reached the half way mark. Or it may even happen that mind takes you back to thinking about ease and freshness at the start of a run. These are the biggest distractions for a runner and has a potential to distract the runner from reaching the summit. What is important in given context is to think only about the next step and not worry about the Finish line because if the next step is taken in the right direction in a right way, you are going to reach the finish line sooner or later. So, the key lies training your mind to stay in present and be there only. In the professional life, there is a great deal of importance in Staying in present. I have tried to capture the essence of it in my post- Software Testing and art of Staying in present .
If you fall down, thats not the end of the race- there is always a better option to get up and run
It happened in the most recent long distance run i took part in. It can happen in any long distance run that gets organized. People stop either because of minor accidents or because they suffer from cramps or they get tired or any other reason. Whatever may be the reason, Falling down is the part of the game. Its not an ideal world that we live in, things usually do not always go as we plan or as intended and Failures are a part of life. The idea here is to treat failures as a minor speed bumps that slow you down but not knock you off completely. Failures should be treated as learning opportunities and not the reasons to drift away from your goals. Any one who faces failure, ideally has 2 choices- either quit or continue. The ones who have strong conviction in their goals never quit. Failing faster holds the key. Remember- If you fall down, that’s not the end of the race- there is always a better option to get up and run.
Cheering your peers gives you momentum
Long distance running usually constitute of people from different backgrounds, age groups, gender etc. There can be a 70 year old participating as against a 14 year old boy or 25 year old female or anyone running alongside you. The diversity of participation makes the run even more wonderful. It happened in my recent run also. The fun lies in treating the running participants as your peers and continually cheering and encouraging them. In the entire run, there will be many phases where you face difficult time and the thought of giving up starts to play around. If in this situation, your fellow runner comes, pats your back and says "Good job", it just helps one defeat the negative emotions and just helps you regain back the momentum. In the real life also, professionally there are tough situations which may pull you down mentally and when someone acknowledge your efforts, it does gives a great sense of assurance to move forward. This act just spreads positive energy.
Taking a break and rethinking your strategy helps more than you expect
Well organized Long distance running events have the break points where in the participants can take very short water, energy breaks to refresh the participants. The refreshment time is very vital for the participants to successfully complete the run. This not only give the opportunity to the participants to hydrate themselves but also rethink strategy to complete the remaining part (thinking about speed, moving with long steps or short steps etc.). Without these breaks, it would really be hard to complete the run. Similar analogy in our professional lives- Generally people who work very hard to attain their and organization's objectives forget about the importance of taking sufficient breaks and this leaves them at a risk of a burnout leading to shortage of problem solving ideas. This situation neither helps them nor their organizations. The key here lies in realizing that you are getting in a rut and need to slow down. The focus and overall output after a well thought out break is far enriched.
I think being out of your comfort zone helps one learn quite a bit and the above write-up is a result of many such running experiences. Do share what you think and share your experiences!
Monday, September 7, 2009
Uncovering myths about Globalization Testing- Reusing Test Automation
Myth 17: The test scripts meant for English language automated tests cannot be reused for Internationalization testing
The idea of making a Software test Software without any human intervention is something that is the basis of automated testing. In my experience, i have seen fewer things that catch the fancy of management other than a well crafted Test automation strategy. I was recently studying one of the Surveys listing the success of Software projects across different Software development models. While it is interesting to notice how the project success ratio varies from different Software development methodologies but one important point to note here is that irrespective of the Software development methodology used, the success ratio is far less than maximum. Before i sound like deviating further in this post, the idea here is not to compare how different Software development methodologies fare in the real projects but certainly to draw an analogy that like the success ratio of Software projects, the success rate of Test automation projects (the lifecycle of which is quite similar to Software development projects, though on a smaller scale) is also quite far from ideal. I don’t have a real data to quote here and this inference is quite based on my observations and experience.
While the reasons of Test automation projects' failure can be plenty and its not my intention to dive deeper into those here but in this post i would be focusing on one of the main reasons automation efforts fail to scale up for International languages' testing.
To start with, It’s actually a colossal myth that the test scripts meant for English language automated tests cannot be reused for testing with International languages. I call it "colossal" because the root cause of the automated test scripts for any projects not working on International platform is no less than a design flaw or a lack of forethought at the time of scripts’ design. In my belief, the Software organizations (which went global quite late) have spent sizable costs due to rework relating to introduction of Internationalization quite late in the overall life cycle. On the similar lines as this, Test automation projects have also suffered great deal of rework because the test automation scripts were not Internationalized upfront. Let me try and elaborate what i mean here-
- For a Software product to be properly Internationalized i.e. ready to be sold in International markets- the product design should-
• be Unicode enabled i.e. the product should be able to process and display data in any language
• have all the strings externalized i.e. none of the strings that show up on User Interface should be hard coded.
• have the capability to know under what language OS is it running on i.e. if the product is installed in Japanese, the product logic should recognize that.
• Should be able to read locale specific details from underlying OS
• be robust enough so that the same code base can be used across all the languages that the product support.
- On the similar lines, for Test automation script to be fully internationalized i.e. working successfully on different languages,
• The Test tool should have a capability of being installed and running on different language OS.
• The Test tool and hence, the automated test scripts should have the capability to process the Unicode i.e. any language text and characters. This is because any testing that's done on International test environments makes use of International character sets(which is what the customers would do)
• The Test scripts should have a capability to understand under what language OS is it running.
• The Test data is not hard coded in the Test automation scripts and is Externalized to a file or any database. This helps because, once the Test scripts detects the language of the OS, the "right" language Test data files can be loaded.
• There should not be separate Test scripts per supported language but a single version of Test scripts should be capable to run on multiple languages.
I must admit the above is not a comprehensive list of features required for enablement of Internationalization in automated scripts but i feel it is good enough list to give an idea on things that need to be kept in mind while designing automation scripts which are scalable in multiple languages. Traditionally, the automated scripts are designed keeping in mind that they have to be run on English environments only. To me, that is a sort of cardinal sin because it robs the Software organizations of reaping multi-fold benefits from automation efforts. Consider this- if by automating the English language Build verification tests, the team handling English testing saves 1 man month of effort, it is just a simple mathematics to judge the benefits the same automated scripts will reap if they are designed to run on 10 languages.
In today's global market place, if your product currently doesn’t support International markets that does not mean that it would not in future also. If it is not already, Globalization of Software products would eventually be required for survival of organizations. In such a dynamic scenario, it is imperative that like smart individuals- we think of future possibilities upfront and include Internationalization in our Test automation design right from the word go.
I would be exploring this area further in detail in the upcoming posts and I am keen to hear your views and experiences around Test automation in general and specifically on leveraging Test automation scripts in International environment.
The idea of making a Software test Software without any human intervention is something that is the basis of automated testing. In my experience, i have seen fewer things that catch the fancy of management other than a well crafted Test automation strategy. I was recently studying one of the Surveys listing the success of Software projects across different Software development models. While it is interesting to notice how the project success ratio varies from different Software development methodologies but one important point to note here is that irrespective of the Software development methodology used, the success ratio is far less than maximum. Before i sound like deviating further in this post, the idea here is not to compare how different Software development methodologies fare in the real projects but certainly to draw an analogy that like the success ratio of Software projects, the success rate of Test automation projects (the lifecycle of which is quite similar to Software development projects, though on a smaller scale) is also quite far from ideal. I don’t have a real data to quote here and this inference is quite based on my observations and experience.
While the reasons of Test automation projects' failure can be plenty and its not my intention to dive deeper into those here but in this post i would be focusing on one of the main reasons automation efforts fail to scale up for International languages' testing.
To start with, It’s actually a colossal myth that the test scripts meant for English language automated tests cannot be reused for testing with International languages. I call it "colossal" because the root cause of the automated test scripts for any projects not working on International platform is no less than a design flaw or a lack of forethought at the time of scripts’ design. In my belief, the Software organizations (which went global quite late) have spent sizable costs due to rework relating to introduction of Internationalization quite late in the overall life cycle. On the similar lines as this, Test automation projects have also suffered great deal of rework because the test automation scripts were not Internationalized upfront. Let me try and elaborate what i mean here-
- For a Software product to be properly Internationalized i.e. ready to be sold in International markets- the product design should-
• be Unicode enabled i.e. the product should be able to process and display data in any language
• have all the strings externalized i.e. none of the strings that show up on User Interface should be hard coded.
• have the capability to know under what language OS is it running on i.e. if the product is installed in Japanese, the product logic should recognize that.
• Should be able to read locale specific details from underlying OS
• be robust enough so that the same code base can be used across all the languages that the product support.
- On the similar lines, for Test automation script to be fully internationalized i.e. working successfully on different languages,
• The Test tool should have a capability of being installed and running on different language OS.
• The Test tool and hence, the automated test scripts should have the capability to process the Unicode i.e. any language text and characters. This is because any testing that's done on International test environments makes use of International character sets(which is what the customers would do)
• The Test scripts should have a capability to understand under what language OS is it running.
• The Test data is not hard coded in the Test automation scripts and is Externalized to a file or any database. This helps because, once the Test scripts detects the language of the OS, the "right" language Test data files can be loaded.
• There should not be separate Test scripts per supported language but a single version of Test scripts should be capable to run on multiple languages.
I must admit the above is not a comprehensive list of features required for enablement of Internationalization in automated scripts but i feel it is good enough list to give an idea on things that need to be kept in mind while designing automation scripts which are scalable in multiple languages. Traditionally, the automated scripts are designed keeping in mind that they have to be run on English environments only. To me, that is a sort of cardinal sin because it robs the Software organizations of reaping multi-fold benefits from automation efforts. Consider this- if by automating the English language Build verification tests, the team handling English testing saves 1 man month of effort, it is just a simple mathematics to judge the benefits the same automated scripts will reap if they are designed to run on 10 languages.
In today's global market place, if your product currently doesn’t support International markets that does not mean that it would not in future also. If it is not already, Globalization of Software products would eventually be required for survival of organizations. In such a dynamic scenario, it is imperative that like smart individuals- we think of future possibilities upfront and include Internationalization in our Test automation design right from the word go.
I would be exploring this area further in detail in the upcoming posts and I am keen to hear your views and experiences around Test automation in general and specifically on leveraging Test automation scripts in International environment.
Saturday, August 8, 2009
Software Testing and the art of staying in present
When i first wrote an article on Soft skills that make a tester some years back, little did i capture the importance that power of concentration plays in our profession. As i grew more in the professional life, i am beginning to get more convinced that most of the inefficiencies while testing or even while dealing with regular work related stuff stems from the notorious ability of our mind to wander at will. While its quite bold of me to relate lack of concentration as one of the major reasons for quite a lot of inadequacies at the work place but a little introspection would reveal that lapses in concentration during the day actually keep us away from being at our best. Consider the following situations-
- A tester working to perform Exploratory testing in a well defined session often sees himself lost and with his mind miles away from task at hand. Does a 1 hour session mean that a tester get to spend entire one hour on testing ? Probably No even if a tester completely isolates himself/herself from the distractions around his work.
- How many times it happens that while performing one task you are either thinking of what happened before the current task or what is going to happen after the current task ?
- While working on something important, you tend to get distracted with an email arrival and tend to spend time there even though it may be as trivial as a joke from a friend.
- If you actually got to use a tool called Session Tester meant for assisting testers in performing Session based testing, it has an interesting feature called "Prime Me". On clicking this button, a tester is given some useful suggestions asking him/her to focus on the task at hand. Some suggestions such as "try touring in different ways", "Try something radical", "What do you see that you didnt see before", "What would Grandma do" etc. This feature is actually quite handy to bring the tester's mind back to where it should be. Why do you think such a feature would be needed ?
I feel that looking back at your day or even last one hour, you would quite appreciate the fact that our mind tend to be one of the most dynamic entities. At the same time, there is also a growing realization that at the very foundation of every success is an individual's power to focus on the goal till its driven to successful completion. In this context, the greater challenge is how can one tame or control one's mind to get the best out of it at will.
What is concentration ?
The Oxford dictionary definition of the word “concentration” is “the act or power of focusing one’s attention”.
One of the best definition of the word "concentration" comes from Geet Sethi (World record holder in Billiards) when he says concentration is simply remaining in the present. The longer you can remain in the present, the greater your span of concentration.
This definition quite beautifully sums up what concentration is all about.
Is it easy to concentrate and focus on something ?
I think Geet Sethi's definition of concentration really makes it seem quite simple. In reality, is it really simple ? I bet you would agree with me in answering this question as "No". Sachin Tendulkar in one of the recent interviews to Wisden stated "The toughest thing about batting is to clear your mind. The mind always wants to be in the past or in the future, it rarely wants to be in the present. My best batting comes when my mind is in the present but it doesn’t happen naturally, you have to take yourself there. I am not able to get into that zone as often as i would like but, when you are there, you don’t see anything expect bat and the ball."
Doesn’t the above text by Sachin proves that it is so human to have a mind cluttered with thoughts that either take you months ahead of current time or may be years behind ? This is a constant battle that every person faces irrespective of his/her stature and greatness is actually bestowed upon the people who are more consistently able to tame their mind to move in the direction they have set for their lives. That is what Sachin referred to above as being in "Zone".
As another cricketer- Aakash Chopra recently put it in his recent articles on the same topic- "The mind has the peculiar ability of wandering off at the first available moment, and it doesn't need any permission."
The Power of focus in Software testing:
For those who have experienced the job of Software testing, would agree with me when i say that its an intense job. To do the testing perfectly and to get the desired results requires a tester to have more than just the Technical skills required to do the job. Consider a scenario in which 2 testers with similar educational background joins an organization and undergo similar training but while at work- one tester gives absolutely wonderful results while the other remains average. There can be multiple factors leading to this situation but one major factor leading to greater performance of an individual has been the Power of focus or concentration that one exhibits while working on a task. For the people who are passionate about Software testing, would find their attention span on task at hand i.e. testing the software more than the average testers. Correlating that with Sachin's statement in previous section- when a tester is in the zone he/she always sees only the Software to be tested and works with it with full attention eliminating all other distractions. The more a skilled tester reaches such a zone, the better he/she will get at the craft of Software testing. I would really call this as "Zone of Accomplishment".
Is it possible for a tester to get in "Zone of Accomplishment" everytime he/she tests ?:
I won’t be forthcoming here and say that the answer to this is "Yes" just because we are humans and cannot always be perfect but one thing is true for a fact that the great testers get into this zone more often than others. In my experience, i have realized that often we try and fight with the thoughts in our mind to focus on task at hand. A mind in current state may have zillion thoughts such as any unfinished work, thoughts about the next day, thoughts about your personal life, thoughts about traffic, weather etc. One of my realization have been that instead of fighting with mind to get it to desired state- as a first step acknowledge that its natural for mind to wander and accept the status quo. Don’t really be hard on yourself, let the mind work with multitude of thoughts while you carve for maximum attention on the task you want to focus on.
Another idea i have found useful is to defocus and allow your mind to wander and then focus back again. The more we allow mind to work naturally, the more attention spans we would be able to get back in return.
I would really like to hear from you on your experiences towards staying in present and getting in to "Zone of Accomplishment" while testing. Do share your thoughts.
Credits:
The Inspiration of this post comes from a beautiful article written by Aakash Chopra . You can find the article here .
- A tester working to perform Exploratory testing in a well defined session often sees himself lost and with his mind miles away from task at hand. Does a 1 hour session mean that a tester get to spend entire one hour on testing ? Probably No even if a tester completely isolates himself/herself from the distractions around his work.
- How many times it happens that while performing one task you are either thinking of what happened before the current task or what is going to happen after the current task ?
- While working on something important, you tend to get distracted with an email arrival and tend to spend time there even though it may be as trivial as a joke from a friend.
- If you actually got to use a tool called Session Tester meant for assisting testers in performing Session based testing, it has an interesting feature called "Prime Me". On clicking this button, a tester is given some useful suggestions asking him/her to focus on the task at hand. Some suggestions such as "try touring in different ways", "Try something radical", "What do you see that you didnt see before", "What would Grandma do" etc. This feature is actually quite handy to bring the tester's mind back to where it should be. Why do you think such a feature would be needed ?
I feel that looking back at your day or even last one hour, you would quite appreciate the fact that our mind tend to be one of the most dynamic entities. At the same time, there is also a growing realization that at the very foundation of every success is an individual's power to focus on the goal till its driven to successful completion. In this context, the greater challenge is how can one tame or control one's mind to get the best out of it at will.
What is concentration ?
The Oxford dictionary definition of the word “concentration” is “the act or power of focusing one’s attention”.
One of the best definition of the word "concentration" comes from Geet Sethi (World record holder in Billiards) when he says concentration is simply remaining in the present. The longer you can remain in the present, the greater your span of concentration.
This definition quite beautifully sums up what concentration is all about.
Is it easy to concentrate and focus on something ?
I think Geet Sethi's definition of concentration really makes it seem quite simple. In reality, is it really simple ? I bet you would agree with me in answering this question as "No". Sachin Tendulkar in one of the recent interviews to Wisden stated "The toughest thing about batting is to clear your mind. The mind always wants to be in the past or in the future, it rarely wants to be in the present. My best batting comes when my mind is in the present but it doesn’t happen naturally, you have to take yourself there. I am not able to get into that zone as often as i would like but, when you are there, you don’t see anything expect bat and the ball."
Doesn’t the above text by Sachin proves that it is so human to have a mind cluttered with thoughts that either take you months ahead of current time or may be years behind ? This is a constant battle that every person faces irrespective of his/her stature and greatness is actually bestowed upon the people who are more consistently able to tame their mind to move in the direction they have set for their lives. That is what Sachin referred to above as being in "Zone".
As another cricketer- Aakash Chopra recently put it in his recent articles on the same topic- "The mind has the peculiar ability of wandering off at the first available moment, and it doesn't need any permission."
The Power of focus in Software testing:
For those who have experienced the job of Software testing, would agree with me when i say that its an intense job. To do the testing perfectly and to get the desired results requires a tester to have more than just the Technical skills required to do the job. Consider a scenario in which 2 testers with similar educational background joins an organization and undergo similar training but while at work- one tester gives absolutely wonderful results while the other remains average. There can be multiple factors leading to this situation but one major factor leading to greater performance of an individual has been the Power of focus or concentration that one exhibits while working on a task. For the people who are passionate about Software testing, would find their attention span on task at hand i.e. testing the software more than the average testers. Correlating that with Sachin's statement in previous section- when a tester is in the zone he/she always sees only the Software to be tested and works with it with full attention eliminating all other distractions. The more a skilled tester reaches such a zone, the better he/she will get at the craft of Software testing. I would really call this as "Zone of Accomplishment".
Is it possible for a tester to get in "Zone of Accomplishment" everytime he/she tests ?:
I won’t be forthcoming here and say that the answer to this is "Yes" just because we are humans and cannot always be perfect but one thing is true for a fact that the great testers get into this zone more often than others. In my experience, i have realized that often we try and fight with the thoughts in our mind to focus on task at hand. A mind in current state may have zillion thoughts such as any unfinished work, thoughts about the next day, thoughts about your personal life, thoughts about traffic, weather etc. One of my realization have been that instead of fighting with mind to get it to desired state- as a first step acknowledge that its natural for mind to wander and accept the status quo. Don’t really be hard on yourself, let the mind work with multitude of thoughts while you carve for maximum attention on the task you want to focus on.
Another idea i have found useful is to defocus and allow your mind to wander and then focus back again. The more we allow mind to work naturally, the more attention spans we would be able to get back in return.
I would really like to hear from you on your experiences towards staying in present and getting in to "Zone of Accomplishment" while testing. Do share your thoughts.
Credits:
The Inspiration of this post comes from a beautiful article written by Aakash Chopra . You can find the article here .
Friday, July 31, 2009
Uncovering Myths about Globalization testing- MUI Packs in Win XP and Win Vista
Myth 16: There is no difference between MUI technology being used in Win XP and Win Vista
This myth has a little bit of background in the Globalization testing Myth# 12 . This post is rather an extension to the before-mentioned post.
While performing the Globalization testing, one of the key test environment specific decisions is whether to use native language Operating system or make use of MUI packs as Microsoft provides both the options for its users. The previous post does touch upon this aspect. As i delved more into this topic, i had a realization that MUI packs do not actually behave the same as the different flavors of Windows Operating systems. With a bit of research, i was able to arrive at the below table listing the differences between the way MUI technology works in Windows XP and Windows Vista. This information has largely been derived from the below mentioned sources.
Source: http://technet.microsoft.com/en-us/library/cc721887(WS.10).aspx
http://msdn.microsoft.com/hi-in/goglobal/dd218461(en-us).aspx
This myth has a little bit of background in the Globalization testing Myth# 12 . This post is rather an extension to the before-mentioned post.
While performing the Globalization testing, one of the key test environment specific decisions is whether to use native language Operating system or make use of MUI packs as Microsoft provides both the options for its users. The previous post does touch upon this aspect. As i delved more into this topic, i had a realization that MUI packs do not actually behave the same as the different flavors of Windows Operating systems. With a bit of research, i was able to arrive at the below table listing the differences between the way MUI technology works in Windows XP and Windows Vista. This information has largely been derived from the below mentioned sources.
. | |||||
|
Source: http://technet.microsoft.com/en-us/library/cc721887(WS.10).aspx
http://msdn.microsoft.com/hi-in/goglobal/dd218461(en-us).aspx
Saturday, July 11, 2009
Uncovering Myths about Globalization testing- English version on Localized setup
Myth 15: There is no use testing the English version of a product on Localized Operating systems
This myth has a little bit of background in the Globalization testing Myth# 3 i.e. Globalization testing actually should start much before the International product is translated i.e. the User Interface, Documents etc. start showing up localized. The question here is how is the Internationalization testing done when the translated product is not available. I will just attempt to explain this in various points below-
Does English version of product and International version of product gets released for testing at the same time ?
In a more matured Software development life cycles, the code complete specific to English version of the product and the International version of product gets submitted at the same time i.e. one single English build have the code changes specific to International version as well.
In some Software development life cycles, the Internationalization specific changes gets introduced only after English build is released.
Can translation of product happen before English product's User Interface is frozen ?
Also, it is a well known fact that the in an ideal scenario, the Translation of product User interface into supported Localized languages happens only after English product's User Interface is Frozen.
* English product's User Interface is Frozen only after some cycles of testing in which entire User Interface is tested in different setups (OS, browsers etc.) to ensure that there all the User Interface specific issues are found and fixed before the different texts are translated. And even after User Interface freeze, the translation activity acually takes quite a bit of time because it is usually a manual process and has its own cycles of reviews before translation gets finalized.
* It is quite evident that since the time first build with Internationalization specific code changes is introduced to User Interface Freeze milestone to actual Translation of the product, there is a lot of time that gets elapsed. If Internationalization testing does not start when the first build (usually English build) is received, then many of the Internationalization specific changes will not get found until the Test team receives the translated build.
How can Internationalization testing happen when there is no translated software available ?
* The answer to this question is testing English version of the product on Localized setup e.g. Say a product is supporting German and Japanese languages and supports Windows XP, Windows Vista, Mac 10.5 OS- Internationalization testing in this case would involve testing English product on German Windows XP with German Internet Explorer 7.0, testing English product on Japanese Windows Vista with Japanese Firefox etc.
What kind of bugs is this type of testing (Testing English product on Localized Operating systems) helping to find ?
One may always argue that testing English product on a Localized version of the Operating system will always result in English specific issues because what we are essentially testing is the English product. This may be true to some extent but not entirely. Consider the below situations-
* The Product installation works fine when English product is installed on English Operating system. The Product installation fails when English product is installed on Spanish language. The reason- the Install Path name is hard coded in the product. The product usually gets installed in "Program Files" folder in Windows. "Program Files" folder is called as "Archivos de programa" in Spanish language.
* The data input using English characters e.g. Writing the name as "Anuj" works fine in English Operation system. When using the same build on Japanese Operating system and using the name as "廃れる" fails. The reason- the product does not recognize the Japanese language data.
These are just a few basic examples and there can be many such instances of unique bugs that can be found (i will cover this aspect in more details in upcoming blogs)
Keep testing passionately and do provide your feedback to me!
This myth has a little bit of background in the Globalization testing Myth# 3 i.e. Globalization testing actually should start much before the International product is translated i.e. the User Interface, Documents etc. start showing up localized. The question here is how is the Internationalization testing done when the translated product is not available. I will just attempt to explain this in various points below-
Does English version of product and International version of product gets released for testing at the same time ?
In a more matured Software development life cycles, the code complete specific to English version of the product and the International version of product gets submitted at the same time i.e. one single English build have the code changes specific to International version as well.
In some Software development life cycles, the Internationalization specific changes gets introduced only after English build is released.
Can translation of product happen before English product's User Interface is frozen ?
Also, it is a well known fact that the in an ideal scenario, the Translation of product User interface into supported Localized languages happens only after English product's User Interface is Frozen.
* English product's User Interface is Frozen only after some cycles of testing in which entire User Interface is tested in different setups (OS, browsers etc.) to ensure that there all the User Interface specific issues are found and fixed before the different texts are translated. And even after User Interface freeze, the translation activity acually takes quite a bit of time because it is usually a manual process and has its own cycles of reviews before translation gets finalized.
* It is quite evident that since the time first build with Internationalization specific code changes is introduced to User Interface Freeze milestone to actual Translation of the product, there is a lot of time that gets elapsed. If Internationalization testing does not start when the first build (usually English build) is received, then many of the Internationalization specific changes will not get found until the Test team receives the translated build.
How can Internationalization testing happen when there is no translated software available ?
* The answer to this question is testing English version of the product on Localized setup e.g. Say a product is supporting German and Japanese languages and supports Windows XP, Windows Vista, Mac 10.5 OS- Internationalization testing in this case would involve testing English product on German Windows XP with German Internet Explorer 7.0, testing English product on Japanese Windows Vista with Japanese Firefox etc.
What kind of bugs is this type of testing (Testing English product on Localized Operating systems) helping to find ?
One may always argue that testing English product on a Localized version of the Operating system will always result in English specific issues because what we are essentially testing is the English product. This may be true to some extent but not entirely. Consider the below situations-
* The Product installation works fine when English product is installed on English Operating system. The Product installation fails when English product is installed on Spanish language. The reason- the Install Path name is hard coded in the product. The product usually gets installed in "Program Files" folder in Windows. "Program Files" folder is called as "Archivos de programa" in Spanish language.
* The data input using English characters e.g. Writing the name as "Anuj" works fine in English Operation system. When using the same build on Japanese Operating system and using the name as "廃れる" fails. The reason- the product does not recognize the Japanese language data.
These are just a few basic examples and there can be many such instances of unique bugs that can be found (i will cover this aspect in more details in upcoming blogs)
Keep testing passionately and do provide your feedback to me!
Friday, July 3, 2009
Uncovering Myths...."Security Testing is from Mars and Globalization Testing is from Venus"
This post is a continuation of my previous post based on the real time myths about Globalization testing as i have experienced.
Myth 14- Security Testing is from Mars and Globalization testing is from Venus
Introduction:
One of the intriguing areas in the sphere of Software Globalization testing is planning/performing testing of the international application from the security perspective. One of the popular myths or rather assumptions when talking about Globalization testing is that the software applications usually do not have any impact as far as Software Security is concerned and thus the Security testing is not required to be done on an International application. While this may be true in certain contexts but there is also a large possibility that system security gets compromised with incorrect assumptions about the topic. Security related bugs usually have a high business impact and are (in most cases) costlier to fix than the related functional bugs.
Without doubt this is a much broader topic to be reasonably covered in one article alone, this article is primarily an attempt to put together a "perspective" of how different security related aspects may have impact on International Software applications.
A background in possible Security considerations for International applications:
Unicode provides a unique number for every character, no matter what the platform, no matter what the program, no matter what the language. In many ways the emergence of Unicode standard has changed the way Software Internationalization has been perceived and carried out in product design. It has been one of the significant advancement over the past encoding systems. Unicode 5.1.0 contains over 100,000 characters and encompasses of large number of different writing systems of the world, the faulty usage of the same may result in potential security attacks. Unicode consortium defines the major security threats related to International applications in 2 major categories-
1) Visual security issues
2) Non Visual security issues
Visual security threats:
The threats under this category are nothing but the Visual spoofs. Since Unicode consists of myriad of characters, there is a good probability of a layman user coming across visually confusing strings. There are no hard-and-fast rules for visual confusability- many characters look like others when used with sufficiently small sizes, in different font, considering different sequences of characters e.g. In some cases sequences of characters can be used to spoof: for example, "rn" ("r" followed by "n") is visually confusable with "m" in many sans-serif fonts.
As security expert Eric Johanson mentions in an advisory, a security weakness in a standard for handling special character sets in domain names could let an attacker spoof Web sites. There are now many ways to display any domain name on a browser, as there are a huge number of character sets which look very similar to Latin characters. The advisory demonstrates the attack using the domain for PayPal, but using an alternate Unicode character for the first "a." That gives an address that looks like "http://www.pàypal.com," but with a "à". This can enable an attacker to create a fake Web site for a phishing scam.
Non Visual security threats:
Non Visual security threats primarily deal with how the Unicode data is interpreted by the system. There are different security flaws that can be exposed by indifferent use of Unicode data by the system. Some of such attacks include-
UTF-8 Exploits, Text Comparison, Buffer Overflows, SQL Injection Vulnerabilities, Cross-Site scripting, Format String vulnerabilities etc.
Potential Security tests on International applications:
For the sake of simplifying the usage of the tests, the Security tests on the International applications can be divided as-
1) Security tests based on Functional requirements
2) Security tests based on Non-Functional requirements
Security tests based on Functional requirements:
These tests validates the Security sensitive functional portion of the system. The tests that would primarily come under these categories would pertain to applications'-
a) Authentication
b) Authorization
Authentication and Authorization tests usually go hand in hand.
If the application is going to be used in International markets, then the relevant Security tests here would be-
- To use the International characters in the supported languages. From the Security perspective, depending upon the reach of the product - the test characters can be of languages not supported by product but are supported by Unicode.
- If the product authorization is dependent upon presence or absence of an dependenant application, for an international application it will make sense to use Localized version of the applications.
Security tests based on Non-Functional requirements
Non-functional security requirement can be something like “System should not be compromised.” As is clear from the wordings, this requirement is not associated with a specific feature and it’s a very generic but an important requirement. In order to look at the Security aspects of an application accurately, it is necessary to have a holistic view of the situation. The most predominant challenge is that if the requirement is as vague as the one mentioned above, there is no one simple test be performed to make sure that the security requirement is met.
One of the possible approach that can be used to find such vulnerabilities is to generate the Flaw specific test ideas. The obvious question is which flaws to consider. Below listing has a mention of few flaws that can potentially have an impact on Internationalized applications and some ideas on how the tests can unveil these. This, by no means is the complete list of Security tests for International applications.
a) Buffer Overflow vulnerability:
o About the Buffer overflow vulnerability-
Buffer overflows occur in the software written in programming languages that do no strictly enforce bounds checking on arrays. The basic concept of a buffer overflow is that we provide an application with more data to be stored in a particular variable than the programmer setup the space for. When this happens, it is likely that the application writes past the bounds of the variable buffer, allowing an attacker to change the value of other data stored in memory and even execute the malicious commands. It is easiest for the attacker to perform buffer overflow attacks on the stack. These attacks can happen over heap but considering the dynamic nature of heap, these are usually difficult to simulate.
o How can this vulnerability impact Localized applications-
One of the possible ways this vulnerability can impact Localized applications is that the application may have typical checks built-in regarding ASCII text but the entering the Unicode data may expose the buffer overflow vulnerability.
o Possible tests on Localized applications to unveil Buffer overflow vulnerability-
1. Identify the areas of the application that are potentially vulnerable. Majorly, it would all the areas where the application accepts user inputs and particularly the areas that are exposed to wider audience. Potential candidates for this type of vulnerability would be any text fields within application that do not have any input validation check.
2. The Localized application might have done the Input validation on the text fields by virtue of number of characters supported e.g. Say, an Input field is programmed to accept maximum of 45 characters for the name field. If the character input is in English, the 45 characters will amount to 45 bytes in case of UTF-8 encoding. But if the character input is in Japanese, then depending upon the character input one character might take 3 bytes- which will amount to 45*3= 135 bytes of "acceptable" data input. Such an application is potential candidate for buffer overflow vulnerability attacks, as this gives an opportunity for the attacker to input malicious code along with the input text.
3. Depending upon the underlying encoding system in use, number of bytes a character occupies varies e.g. the character "は" occupies 2 bytes in UTF-16, 3 bytes in UTF-8 and 5 bytes in UTF-7. Thus, by using character driven Fuzz techniques the test data can be generated to simulate a situation when the character data exceeds the available buffer space.
4. Converting strings between different character encodings (such as SBCS, MBCS, Unicode, UTF-8, and UTF-16) may produce a buffer size mismatch. Being aware of the areas where such conversion is happening in application may aid the test team to focus to find this vulnerability.
5. If the application reads certain text or data embedded in the communications protocol, this source can be populated with localized text to simulate the buffer overflow attacks. e.g. by some internal operation of the program, the string may expand- which will result in enlargement of the buffer. Strings may expand in casing: Fluß → FLUSS
b) SQL Injection vulnerability:
o About the SQL Injection vulnerability-
SQL injection is an attack in which malicious code is inserted into strings that are later passed to an instance of database server for parsing and execution. The primary form of SQL injection consists of direct insertion of code into user-input variables that are concatenated with SQL commands and executed.
o How can this vulnerability impact Localized applications-
This vulnerability can be tested in the applications with an interface to the database. In case the localized applications are using the database with localized schema, then this vulnerability (if existing) might be exposed by entering alternate encodings for the potentially problematic characters such as Apostrophe, Quotation mark, Comma, Bracket etc.
o Possible tests on Localized applications to unveil SQL Injection vulnerability-
1. Make a note of all the user input fields that commit the data to the database.
2. Generate the test data that includes the data changing or even schema changing commands. There are a lot of publically available SQL vulnerability cheat sheets available that can help generate the relevant test data depending upon the database being used.
3. One of the key changes that could be made to the test data is to use the equivalent characters in the different supported languages.
c) Other Security vulnerabilities:
One of the more methodical ways while considering the Security testing for International applications is to commence with the creation of appropriate threat model. A threat model is a description of a set of security aspects; that is, when looking at a piece of software (or any computer system), one can define a threat model by defining a set of possible attacks to consider.
There are other notable Security vulnerabilities that can have potential impact on the security of International applications (and can be considered in threat modeling) such as Format String vulnerability, canonicalization exploit and with more Software vulnerabilities being found with each passing day, the list of vulnerabilities having impact on International applications can never be fixed but would always be ever growing.
Local governments may have their own specific security requirements. For example, any product that either uses or implements cryptography for confidentiality must obtain necessary approvals from the French government prior to shipping to France.
Epilogue:
It is quite evident that the International application does bring out the unique challenges from Security perspective. There is a certain intersection between Security testing and Globalization testing, something that cannot be ignored. The adage "Security testing is from Mars and Globalization testing is from Venus" is possibly not quite right! and this is certainly one area that is waiting to be explored further and researched.
References:
http://www.unicode.org/
http://www.isecpartners.com/files/iSEC_Scott_Stender_Blind_Security_Testing.bh07.pdf
Myth 14- Security Testing is from Mars and Globalization testing is from Venus
Introduction:
One of the intriguing areas in the sphere of Software Globalization testing is planning/performing testing of the international application from the security perspective. One of the popular myths or rather assumptions when talking about Globalization testing is that the software applications usually do not have any impact as far as Software Security is concerned and thus the Security testing is not required to be done on an International application. While this may be true in certain contexts but there is also a large possibility that system security gets compromised with incorrect assumptions about the topic. Security related bugs usually have a high business impact and are (in most cases) costlier to fix than the related functional bugs.
Without doubt this is a much broader topic to be reasonably covered in one article alone, this article is primarily an attempt to put together a "perspective" of how different security related aspects may have impact on International Software applications.
A background in possible Security considerations for International applications:
Unicode provides a unique number for every character, no matter what the platform, no matter what the program, no matter what the language. In many ways the emergence of Unicode standard has changed the way Software Internationalization has been perceived and carried out in product design. It has been one of the significant advancement over the past encoding systems. Unicode 5.1.0 contains over 100,000 characters and encompasses of large number of different writing systems of the world, the faulty usage of the same may result in potential security attacks. Unicode consortium defines the major security threats related to International applications in 2 major categories-
1) Visual security issues
2) Non Visual security issues
Visual security threats:
The threats under this category are nothing but the Visual spoofs. Since Unicode consists of myriad of characters, there is a good probability of a layman user coming across visually confusing strings. There are no hard-and-fast rules for visual confusability- many characters look like others when used with sufficiently small sizes, in different font, considering different sequences of characters e.g. In some cases sequences of characters can be used to spoof: for example, "rn" ("r" followed by "n") is visually confusable with "m" in many sans-serif fonts.
As security expert Eric Johanson mentions in an advisory, a security weakness in a standard for handling special character sets in domain names could let an attacker spoof Web sites. There are now many ways to display any domain name on a browser, as there are a huge number of character sets which look very similar to Latin characters. The advisory demonstrates the attack using the domain for PayPal, but using an alternate Unicode character for the first "a." That gives an address that looks like "http://www.pàypal.com," but with a "à". This can enable an attacker to create a fake Web site for a phishing scam.
Non Visual security threats:
Non Visual security threats primarily deal with how the Unicode data is interpreted by the system. There are different security flaws that can be exposed by indifferent use of Unicode data by the system. Some of such attacks include-
UTF-8 Exploits, Text Comparison, Buffer Overflows, SQL Injection Vulnerabilities, Cross-Site scripting, Format String vulnerabilities etc.
Potential Security tests on International applications:
For the sake of simplifying the usage of the tests, the Security tests on the International applications can be divided as-
1) Security tests based on Functional requirements
2) Security tests based on Non-Functional requirements
Security tests based on Functional requirements:
These tests validates the Security sensitive functional portion of the system. The tests that would primarily come under these categories would pertain to applications'-
a) Authentication
b) Authorization
Authentication and Authorization tests usually go hand in hand.
If the application is going to be used in International markets, then the relevant Security tests here would be-
- To use the International characters in the supported languages. From the Security perspective, depending upon the reach of the product - the test characters can be of languages not supported by product but are supported by Unicode.
- If the product authorization is dependent upon presence or absence of an dependenant application, for an international application it will make sense to use Localized version of the applications.
Security tests based on Non-Functional requirements
Non-functional security requirement can be something like “System should not be compromised.” As is clear from the wordings, this requirement is not associated with a specific feature and it’s a very generic but an important requirement. In order to look at the Security aspects of an application accurately, it is necessary to have a holistic view of the situation. The most predominant challenge is that if the requirement is as vague as the one mentioned above, there is no one simple test be performed to make sure that the security requirement is met.
One of the possible approach that can be used to find such vulnerabilities is to generate the Flaw specific test ideas. The obvious question is which flaws to consider. Below listing has a mention of few flaws that can potentially have an impact on Internationalized applications and some ideas on how the tests can unveil these. This, by no means is the complete list of Security tests for International applications.
a) Buffer Overflow vulnerability:
o About the Buffer overflow vulnerability-
Buffer overflows occur in the software written in programming languages that do no strictly enforce bounds checking on arrays. The basic concept of a buffer overflow is that we provide an application with more data to be stored in a particular variable than the programmer setup the space for. When this happens, it is likely that the application writes past the bounds of the variable buffer, allowing an attacker to change the value of other data stored in memory and even execute the malicious commands. It is easiest for the attacker to perform buffer overflow attacks on the stack. These attacks can happen over heap but considering the dynamic nature of heap, these are usually difficult to simulate.
o How can this vulnerability impact Localized applications-
One of the possible ways this vulnerability can impact Localized applications is that the application may have typical checks built-in regarding ASCII text but the entering the Unicode data may expose the buffer overflow vulnerability.
o Possible tests on Localized applications to unveil Buffer overflow vulnerability-
1. Identify the areas of the application that are potentially vulnerable. Majorly, it would all the areas where the application accepts user inputs and particularly the areas that are exposed to wider audience. Potential candidates for this type of vulnerability would be any text fields within application that do not have any input validation check.
2. The Localized application might have done the Input validation on the text fields by virtue of number of characters supported e.g. Say, an Input field is programmed to accept maximum of 45 characters for the name field. If the character input is in English, the 45 characters will amount to 45 bytes in case of UTF-8 encoding. But if the character input is in Japanese, then depending upon the character input one character might take 3 bytes- which will amount to 45*3= 135 bytes of "acceptable" data input. Such an application is potential candidate for buffer overflow vulnerability attacks, as this gives an opportunity for the attacker to input malicious code along with the input text.
3. Depending upon the underlying encoding system in use, number of bytes a character occupies varies e.g. the character "は" occupies 2 bytes in UTF-16, 3 bytes in UTF-8 and 5 bytes in UTF-7. Thus, by using character driven Fuzz techniques the test data can be generated to simulate a situation when the character data exceeds the available buffer space.
4. Converting strings between different character encodings (such as SBCS, MBCS, Unicode, UTF-8, and UTF-16) may produce a buffer size mismatch. Being aware of the areas where such conversion is happening in application may aid the test team to focus to find this vulnerability.
5. If the application reads certain text or data embedded in the communications protocol, this source can be populated with localized text to simulate the buffer overflow attacks. e.g. by some internal operation of the program, the string may expand- which will result in enlargement of the buffer. Strings may expand in casing: Fluß → FLUSS
b) SQL Injection vulnerability:
o About the SQL Injection vulnerability-
SQL injection is an attack in which malicious code is inserted into strings that are later passed to an instance of database server for parsing and execution. The primary form of SQL injection consists of direct insertion of code into user-input variables that are concatenated with SQL commands and executed.
o How can this vulnerability impact Localized applications-
This vulnerability can be tested in the applications with an interface to the database. In case the localized applications are using the database with localized schema, then this vulnerability (if existing) might be exposed by entering alternate encodings for the potentially problematic characters such as Apostrophe, Quotation mark, Comma, Bracket etc.
o Possible tests on Localized applications to unveil SQL Injection vulnerability-
1. Make a note of all the user input fields that commit the data to the database.
2. Generate the test data that includes the data changing or even schema changing commands. There are a lot of publically available SQL vulnerability cheat sheets available that can help generate the relevant test data depending upon the database being used.
3. One of the key changes that could be made to the test data is to use the equivalent characters in the different supported languages.
c) Other Security vulnerabilities:
One of the more methodical ways while considering the Security testing for International applications is to commence with the creation of appropriate threat model. A threat model is a description of a set of security aspects; that is, when looking at a piece of software (or any computer system), one can define a threat model by defining a set of possible attacks to consider.
There are other notable Security vulnerabilities that can have potential impact on the security of International applications (and can be considered in threat modeling) such as Format String vulnerability, canonicalization exploit and with more Software vulnerabilities being found with each passing day, the list of vulnerabilities having impact on International applications can never be fixed but would always be ever growing.
Local governments may have their own specific security requirements. For example, any product that either uses or implements cryptography for confidentiality must obtain necessary approvals from the French government prior to shipping to France.
Epilogue:
It is quite evident that the International application does bring out the unique challenges from Security perspective. There is a certain intersection between Security testing and Globalization testing, something that cannot be ignored. The adage "Security testing is from Mars and Globalization testing is from Venus" is possibly not quite right! and this is certainly one area that is waiting to be explored further and researched.
References:
http://www.unicode.org/
http://www.isecpartners.com/files/iSEC_Scott_Stender_Blind_Security_Testing.bh07.pdf
Subscribe to:
Posts (Atom)
