Testing Types

Unit testing:

The most 'micro' scale of testing; to test particular functions or code modules. Typically done by the programmer and not by testers, as it requires detailed knowledge of the internal program design and code. Not always easily done unless the application has a well-designed architecture with tight code; may require developing test driver modules or test harnesses.

Integration testing:

Integration testing is a logical extension of unit testing. In its simplest form, two units that have already been tested are combined into a component and the interface between them is tested. A component, in this sense, refers to an integrated aggregate of more than one unit. In a realistic scenario, many units are combined into components, which are in turn aggregated into even larger parts of the program. The idea is to test combinations of pieces and eventually expand the process to test your modules with those of other groups. Eventually all the modules making up a process are tested together. Beyond that, if the program is composed of more than one process, they should be tested in pairs rather than all at once.

Generally integration test carried out in two ways, called the bottom-up approach and the top-down approach. Bottom-up integration testing begins with unit testing, followed by tests of progressively higher-level combinations of units called modules or builds. In top-down integration testing, the highest-level modules are tested first and progressively lower-level modules are tested after that. In software development environment, bottom-up testing is usually done first, followed by top-down testing.

Bottom up testing: In case of bottom up testing the test engineers uses test drivers which are temporary programs (that have been not developed yet to replace main module

Top down testing: In case of top down testing the test engineers uses stubs which are temporary programs (that have been not developed yet ) to replace sub modules.

Regression testing:

Fixing an issue results any news issue in any other aspect will be tested in regression testing. It tests older functionality should not be effected during new code added to existing code. Generally in Regression testing what organization do is executing the all test cases once.Regression will be performed in two cases. In the first case once issue reported by tester is fixed and second before project going to live.

User acceptance testing:

User Acceptance Testing is the final stage of validation. This is the time that customers get their hands on the system (or should do) and the end product of this is usually a sign-off from the users.

One of the problems is that this is rather late in the project for users to be involved - any problems found now are too late to do anything about them. This is one reason why Rapid Application Development (RAD) has become popular. Users are involved earlier and testing is done earlier.

However, the users should have been involved in the test specification of the Acceptance Tests at the start of the project. They should also have been involved in reviews throughout the project, and there is nothing to say that they cannot be involved in helping to design System and Integration tests. So there really should be no surprises!

usability testing:

Usability testing measures the site's interface for ease and intuitiveness of navigation.

Validation testing:

Validation is the term for verifying that the HTML code in a file meets the DTD (Document Type Definition) for any particular version of HTML. This is important because strict adherence to a DTD specification ensures the best likelihood of any file being fully supportable by a browser that follows that DTD.

Ad Hoc Test:

Informal testing without a test case.

Age Test (aging):

Evaluating a system's ability to perform in the future. To perform these tests, hardware and/or test data is modified to a future date.


Black Box Test:

Testing software based on output only without any knowledge of internal operation. Contrast with "white box test."

When black box testing is applied to software engineering, the tester would only know the "legal" inputs and what the expected outputs should be, but not how the program actually arrives at those outputs.


Environment Test:

A test of new software that determines whether all transactions flow properly between input, output and storage devices.

Functional Test:

Testing software based on its functional requirements. It ensures that the program physically works the way it was intended and all required menu options are present. It also ensures that the program conforms to the industry standards relevant to that environment. For example, in a Windows program, pressing F1 brings up help.



Compatibility testing:

Compatibility testing measures how well pages display on different clients; for example: browsers, different browser version, different operating systems, and different machines. At issue are the different implementations of HTML by the various browser manufacturers and the different machine platform display and rendering characteristics. Also called browser compatibility testing and cross-browser testing.

Stress Testing:

During a stress test, the system has to process a huge amount of data or perform many function calls within a short period of time. A typical example could be to perform the same function from all workstations connected in a LAN within a short period of time (e.g. sending e-mails, or, in the NLP area, to modify a term bank via different terminals simultaneously).

Recovery Testing:

The aim of recovery testing is to make sure to which extent data can be recovered after a system breakdown. Does the system provide possibilities to recover all of the data or part of it? How much can be recovered and how? Is the recovered data still correct and consistent? Particularly for software that needs high reliability standards, recovery testing is very important.