User tasting

User or customer testing is a stage in the testing process in which users or customer provide input and advice on system testing .this may involve formally testing a system that has been commissioned from an external supplier, or could be an informal process where user experiment with a new software product to see if they like it and that it does what they need. User tasting is essential, even when comprehensive system and release testing have been carried out. The reason for this is that influences from the users working environment have a major effect on the reliability, performance, usability, and robustness of a system. It is practically impossible for a system developer to replicate the systems working environment, as tests in the developers environment are inevitably artificial. For example, a system that is intended for use in a hospital is used in a clinical environment where other things are going on, such as patient emergencies, conversations with relatives, etc. these all affect the use of a system, but developers cannot include them in testing environment. 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 developers 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 from the system developers and deployed in the customer environment. In alpha testing, users and developers work together to test a system as it is being developed. This means that the users can identify problems and issues that are not readily apparent to the development testing team. Developers can only really work from the requirements but these often do not reflect other factors that affect the practical use of the software. User can therefore provide information about practice that helps with the design of more realistic test. Alpha testing is often used when developing software products that are sold as shrink-wrapped system. Users of these products may be willing to get involved in the alpha testing process because this gives them early information about new system features that they can exploit. It also reduces the risk that unanticipated changes to the software will have disruptive effects on their business. However, alpha testing may also be

used when custom software is being developed. Agile methods, such as XP. Advocate user involvement in the development process and that users should play a key role in designing test for the system. Beta testing takes place when an early, sometimes unfinished, release of software system is made available to customer and for evaluation. Beta testers may be a selected group of customer who are early adopters of the system. Alternatively, the software may be made publicly available for use by anyone who is interested in it. Beta testing is mostly used for software products that are used in many different environments (as opposed to custom system which are generally used in a defined environment). It is impossible for product developers to know and replicate all the environments in which the software will be used. Beta testing is therefore essential to discover interaction problem between the software and features of the environment where it is used. Beta testing is also a form of marketing customers learn about their system and what it can do for them. Acceptance testing is an inherent part of custom system development. It takes place after release testing. It involves a customer formally testing a system to decide whether or not it should be accepted from the system developer. Acceptance implies that payment should be made for the system.

There are six stages in the acceptance testing process, as shown in figure 8.11. They are: 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 difficult to define criteria so early in the process. Detailed 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 tests both the functional and non-functional characteristics of the system. They should, ideally, provide complete coverage of the system

requirements. 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 test. It is difficult to automate this process as part of the acceptance Tests may involve testing the interactions between end-users and the system. 5. Negotiate test results it is very unlikely that all of the defined acceptance tests will pass and that there will be no problem with the system. If this is the case, then acceptance testing is complete and the system can be handed over.

6. Reject/accept system this stage involves a