Internationalization (I18N)

• Developing a (software) product in such a way that it will be easy to adapt it to other markets (languages and cultures)
• Goal: eliminate the need to reprogram or recompile the original program
• Carried out by SW-Development in conjunction with Localization
• Handing foreign text and data within a program
• Sorting, importing and exporting text and data, correct handing of currency and data and time formats, string parsing, upper and lower case handling
• Separating strings from the source code and making sure that the foreign language string has enough space in your user interface to be displayed correctly

Internationalization
The aspect of development and testing relating to handling foreign text and data within a program, this would include sorting, importing and exporting text and data, correct handling of currency and date and time formats, string parsing, upper and lower case handling, and so forth. It also includes the task of separating strings (or user interface text) from the source code, and making sure that the foreign language strings have enough space in your user interface to be displayed correctly. You could think of internationalization as pertaining of the underlying functionality and workings of your program

Localization (L10N)

• Adapting a (software) product to a local or regional market
• Goal: Appropriate linguistic and cultural aspects
• Performed by translators, localizers, language engineers

Localization
The aspect of development and testing relating to the translation of the software & the ITE presentation to the end user. This includes translating the program, choosing appropriate icons and graphics, and other cultural considerations. It also may include translating the program's help files and the documentation. You could think of localization as pertaining to the presentation of your program; the things the user sees

Walk-through

A walk-through is an informal meeting for evaluation or informational purposes. A walk-through is also a process at an abstract level. It's the process of inspecting software code by following paths through the code (as determined by input conditions and choices made along the way). The purpose of code walk-throughs is to ensure the code fits the purpose Walk-throughs also offer opportunities to assess an individual's or team's competency

Cause of Software Bugs

Incorrect communication or no communication - as to specifics of what an application should or shouldn't do (the application's requirements)
Software complexity - the complexity of current software applications can be difficult to comprehend for anyone without experience in modern-day software development. Windows-type interfaces, client-server and distributed applications, data communications, enormous relational databases, and sheer size of applications have all contributed to the exponential growth in software/system complexity
Programming errors - programmers, like anyone else, can make mistakes
Changing requirements - the customer may not understand the effects of changes, or may understand and request them anyway - redesign rescheduling of engineers, effects on other projects, work already completed that may have to be redone or thrown out, hardware requirements that may be affected, etc. If there are many minor changes or any major changes, known and unknown dependencies among parts of the project are likely to interact and cause problems, and the complexity of keeping track of changes may result in errors. Enthusiasm of engineering staff may be affected. In some fast-changing business environments, continuously modified requirements may be a fact of life. In this case, management must understand the resulting risks, and QA and test engineers must adapt and plan for continuous extensive testing to keep the inevitable bugs from running out of control
Time pressures - scheduling of software projects is difficult at best, often requiring a lot of guesswork. When deadlines loom and the crunch comes, mistakes will be made.
Poorly documented code - it's tough to maintain and modify code that is badly written or poorly documented; the result is bugs. In many organizations management provides no incentive for programmers to document their code or write clear, understandable code. In fact, it's usually the opposite: they get points mostly for quickly turning out code, and there's job security if nobody else can understand it
Software development tools - visual tools, class libraries, compilers, scripting tools, etc. often introduce their own bugs or are poorly documented, resulting in added bugs

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

Bug Life Cycle

1. New: When bug rises then it is in the New State
2. Open: Developer Check the Bug Then it is in the Open state
3. Fixed: Developer Fixes the Bug, Then State is fixed
4. Closed: Tester Checks again, if bug is not raised then it is Closed State
5. Reopen: Again It is raised then it is in Reopen State