Acceptance and Delivery CSCI 5801: Software Engineering

Acceptance Testing Complete system is tested against the requirements by client, assisted by developers including documentation, training materials, installation scripts, etc.

Acceptance Testing Black box testing by the client without knowledge of the internal structure The entire system is tested as a whole Emphasis on whether system meets requirements Tests should use real data in realistic situations, with actual users, administrators, and operators The acceptance test must be successfully completed before a new system can go live/replace a legacy system Completion of acceptance test may be a contractual requirement before the system is paid for

Acceptance Testing in Iterative Models Customer will have already tested many parts of the system At the end of each iteration During user testing in XP Problems and suggestions for improvement will have been incorporated Must still be an acceptance test of the final version before it is released Customer is ultimately interested in system as a whole

Acceptance Testing Good acceptance testing requires careful planning For each functional requirement: Describe scenario to customer Allow them to accomplish scenario on system For each non-functional requirement: Create stress test that describes “worst case scenario” within bounds of requirements Explain and demonstrate system passes stress test

Acceptance Testing Acceptance testing ultimately controlled by customer During one test, customer may want to follow another branch (“what would happen if I…”) Role of developers is to provide assistance when necessary Introduce scenario, its goals and major steps Give customers guidance to accomplish steps when needed

Testing and Release Stages Alpha Testing: Clients operate the system in a realistic but non-production environment Example: Prof. Bodnovich uses system pretending to be employers/students Beta Testing: Clients operate the system in a carefully monitored production environment Example: Select employers and students are allowed to use the system, providing feedback on its usability

Testing and Release Stages Parallel Testing: Clients operate the new system alongside the old system with same data and compare results Can be expensive and may take months! Requires two of everything (staff, equipment, etc.) Requires software to control changeover (do not mail two sets of payments, etc.) Requires automated scripts to compare results Ideally, the new system will be brought into production incrementally

Other Deliverables Everything needed to install software Help systems Configuration files Data files needed for system operation An installation program or shell script to install the system on target hardware Help systems Training materials

Help Systems Users need many routes to find information (people learn in different ways) Index by many terms Examples Tutorials Help systems need to be tested with real users (just like other parts of system) Tradeoffs A good help system requires a major commitment (time, expense, difficulty) A good help system saves user time and support staff effort

Training Providing users with knowledge necessary to fulfill role in system Types of training: One on one training sessions for critical users Classes for large groups of every day users On-line tutorials for other users Help materials

Help and Training Systems Different materials (at different levels of detail) for different users Different types of users (faculty, advisors, students in Banner) System maintenance Other trainers… Different skill levels need different types of training Skilled users work from the conceptual model, relating the system to a task they already know well Less-skilled users prefer cookbook sets of instructions Occasional users will forget complex details, but remember general structure, so will need reminders when requested