Load Testing Definition

A formal test plan is a document that provides and records important information about a test project, for example:

project and quality assumptions
project background information
resources
schedule & timeline
entry and exit criteria
test milestones
tests to be performed
use cases and/or test cases

Localization (L10N) is the process of customizing a software application that was originally designed for a domestic market so that it can be released in foreign markets. This process involves translating all native language strings to the target language and customizing the GUI so that it is appropriate for the target market. Depending on the size and complexity of the software, localization can range from a simple process involving a small team of translators, linguists, desktop publishers and engineers to a complex process requiring a Localization Project Manager directing a team of a hundred specialists. Localization is usually done using some combination of in-house resources, independent contractors and full-scope services of a localization company.

Agile software development is a conceptual framework for software engineering that promotes development iterations throughout the life-cycle of the project.
There are many agile development methods; most minimize risk by developing software in short amounts of time. Software developed during one unit of time is referred to as an iteration, which may last from one to four weeks. Each iteration is an entire software project: including planning, requirements analysis, design, coding, testing, and documentation. An iteration may not add enough functionality to warrant releasing the product to market but the goal is to have an available release (without bugs) at the end of each iteration. At the end of each iteration, the team re-evaluates project priorities.

The goal of globalization testing is to detect potential problems in application design that could inhibit globalization. It makes sure that the code can handle all international support without breaking functionality that would cause either data loss or display problems. Globalization testing checks proper functionality of the product with any of the culture/locale settings using every type of international input possible.

In I18N testing, first step is to identify all the textual information in the system. This includes all the text present on the application's GUI, any text/messages that application is producing including error message/warning and help/documentation etc. Main focus of the I18N testing is not to find functional defects, but to make sure that product is ready for the global market. As in other non functional testing it is assumed that functional testing has been completed and all the functionality related defects are identified and removed.

I18N testing can be divided in to two parts. First, to make sure that application's GUI or functionality will not be broken with the translated text. Second to make sure that translation of all the strings have happened properly. This activity is called Translation Verification Testing and is normally conducted by person who knows the language very well.

A manual tester would typically perform the following steps for manual testing:

Understand the functionality of program
Prepare a test environment
Execute test case(s) manually
Verify the actual result
Record the result as Pass or Fail
Make a summary report of the Pass and Fail test cases
Publish the report
Record any new defects uncovered during the test case execution

In this type of testing, the software is tested for the functional requirements. The tests are written in order to check if the application behaves as expected. Although functional testing is often done toward the end of the development cycle, it can-and should, -be started much earlier. Individual components and processes can be tested early on, even before it's possible to do functional testing on the entire system. Functional testing covers how well the system executes the functions it is supposed to execute-including user commands, data manipulation, searches and business processes, user screens, and integrations

The application is tested against heavy load such as complex numerical values, large number of inputs, large number of queries etc. which checks for the stress/load the applications can withstand. Stress testing deals with the quality of the application in the environment. The idea is to create an environment more demanding of the application than the application would experience under normal work loads. This is the hardest and most complex category of testing to accomplish and it requires a joint effort from all teams. A test environment is established with many testing stations. At each station, a script is exercising the system.

This type of testing is done without any formal Test Plan or Test Case creation. Ad-hoc testing helps in deciding the scope and duration of the various other testing and it also helps testers in learning the application prior starting with any other testing. It is the least formal method of testing. One of the best uses of ad hoc testing is for discovery. Reading the requirements or specifications (if they exist) rarely gives you a good sense of how a program actually behaves. Even the user documentation may not capture the "look and feel" of a program. Ad hoc testing can find holes in your test strategy, and can expose relationships between subsystems that would otherwise not be apparent. In this way, it serves as a tool for checking the completeness of your testing.

This testing is similar to the ad-hoc testing and is done in order to learn/explore the application.

Exploratory software testing is a powerful and fun approach to testing. In some situations, it can be orders of magnitude more productive than scripted testing. At least unconsciously, testers perform exploratory testing at one time or another. Yet it doesn't get much respect in our field. It can be considered as "Scientific Thinking" at real time