Software Testing - Tutorials, QTP, Manual Testing Automation Testing, Load Runner

For each of the test levels, the following can be identified: their generic objectives, the work
product(s) being referenced for deriving test cases (i.e. the test basis), the test object (i.e. what is being tested), typical defects and failures to be found, test harness requirements and tool support, and specific approaches and responsibilities.

Component testing

Component testing searches for defects in, and verifies the functioning of, software (e.g. modules, programs, objects, classes, etc.) that are separately testable. It may be done in isolation from the rest of the system, depending on the context of the development life cycle and the system. Stubs, drivers and simulators may be used. Component testing may include testing of functionality and specific non-functional characteristics, such as resource-behaviour (e.g. memory leaks) or robustness testing, as well as structural testing (e.g. branch coverage). Test cases are derived from work products such as a specification of the component, the software design or the data model.

Typically, component testing occurs with access to the code being tested and with the support of
the development environment, such as a unit test framework or debugging tool, and, in practice,
usually involves the programmer who wrote the code. Defects are typically fixed as soon as they
are found, without formally recording incidents.
One approach to component testing is to prepare and automate test cases before coding. This is
called a test-first approach or test-driven development. This approach is highly iterative and is
based on cycles of developing test cases, then building and integrating small pieces of code, and
executing the component tests until they pass.



Integration testing

Integration testing tests interfaces between components, interactions with different parts of a
system, such as the operating system, file system, hardware, or interfaces between systems.
There may be more than one level of integration testing and it may be carried out on test objects of varying size. For example:

1. Component integration testing tests the interactions between software components and is done after component testing;
2. System integration testing tests the interactions between different systems and may be done
after system testing. In this case, the developing organization may control only one side of the
interface, so changes may be destabilizing. Business processes implemented as workflows
may involve a series of systems. Cross-platform issues may be significant.
The greater the scope of integration, the more difficult it becomes to isolate failures to a specific
component or system, which may lead to increased risk.


Systematic integration strategies may be based on the system architecture (such as top-down and bottom-up), functional tasks, transaction processing sequences, or some other aspect of the system or component. In order to reduce the risk of late defect discovery, integration should normally be incremental rather than “big bang”.
Testing of specific non-functional characteristics (e.g. performance) may be included in integration testing.
At each stage of integration, testers concentrate solely on the integration itself. For example, if they are integrating module A with module B they are interested in testing the communication between the modules, not the functionality of either module. Both functional and structural approaches may be used.
Ideally, testers should understand the architecture and influence integration planning. If integration tests are planned before components or systems are built, they can be built in the order required for most efficient testing.


System testing

System testing is concerned with the behaviour of a whole system/product as defined by the scope of a development project or programme.In system testing, the test environment should correspond to the final target or production environment as much as possible in order to minimize the risk of environment-specific failures not being found in testing.

System testing may include tests based on risks and/or on requirements specifications, business
processes, use cases, or other high level descriptions of system behaviour, interactions with the
operating system, and system resources.

System testing should investigate both functional and non-functional requirements of the system. Requirements may exist as text and/or models. Testers also need to deal with incomplete or undocumented requirements. System testing of functional requirements starts by using the most appropriate specification-based (black-box) techniques for the aspect of the system to be tested.

For example, a decision table may be created for combinations of effects described in business
rules. Structure-based techniques (white-box) may then be used to assess the thoroughness of the testing with respect to a structural element, such as menu structure or web page navigation.
An independent test team often carries out system testing.


Acceptance testing


Acceptance testing is often the responsibility of the customers or users of a system; other
stakeholders may be involved as well.
The goal in acceptance testing is to establish confidence in the system, parts of the system or
specific non-functional characteristics of the system. Finding defects is not the main focus in
acceptance testing. Acceptance testing may assess the system’s readiness for deployment and
use, although it is not necessarily the final level of testing. For example, a large-scale system
integration test may come after the acceptance test for a system.

Acceptance testing may occur as more than just a single test level, for example:

• A COTS software product may be acceptance tested when it is installed or integrated.
• Acceptance testing of the usability of a component may be done during component testing.
• Acceptance testing of a new functional enhancement may come before system testing.

Typical forms of acceptance testing include the following:

User acceptance testing
Typically verifies the fitness for use of the system by business users.

Operational (acceptance) testing
The acceptance of the system by the system administrators, including:

• testing of backup/restore;
• disaster recovery;
• user management;
• maintenance tasks;
• periodic checks of security vulnerabilities.
  

Contract and regulation acceptance testing
Contract acceptance testing is performed against a contract’s acceptance criteria for producing
custom-developed software. Acceptance criteria should be defined when the contract is agreed.
Regulation acceptance testing is performed against any regulations that must be adhered to, such as governmental, legal or safety regulations.

Alpha and beta (or field) testing
Developers of market, or COTS, software often want to get feedback from potential or existing
customers in their market before the software product is put up for sale commercially. Alpha testing is performed at the developing organization’s site. Beta testing, or field testing, is performed by people at their own locations. Both are performed by potential customers, not the developers of the product.
Organizations may use other terms as well, such as factory acceptance testing and site acceptance testing for systems that are tested before and after being moved to a customer’s site.

SPONSORED LINKS