Test phases :
There are four distinct and progressive test phases (or levels), which must be respected. Each phase targets a specific aspect of a system or software product.
The breakdown of test phases helps to :
- Avoid redundancy between test phases (duplicate testing).
- Ensure that the product is adequate before integrating it into a higher-level component (progression).
- Facilitate error source detection.
- Avoid generating errors in other systems.
- Avoid “big-bang” testing.
The four phases of testing are
- Unit testing (UT) to verify the operation of a piece of software in isolation.
- Integration Testing (IT) to verify the interaction between various components of a single application.
- System testing (ST) to verify the behavior of the system as a whole, i.e. between applications.
- Acceptance testing (AT) to validate whether the system meets the customer's initial requirements.
Unit testing (UT)
The project team must carry out its unit or component tests, either manually or automatically.
Unit tests are carried out to demonstrate that a unit satisfies its functional requirements and that its implementation structure conforms to the design concept.
These tests of a program, a class, a module or an isolated component, ensure the absence of analysis or programming errors. The aim is to ensure that the detailed logic of the component is accurate and reliable according to predetermined specifications.
Each process is individually validated, ensuring that 100% of the lines of code have been executed at least once.
A test unit is the smallest testable software element that can be compiled, assembled, linked, loaded and configuration managed. A screen page or a report is a unit for the test team. A unit is generally the work of a single programmer and is made up of several lines of source code. The essential characteristic of a unit is that it must be meaningful to be treated as a whole. Each developer is responsible for verifying the functionalities to be satisfied by his or her units.
Unit tests are carried out by the development team in the development environment as units are developed.
The effort involved in unit testing (planning, design and execution) is around 6% of the total effort of a project, phase, release or iteration.
Integration testing (IT)
Integration testing is carried out to demonstrate that even if an individual component is satisfactory, the combination of several components is also satisfactory; that it satisfies its functional requirements and that its implementation structure conforms to its design and architecture.
Integration testing follows an ordered progression of tests in which software and hardware elements are assembled and tested until the whole application is tested.
Integration testing is ideally carried out by a test team independent of development, in the test environment.
As development progresses, new components are developed, and the test team ensures that they are properly integrated until the complete executable application has been built.
The test team must therefore establish a component integration strategy, which must be incorporated into the test plan. Integration tests therefore consist of simulated modules.
The effort required to carry out integration testing (planning, design and execution) is around 14% of the total effort required for a project, phase, release or iteration.
System testing (ST)
The aim of system testing is to test the entire system from every angle, including its ramifications with other applications and external systems. Integration with external systems is important at this stage.
System testing deals with the overall functionality of the system.
They focus more on functional, or black-box, testing, and verify compliance with all the specifications expressed by the customer.
System testing is carried out by the test team in the test environment.
System tests also include performance, volume, security, configuration, stress, startup and recovery tests.
The effort required for system testing (planning, design and execution) is around 14% of the total effort for a project, phase, release or iteration.
Acceptance testing (AT)
Acceptance tests are formal tests carried out by the customer. They determine whether the system meets the initial requirements and acceptance criteria.
Based on business processes, they validate that the system functions as intended by the user in the real world. They are based on realistic business scenarios.
Acceptance tests are carried out by system users or their representatives with the help of the supplier in the customer's environment (pre-production).
Acceptance tests validate the system in a production-like environment. Following these tests, the system can be put into production.
Good execution practices
When executing TI, TS and TA tests, approximately 5% of the effort should be set aside at the beginning of the execution period for ad-hoc testing, before starting the actual tests as planned.
Ad-hoc testing is creative, informal testing not based on a test plan or test cases. The tester improvises and learns the system during the execution of these tests. They are random tests based on the probability of finding an error.
We end the test period with around 10% of the effort spent on exploratory testing. Exploratory tests are similar to ad-hoc tests, except that the tester knows the system.
Conclusion
By covering all stages, from unit testing to acceptance testing, each phase contributes to detecting and correcting anomalies, thus ensuring that the software or system meets user expectations and market requirements.
In my next article, I'll look at the benefits of breaking down testing in this way, as well as the need to develop a risk-based testing strategy and plan.
To find out more :
Quality: The Basics and Best Practices of Software TestingQuality: plan and execute your software testing activities
Software testing : implementing a team in the organization
Software Testing: Applying the Best Practices Using the Agile Mode
