User Acceptance Testing (UAT) – also called beta testing, application testing, and/or end user testing – is a phase of software development in which the software is tested in the “real world” by the intended audience or a business representative.
“The goal of User Acceptance Testing is to assess if the system can support day-to-day business and user scenarios and ensure the system is sufficient and correct for business usage.”
User Acceptance Testing (UAT) does three things for a software development project:
- It measures how compliant the system is with the business requirements.
- It exposes functionality/business logic problems that unit testing and system testing have missed out since unit testing and system testing do not focus much on functionality/business logic testing.
- It provides a means of determining how “done” the system is.
In reality, by the time the UAT starts, contracts have been signed and money has been spent. So,user acceptance testing is not an “accept or reject” proposition any more. UAT is rather more about finding gaps between “how the completed system works” and “how business operational processes are performed”.
A patient portal is a Web-based access point that allows doctors and patients to communicate and share health information remotely, supplementing the ongoing management of the patient’s care. While portals can’t replace an in-office visit, they have many benefits: They are “designed to boost patient’s involvement in their care,” as portals encourage viewing test results and health documentation and can facilitate an ongoing doctor-patient dialogue. Additionally, portals can reduce costly paperwork by serving as online billing and payment centers. As part of the meaningful use Stage 2 requirements, providers must have “at least five percent of their patients using an online patient portal” to get incentive payments.
Do Patient Portals Improve Healthcare?
An important aspect of the software development approach is the Joint Application Development (JAD) process. JAD is used as a technique for developing business system requirements. JAD (Joint Application Development) is a methodology that involves the client or end user in the design and development of an application, through a succession of collaborative workshops called JAD sessions. Chuck Morris and Tony Crawford, both of IBM, developed JAD in the late 1970s and began teaching the approach through workshops in 1980.
The purpose of JAD is to bring together IT and the business community in a structured workshop setting to extract consensus based system requirements. This is accomplished by using a trained JAD facilitator and customized, planned agendas to assist the participants in arriving at complete, high quality requirements. Experience has shown that the JAD process substantially reduces development time, costs and errors.
JAD Basics Video (A must watch): https://www.youtube.com/watch?v=KKUXMghMy9M
The Requirements Traceability Matrix (RTM) is a template spreadsheet that software developers, IT Business Analysts and Testers can use to define and track the life of a requirement. This document maps requirements for design, implementation, and test cases. The purpose of the Requirements Traceability Matrix is to help users trace each requirement and monitor changes made to a particular requirement.
The Requirements Traceability Matrix (RTM) is usually developed in concurrence with the initial list of requirements during the Requirements Analysis phase while documenting the Business Requirements Document (BRD). As the Design Specifications and Test Protocols are developed, the traceability matrix is updated to include the updated documents. Ideally, requirements should be traced to the specific test step in the testing protocol in which they are tested.
RTM as explained by Karl Wiegers: