What are the different levels of testing? Explain each in brief.
Component testing, also known as unit, module and program testing, searches for defects in, and verifies the functioning of software (e.g. modules, programs, objects, classes, etc.) that are separately testable. Component testing may be done in isolation from the rest of the system depend-ing on the context of the development life cycle and the system. Most often stubs and drivers are used to replace the missing software and simulate the interface between the software components in a simple manner. A stub is called from the software component to be tested; a driver calls a component to be tested .Component testing may include testing of functionality and specific non-functional characteristics such as resource-behavior (e.g. memory leaks), performance or robustness testing, as well as structural testing (e.g. decision coverage). Test cases are derived from work products such as the software design or the data model.
2. Integration testing
Integration testing tests interfaces between components, interactions to dif-ferent parts of a system such as an operating system, file system and hard-ware or interfaces between systems. Note that integration testing should be differentiated from other integration activities. Integration testing is often carried out by the integrator, but preferably by a specific integration tester or test team. There may be more than one level of integration testing and it may be carried out on test objects of varying size. For example: • component integration testing tests the interactions between software com ponents and is done after component testing; • 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 destabilizelazing. Business processes implemented as
workflows may involve a series of systems that can even run on different platforms. The greater the scope of integration, the more difficult it becomes to isolate failures to a specific interface, which may lead to an increased risk. This leads to varying approaches to integration testing. One extreme is that all components or systems are integrated simultaneously, after which everything is tested as a whole. This is called ‘big-bang’ integration testing. Big-bang testing has the advantage that everything is finished before integration testing starts. Top-down: testing takes place from top to bottom, following the control flow or architectural structure (e.g. starting from the GUI or main menu).
Components or systems are substituted by stubs.
• Bottom-up: testing takes place from the bottom of the control flow upwards. Components or systems are substituted by drivers.
• Functional incremental: integration and testing takes place on the basis of the functions or functionality, as documented in the functional specification.
3. System testing
System testing is concerned with the behavior of the whole system/product as defined by the scope of a development project or product. It may include tests based on risks and/or requirements specification, business processes, use cases, or other high level descriptions of system behavior, interactions with the operating system, and system resources. System testing is most often the final test on behalf of development to verify that the system to be delivered meets the specification and its purpose may be to find as many defects as possible. Most often it is carried out by specialist testers that form a dedicated, and sometimes independent, test team within development, reporting to the development manager or project manager. In some organizations system testing is carried out by a third party team or by business analysts. Again the required level of independence is based on the applicable risk level and this will have a high influence on the way system testing is organized. System testing should investigate both functional and non-functional requirements of the system. Typical non-functional tests include performance and reliability. Testers may 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 (white-box) techniques may also be used to assess the thoroughness of testing elements such as menu dialog structure or web page navigation. System testing requires a controlled test environment with regard to, amongst other things, control of the software versions, testware and the test data. A system test is executed by the development organization in a (properly controlled) environment. 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 by testing.
4. Acceptance testing :-
When the development organization has performed its system test and has corrected all or most defects, the system will be delivered to the user or customer for acceptance testing. The acceptance test should answer questions such as: ‘Can the system be released?’, ‘What, if any, are the outstanding (business) risks?’ and ‘Has development met their obligations?’. Acceptance testing is most often the responsibility of the user or customer, although other stakeholders may be involved as well. The execution of the acceptance test requires a test environment that is for most aspects, representative of the production environment (‘as-if production’). The goal of acceptance testing is to establish confidence in the system, part of the system or specific non-functional characteristics, e.g. usability, of the system. Acceptance testing is most often focused on a validation type of testing, whereby we are trying to determine whether the system is fit for purpose. Finding defects should not be the main focus in acceptance testing. Although it assesses the system’s readiness for deployment and use, it is not necessarily the final level of testing. For example, a large-scale system integration test may come after the acceptance of a system. Acceptance testing may occur at more than just a single level, for example: • A Commercial Off The Shelf (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. Other types of acceptance testing that exist are contract acceptance testing and compliance acceptance testing.
If the system has been developed for the mass market, e.g. commercial off-the-shelf software (COTS), then testing it for individual users or customers is not practical or even possible in some cases. Feedback is needed from potential or existing users in their market before the software product is put out for sale commercially. Very often this type of system undergoes two stages of acceptance test. The first is called alpha testing. This test takes place at the developer’s site. A cross-section of potential users and members of the developer’s organization are invited to use the system. Developers observe the users and note problems. Alpha testing may also be carried out by an independent test team. Beta testing, or field testing, sends the system to a cross-section of users who install it and use it under real-world working conditions. The users send records of incidents with the system to the development organization where the defects are repaired.