Follow and Support me on these Media Channels
I attended an NARUG Lunch-n-Learn educational event presented by ROI's Mariano Botto, Principal of MMB Rapid Consulting. Mario's topic was Tips and Tricks for Configuration Audits, which focused on significant issues that he found during audits of healthcare organizations' Revenue Cycle operations.
Many of the examples he provided illustrated how organizations were losing a significant amount of revenue, due to errors in processing billings and claims. It was evident to me that the root cause of many of these issues was due to inadequate User Acceptance Testing (UAT).
Healthcare organizations and their patients pay a heavy price when problems are found in production, rather than in the initial stages of the software development lifecycle.
The cost of providing healthcare services often increases due to lost revenue and increased operational costs.
Healthcare executives, application software development companies, and IT implementation/consulting firms that invest in a User Acceptance Test program, are rewarded with increased revenue, cost savings, and a host of other direct and indirect benefits that a quality UAT program delivers.
User Acceptance Testing (UAT) is an ongoing program performed by internal and external stakeholders to validate and certify that a system or software application product is fit for use in a production environment.
UAT is performed in the final phase of testing after functional, integration, and system testing has been completed.
UAT engages the customer's key business stakeholders: executives, directors, managers and operational team members, partners, vendors, and other key members who understand every aspect of the business application.
Thomas Hamilton's article What is User Acceptance Testing (UAT)? provides a good overview of the UAT process. In short, UAT is performed to ensure that a software deliverable functions according to accepted and documented development standards and business specifications.
From a software development testing perspective, I'm interested in monitoring application build tests, interface testing, application integration tests, and quality control test results.
Collaboratively Managed Business Requirements Process
Sets of functional requirements that are developed and maintained by collaborating teams consisting of IT vendors, business Subject Matter Experts (SME's) and third-party business and technology implementation consultants, are often a hallmark of a successful software development project.
Consider a three-legged stool; all three legs must work in concert to support the weight of a person who sits on the stool.
A team consisting of SMEs from the IT application vendor, customer, and IT implementation project consultants, working collaboratively, can support the needs of stakeholders and end-users.
Key to the management of business requirements are Business Systems Analysts (BSAs) and Business Analysts (BAs). BA & BSAs are laser-focused on business policies, best practices, procedures, workflows, and stakeholder needs and requirements.
They are responsible for eliciting, analyzing and documenting business functional and non-functional requirements that will drive the software application development project and ongoing Quality Assurance (QA) testing program.
Providing QA team members with access to documented functional requirements is an absolute requirement. A QA team cannot determine if an application is Working as Designed (WAD), if it has no approved and documented business requirements to reference.
Look for the presence of a formalized UAT program, managed by experienced Software Quality Assurance professionals.
The QA program's software test plan should provide an end-to-end UAT program, staffed by experienced QA professionals, backed by the full support of senior program executives and managers.
Successful projects engage one or more teams of Quality Assurance (QA) professionals to manage every aspect of a software development testing program.
QA professionals with domain and application knowledge and experience will provide a better Return on Investment (ROI), as compared to QA professionals that are generalists.
End users that are transitioning to a new software business management application, must be oriented to how the new application will manage a recurring business process, like submitting payment for an invoice.
Quality Assurance teams that represent the interests of internal and external business end users, must also be oriented as to a new application's capabilities, features, functions, etc. The reason for this is simple: The degree of knowing how an application is supposed to behave and functional, relative to a business organizations policies, procedures, and practices, determines the degree of confidence in the pass or fail status of a UAT test result.
Providing QA teams with access to applications that report end-user findings (change requests, application defects, etc.) empowers the team to improve the overall development process and find additional defects that may have yet to be encountered by stakeholders.
New application orientation and end-user experience information enables a QA team to make determinations as to whether a new application in development is Working as Designed (WAD).
Projects that have a high degree of collaboration among stakeholders and end-users experience few surprises during a UAT event.
As members of the development team continuously share needs, requirements and preliminary test results throughout the development project, issues and concerns are addressed, prior the product's release for production go-live.
A principal, critical goal of an application software development project is achieving the milestone that all critical business internal and external stakeholder needs, requirements and expectations have been successfully met, based on documented end-user satisfaction measures.
Successful projects must also meet timeliness of delivery and cost metrics. These project success measures, however, do not negate the impact of a project that fails to meet end user needs and expectations.
