User Testing

User Testing

User or customer testing is a crucial stage in the testing process where users or customers provide input and feedback on the system being tested.

It can involve formal testing of a system commissioned from an external supplier or an informal process where users experiment with new software to assess its suitability. Even after comprehensive system and release testing, user testing remains essential due to its impact on reliability, performance, usability, and robustness.

The user's working environment significantly influences the system's functionality, which developers may not replicate accurately in their testing environments.

Developers' testing environments are often artificial and cannot simulate real-world scenarios. For instance, a system designed for hospital use must be tested in a clinical environment, considering factors like patient emergencies and interactions with relatives, which cannot be replicated in a developer's setting.

In practice, there are three different types of user testing:

  1. Alpha testing:- where users of the software work with the development team to test the software at the developer’s site.

  2. Beta testing:- where a release of the software is made available to users to allow them to experiment and to raise problems that they discover with the system developers.

  3. Acceptance testing:- where customers test a system to decide whether or not it is ready to be accepted by the system developers and deployed in the customer environment.

Acceptance testing is an inherent part of custom systems development. It takes place after release testing. It involves a customer formally testing a system to decide whether or not it should be accepted by the system developer. Acceptance implies that payment should be made to the system.

There are six stages in the acceptance testing process:-

  1. Define acceptance criteria:- This stage should, ideally, take place early in the process before the contract for the system is signed. The acceptance criteria should be part of the system contract and be agreed between the customer and the developer. In practice, however, it can be difficult to define criteria so early in the process. Detailed requirements may not be available and there may be significant requirements change during the development process.

  2. Plan acceptance testing:- This involves deciding on the resources, time, and budget for acceptance testing and establishing a testing schedule. The acceptance test plan should also discuss the required coverage of the requirements and the order in which system features are tested. It should define risks to the testing process, such as system crashes and inadequate performance, and discuss how these risks can be mitigated.

  3. Derive acceptance tests:- Once acceptance criteria have been established, tests have to be designed to check whether or not a system is acceptable. Acceptance tests should aim to test both the functional and non-functional characteristics of the system. They should, ideally, provide complete coverage of the system requirements. In practice, it is difficult to establish completely objective acceptance criteria. There is often scope for argument about whether or not a test shows that a criterion has definitely been met.

  4. Run acceptance tests:- The agreed acceptance tests are executed on the system. Ideally, this should take place in the actual environment where the system will be used, but this may be disruptive and impractical. Therefore, a user testing environment may have to be set up to run these tests. It is difficult to automate this process as part of the acceptance tests may involve testing the interactions between end-users and the system. Some training of end-users may be required.

  5. Negotiate test results:- It is very unlikely that all of the defined acceptance tests will pass and that there will be no problems with the system. If this is the case, then acceptance testing is complete and the system can be handed over. More commonly, some problems will be discovered. In such cases, the developer and the customer have to negotiate to decide if the system is good enough to be put into use. They must also agree on the developer’s response to identified problems.

  6. Reject/accept system:- This stage involves a meeting between the developers and the customer to decide whether or not the system should be accepted. If the system is not good enough for use, then further development is required to fix the identified problems. Once complete, the acceptance testing phase is repeated.

User or customer testing is a vital stage in the testing process where users provide feedback on the system. This feedback is essential for assessing reliability, performance, usability, and robustness. Developers often cannot replicate the real-world working environment, which makes user testing crucial even after comprehensive system testing.