Software QA FYI - SQAFYI

Software QA/Testing Technical FAQs

Part:   1  2  3  4  5  6  7  8  9  10  11  12  13  14  15  16  17  18  19  20  21  22  23  24  25  26  27  28  29  30  31   32  33  34  35  36  37  38  39  40  41  42  43  44  45  46  47 

What are Internationalization, Localization, Globalization, and Multilingualization Testing?

Internationalization and localization are a means of adapting software for non-native environments, especially other nations and cultures. Internationalization is often abbreviated as I18N (or i18n or I18n), where the number 18 refers to the number of letters omitted. "Localization" is often abbreviated l10n in the same manner. Both are sometimes collectively termed globalization (g11n). Also seen in some circles, but less commonly, are "p13n" for personalization? and "r3h" for reach, as in the reach of a website across countries and markets.
L10N should support two languages or character codes simultaneously, usually English (ASCII) and another specific one. Since each programmer has his or her own mother tongue, there are numerous L10N patches and L10N programs written to satisfy his or her own need. L10N is preparing a feature or system for use in a local market, e.g., Russia, Japan, Québec. Usually a market has a distinct language, customs and regulations. At the very least, user interface elements are translated into the local language.
I18N is also sometimes used interchangeably with G11N when speaking broadly of the economic and cultural effects of an increasingly interconnected world. In software terms, Usage of the term I18N has become rare; the term globalization (G11N) is preferred mostly because of corporate globalization where many companies and products find themselves in many countries worldwide.
G11N is a multi-step process to prepare a feature or system for use in multiple markets, or at least so that it can easily be localized. It is most commonly taken to refer to the addition of a framework for multiple language support. This implies that the application is capable of input of and displaying non-western character sets. These activities include software localization, and technical document translation result in user interfaces, on-line help systems, and documentation that are adapted to the cultural, linguistic, and technical requirements of specific international markets. This has given rise to increasing requirements for localization (L10N) of products and services.
M17N (multilingualization) model is to support many languages at the same time. For example, Mule (MULtilingual Enhancement to GNU Emacs) can handle a text file which contains multiple languages - for example, a paper on differences between Korean and Chinese whose main text is written in Finnish. GNU Emacs 20 and XEmacs now include Mule. Note that the M17N model can only be applied in character-related instances. For example, it is nonsense to display a message like 'file not found' in many languages at the same time. Unicode and UTF-8 are technologies which can be used for this model. Viewing a website in English and same in French should not have any functionality differences ideally, and no runtime errors. Check for incorrect translations, misspelled words and wrong symbols for the particular language chosen by the user. The language conversion should be consistent throughout the application. Use of shared variables can cause serious bugs, like when users select same page or content to view but choose different languages however the page is renderd in the previous user's language.


What makes a good QA engineer?
The same qualities a good test engineer has are useful for a QA engineer. Additionally, Rob Davis understands the entire software development process and how it fits into the business approach and the goals of the organization. Rob Davis' communication skills and the ability to understand various sides of issues are important. Good QA engineers understand the entire software development process and how it fits into the business approach and the goals of the organization. Communication skills and the ability to understand various sides of issues are important.


Difference between Verification and Validation?


Answer1:
The ISO would say that Verification is a process of determining whether or not the products of a given phase of the software development cycle meets the implementation steps and can be traced to the incoming objectives established during the previous phase. The techniques for verification are testing, inspection and reviewing.
Validation is a process of evaluating software at the end of the software development process to ensure compliance with software requirements. The techniques for validation are testing, inspection and reviewing.

Answer2:
Validation:Determination of the correctness of the products with respect to the user needs and requirements.
Verification:Determination of the correctness of the product with respect to the test conditions/requirement imposed at the start.

Answer3:
the diifernce between V & V.
*no.*
Verification ensures that the system complies with organizations standards & processes.
Validation physically ensures that the system operates according to plan.
Relies on non-executable methods of analyzing various artifacts.
Executes the system functions through a series of tests that can be observed & evaluated.
Answers the question "Did we build the right system?"
Answers the question "Did we build the system right?"
E.g. Check sheets, traceability matrix,
Uses functional or structural testing techniques to catch defects.
Includes Requirement reviews, design reviews, code walkthroughs, code inspections, test reviews, independent static analyzers, confirmation in which 3rd party attests to the document, desk checking.
Includes Unit testing, coverage analysis, black box techniques, Integrated testing, System testing & User Acceptance testing.
Most effective, it has been proven that 65% defects can be discovered here.
Effective, but not as effective as verification, for removing defects. It has been proven that 30% of defects can be discovered here.
Can be used throughout SDLC.

Part:   1  2  3  4  5  6  7  8  9  10  11  12  13  14  15  16  17  18  19  20  21  22  23  24  25  26  27  28  29  30  31   32  33  34  35  36  37  38  39  40  41  42  43  44  45  46  47 

Software QA/Testing Technical FAQs