Etapele Testarii

According to the distinct development phases in which we can produce testable results, we
identify test levels to facilitate testing of these results.
• Unit tests: test the smallest testable units (classes, Web pages, etc.), independently of one
another. Unit testing is done by the developer during implementation.
• Integration tests: evaluate the interaction between distinct and separately tested units once
they have been integrated. Integration tests are performed by a tester, a developer, or both
jointly.
• System tests: test the complete, integrated system. System tests are typically performed by
a specialized test team.
• Acceptance tests: evaluate the system in cooperation with or under the auspice of the client
in an environment that comes closest to the production environment. Acceptance tests use
real conditions and real data.
• Beta tests: let friendly users work with early versions of a product with the goal to provide
early feedback. Beta tests are informal tests (without test plans and test cases) which rely
on the number and creativity of potential users.
As development progresses, one proceeds from a verification against the technical specification
(if available) – as in unit tests, integration tests and system tests – to a validation against user
expectations – as in acceptance tests and beta tests.
An inherent risk when performing the test levels sequentially according to the project’s phases
is that errors due to misunderstood user expectations may be found only at a late stage, which
makes their removal very costly. To minimize this risk, testing has to be an integrated part
of the product construction which should encompass the whole development process. Hence,
quality-assurance measures like reviews or prototyping are used even before running unit
tests. A strongly iterative and evolutionary development process reduces this risk since smaller
system parts are frequently tested on all test levels (including those with validation against user
expectations), so that errors can be found before they can have an impact on other parts of the
system. This means that the sequence of test levels described above does not always dictate the
temporal sequence for Web project testing but may be performed several times, e.g. once for
each incrementation of functionality.