Test Case

A test case is a document that describes an input, action, or event and its expected result, in order to determine if a feature of an application is working correctly. A test case should contain particulars such as a
a. Test case identifier; or Test Case ID
b. Test case name;
c. Objective; or Test Case Description
d. Test conditions/setup; or Steps
e. Input data requirements, or Actions
d. Expected result
e. Actual Result
f. Test Log or Test Case Status (Pass/Fail)
Please note, the process of developing test cases can help find problems in the requirements or design of an application, since it requires you to completely think through the operation of the application. For this reason, it is useful to prepare test cases early in the development cycle, if possible.

Test Plan

A software project test plan is a document that describes the objectives, scope, approach and focus of a software testing effort. The process of preparing a test plan is a useful way to think through the efforts needed to validate the acceptability of a software product. The completed document will help people outside the test group understand the why and how of product validation. It should be thorough enough to be useful, but not so thorough that none outside the test group will be able to read it

What is Quality ?

Quality software is software that is reasonably bug-free, delivered on time and within budget, meets requirements and expectations and is maintainable. However, quality is a subjective term. Quality depends on who the customer is and their overall influence in the scheme of things. Customers of a software development project include end-users, customer acceptance test engineers, testers, customer contract officers, customer management, the development organization’s management, test engineers, testers, salespeople, software engineers, stockholders and accountants. Each type of customer will have his or her own slant on quality. The accounting department might define quality in terms of profits, while an end-user might define quality as user friendly and bug free

Considering Localization Testing

Testing resource files [separate strings from the code] Solution: create a pseudo build
String expansion: String size change breaking layout and alignment. When words or sentences are translated into other languages, most of the time the resulting string will be either longer or shorter than the native language version of the string. Two solutions to this problem:
a. Account the space needed for string expansion, adjusting the layout of your dialog accordingly
b. Separate your dialog resources into separate dynamic libraries.
Data format localization: European style: DD/MM/YY North American style: MM/DD/YY Currency, time and number format, address
Character sets: ASCII or Non ASCII Single byte character 16bit (US) 256 characters Double byte character 32bit (Chinese) 65535 code points
Encoding: Unicode: Unicode supports many different written languages in the world all in a single character encoding. Note: For double character set, it is better to convert from Unicode to UTF8 for Chinese, because UTF8 is a variable length encoding of Unicode that can be easily sent through the network via single byte streams
Builds and installer: Creating an environment that supports a single version of your code, and multiple version of the language files
Program’s installation, un-installation in the foreign machines
Testing with foreign characters: EXP: enter foreign text for user name and password. For entering European or Latin characters on Windows
a. Using Character Map tool
Search: star-program-accessories-accessibility-system tool-
b. Escape sequences. EXP: ALT + 128
For Asia languages use what is usually called an IME (input method editor)
Chinese: I use GB encoding with pin yin inputted mode
Foreign Keyboards or On-Screen keyboard
Text filters: Program that is used to collect and manipulate data usually provides the user with a mechanism for searching and filtering that data. As a global software tester, you need to make sure that the filtering and searching capabilities of your program work correctly with foreign text. Problem; ignore the accent marks used in foreign text
Loading, saving, importing, and exporting high and low ASCII
Asian text in program: how double character set work
Watch the style
Two environments to test for the program in Chinese
a. In Chinese window system (in China)
b. In English Window system with Chinese language support (in USA)
Microsoft language codes:
CHS – Chinese Simplified
CHT – Chinese Traditional(Taiwan)
ENU – English (United States)
FRA – French (France)
Java Languages codes
zh_CN – Chinese Simplified
zh_TW – Chinese Traditional(Taiwan)
Fr or fr_FR – French (France)
en or en_US – English (United States)
More need consider in localization testing:
* Hot key.
* Garbled in translation
* Error message identifiers
* Hyphenation rules
* Spelling rules
* Sorting rules
* Uppercase and lowercase conversion

Localization Aspects

Terminology
Terminology The selection and definition as well as the correct and consistent usage of terms are preconditions for successful localization:

