Delivery & User testing
Importance of the phase for democratic dialogue
Delivery & User testing is the phase during which we verify that the application meets the needs expressed.
It is essential that compliance with requirements in terms of well-being and citizenship at work can be validated during this phase by the stakeholders who raised these requirements in previous phases.
Standard presentation of the phase
APIDOR’s advice
This phase involves implementing the application in an acceptance testing environment and performing various checks to ensure that the application meets the specified requirements.
Other names: user acceptance tests (UAT)
Objectives of the phase
The objective of the phase is to have the “business” party (sponsor, project owner) validate the developed application (which has been technically tested by the project management team during the previous phase).
This validation will enable preparation for the next phase, the deployment of the application “in real life”.
Note: the challenges for senior management
The expectation, rather than the challenge, is that the number of bugs and defects should be kept to a minimum, as correcting errors means missed deadlines and increased costs.
Phase inputs and outputs
Inputs
The software developed and tested at a technical level (in a development environment) by the project owner.
External documentation.
Outputs
The approved acceptance log (validation of acceptance).
The application developed, fully tested and ready to be deployed in the users’ working environment.
Actors and bodies involved
The project owner, one or more project owner assistants (business analysts).
Users (chosen by the management of the department concerned).
The project manager.
Developers, possibly with a test manager.
- Democratic dialogue procedures
Stakeholders responsible for the requirements in well-being and citizenship at work must be involved in this phase.
Content and sequence of the phase
A test plan is defined, specifying the following for each test: the resources allocated, the schedule of operations, and logistics (technical environment, tools, etc.).
The scenarios to be tested, the list of cases, the functional paths, etc. are defined.
The acceptance criteria are set (maximum number of acceptable anomalies according to severity).
During this phase, two levels of acceptance can be performed:
- Functional acceptance: verifies that the software works without errors in an acceptance environment (i.e., more limited than in “real” operation) and complies with the detailed functional specifications.
- User acceptance: this involves verifying that the application works correctly in a business environment close to real life, in accordance with all the requirements (functional and non-functional) expressed. This acceptance test requires a reference database and an ad hoc autonomous technical environment.
This acceptance test results in a validated acceptance test report.
The result of this phase is an application in operational condition, ready to be deployed to users (next phase).
- Point to note: acceptance test specifications
Check that the functional and non-functional requirements generated by the democratic dialogue are included in the acceptance test specifications (i.e., that they will be tested during acceptance).
- Point to note: participation in user acceptance testing
Those responsible for well-being and citizenship at work requirements must participate in acceptance testing to verify that the functional and non-functional requirements generated by the democratic dialogue are met.
- Point to note: time spent on testing
Is the time allocated for the testing period considered sufficient by future users and those responsible for well-being and citizenship at work requirements who will participate in acceptance testing?
- Democratic dialogue procedures
The procedure for correcting identified errors must be known and accepted by those responsible for well-being and citizenship at work requirements: reporting of problems, problem-handling procedure (by whom, how and on what criteria are decisions made to correct or not, etc.).
Information usually disseminated/processed
Project monitoring indicators (KPIs) on costs and deadlines.
May or may not be disseminated: information on the number of errors and their categorization (level of criticality), the completed acceptance log.