• Laymen and expert users
• In most cases innovative domains and topics
• Huge projects with many persons involved
• Consistent terminology throughout all products
• No synonyms allowed
• Predefined terminology (environment, laws, specifications, guidelines, corporate language)

Symbols

• Symbols are culture-dependant, but often they cannot be modified by the localizer
• Symbols are often adopted from other (common) spheres of life
• Symbols often use allusions (concrete for abstract); in some cases, homonyms or even homophones are used

Illustrations and Graphics

• Illustrations and graphics are very often culture dependant, not only in content but also in the way they are presented
• Illustrations and graphics should be adapted to the (technical) needs of the target market (screen shots, manuals)
• Illustrations and graphics often contain textual elements that must be localized, but cannot be isolated

Colors have different meanings in different cultures
Character sets

• Languages are based on different character sets (“alphabets”)
• The localized product must be able to handle(display, process, sort etc) the needed character set
• “US English” character sets (1 byte, 7 bit or 8 bit)
• Product development for internationalization should be based on UNICODE (2 byte or 4 byte)

Fonts and typography

• Font types and font families are used in different cultures with varying frequency and for different text types and parts of text
• Example: In English manuals fonts with serifs (Times Roman) are preferred; In German manuals fonts without serifs (Helvetica) are preferred
• Example: English uses capitalization more frequently (e.g. CAUTION) for headers and parts of text

Language and style

• In addition to the language specific features of grammar, syntax and style, there are cultural conventions that must be taken into account for localization
• In (US English) an informal style is preferred, the reader is addressed directly, “simple” verbs are used, repetition of parts of text is accepted etc
• Formulating headers (L10N)
• Long compound words (L10N)
• Elements of the user interface(open the File menu -The Open dialog box appears -Click the copy command etc)

Formats

• Date, currency, units of measurement
• Paper format
• Different length of text

a. Consequences for the volume of documents, number of pages, page number (table of contents, index) etc.
b. Also for the size of buttons (IT, machines etc.)

I18N and L10N

These two abbreviations mean internationalization and localization respectively. Using the word “internationalization” as an example; here is how these abbreviations are derived. First, you take the first letter of the word you want to abbreviate; in this case the letter “I”. Next, you take the last letter in the word; in this case the letter “N”. These become the first and last letters in the abbreviation. Finally, you count the remaining letters in the word between the first and last letter. In this case, “nternationalizatio” has 18 characters in it. se we will plug the number 18 between the “I” and “N”; thus I18N
I18N and L10N

• I18N and L10N comprise the whole of the effort involved in enabling a product
• I18N is “Stuff” you have to do once
• L10N is “stuff you have to do over and over again
• The more stuff you push into I18N out of L10N, the less complicated and expensive the process becomes

Configuration Management

Configuration management covers the processes used to control, coordinate, and track: code, requirements, documentation, problems, change requests, designs, tools/compilers/libraries/patches, changes made to them, and who makes the changes

Verification and Validation

Verification typically involves reviews and meetings to evaluate documents, plans, code, requirements, and specifications. This can be done with checklists, issues lists, walk through, and inspection meetings. Validation typically involves actual testing and takes place after verifications are completed

Difference between Bug and Error

Bug
If the software does not meet the below criteria then it is bug

• Any thing which is not defined by the client
• If Excess Things are added in the software
• Software does not produce a expected result
• it is not user friendly

Error
An Error is a programming mistake, if the function is not responding with expected result then it is error, Bug is any thing which is not added or excess added in to software or it is functionally not well defined and it is not user friendly software. Then errors are also comes under bug

Testing Techniques

White Box Testing

• Aims to establish that the code works as designed
• Examines the internal structure and implementation of the program
• Target specific paths through the program
• Needs accurate knowledge of the design, implementation and code

Black box testing

• Aims to establish that the code meets the requirements
• Tends to be applied later in the life cycle
• Mainly aimed at finding deviations in behavior from the specification or requirement
• Causes are inputs, effects are observable outputs