User Acceptance Testing, Go-Live Readiness
Help Questions
CPA Information Systems and Controls (ISC) › User Acceptance Testing, Go-Live Readiness
A city government is preparing to go live with a payroll system in the final SDLC phase and is using a controlled waterfall methodology with formal acceptance. UAT included parallel payroll runs for two pay periods; totals matched overall, but testers found that overtime premiums are calculated incorrectly for a specific union contract when employees work split shifts. The project sponsor wants to proceed because only one department uses that contract. How should the IT team address this issue before going live?
Close UAT and shift focus to load testing, since payroll accuracy is primarily a performance concern at scale.
Reclassify the defect as low severity because it affects a single department and can be corrected after go-live.
Proceed with go-live and issue manual adjustments only for affected employees, since the overall parallel run totals matched.
Remediate the union-specific overtime calculation, re-run targeted parallel payroll for affected scenarios, and obtain sign-off from payroll and the impacted department before go-live.
Explanation
This question evaluates addressing payroll accuracy defects in waterfall SDLCs, focusing on targeted re-testing. Key facts include overall parallel matches but overtime errors for specific contracts, with sponsor pushing proceed. Option B aligns with best practices by remediating and re-running parallels for assurance. Option A is incorrect as manual adjustments are error-prone; option C is wrong because severity is not low; option D is misguided as accuracy is not performance. For payroll, mandate accuracy across scenarios. Implement parallel runs as UAT gates.
A travel company is in the final SDLC stage for a reservation system using Agile with a release readiness review. UAT passed booking flows, but testers reported that cancellation confirmations are sometimes not generated when a booking includes both flight and hotel components. Customer service warns this could increase disputes and chargebacks. What potential risk identified during testing requires immediate attention?
A project staffing risk, because customer service involvement increases training requirements.
A financial and customer dispute risk, because missing confirmations can lead to chargebacks and operational rework, impacting revenue and customer trust.
A hardware risk, because confirmations depend on printer drivers at customer service desks.
A minor content risk, because confirmations are informational and do not affect actual cancellations in the system.
Explanation
This question assesses risk identification in UAT for Agile SDLCs, emphasizing financial and customer impacts. Key facts include missing confirmations for multi-component cancellations, potentially increasing disputes. Option A aligns with best practices by recognizing revenue and trust risks. Option B is incorrect as hardware is unrelated; option C is wrong because confirmations affect disputes, not just info; option D is misguided as staffing is secondary. In confirmation defects, prioritize to avoid rework. Assess customer impact in risk frameworks.
A manufacturing company is preparing to go live with an ERP procurement module in the final SDLC phase (cutover and deployment) using a traditional waterfall approach with formal stage gates. UAT included role-based testing by buyers and approvers, and the team achieved sign-off; however, a late UAT cycle revealed that delegated approval limits are not enforced for temporary approvers during vacations. The project sponsor wants to proceed and “monitor approvals closely” for the first month. How should the IT team address this issue before going live?
Reclassify the defect as low severity because it affects only a small subset of users and can be corrected in a later release.
Proceed with go-live and use daily exception reports as a compensating control, since UAT sign-off has already been obtained.
Implement a temporary manual policy requiring finance to review all delegated approvals, and defer system remediation until after stabilization.
Treat the issue as a high-risk control gap, remediate approval-limit enforcement, and perform targeted UAT regression on delegated approval scenarios before cutover.
Explanation
This question evaluates addressing control gaps identified late in UAT within a waterfall SDLC, focusing on risk-based decisions before cutover. Key facts include a defect in delegated approval limits not being enforced, discovered post-sign-off, with the sponsor suggesting monitoring instead of fixes. Option D aligns with IT project management best practices by treating it as a high-risk gap and requiring remediation and regression testing to maintain internal controls. Option A is incorrect as exception reports are insufficient compensating controls for systemic issues, per governance standards; option B is wrong because reclassifying severity downplays the control risk, violating defect prioritization; option C is inadequate as manual policies introduce human error, contrary to automation principles in ERP. For similar issues, use a risk register to evaluate defects and mandate re-testing. Ensure stage gates include control validation to prevent post-go-live surprises.
An insurance company is in the final SDLC stage for a claims processing system implemented with a vendor using waterfall with formal UAT exit criteria. UAT completion criteria include: (1) all high-severity defects closed, (2) successful execution of critical claims scenarios, (3) business owner sign-off, and (4) completed cutover rehearsal. UAT found no high-severity defects, but the cutover rehearsal was skipped due to schedule pressure. Which criteria should be prioritized to determine go-live readiness?
Completion of cutover rehearsal and operational readiness, because go-live risk includes data migration, integrations, and rollback capability beyond UAT script results.
The total number of defects found in UAT, because fewer defects indicates lower cutover risk.
Only successful execution of UAT scripts, because cutover rehearsal is an operations activity and can be performed after go-live.
Business owner sign-off alone, because sign-off implies acceptance of all readiness risks.
Explanation
This question examines comprehensive readiness criteria in waterfall SDLCs, beyond UAT to include operational aspects. Key facts include meeting most criteria but skipping cutover rehearsal due to pressure. Option B aligns with best practices by prioritizing rehearsals for migration and rollback, reducing go-live risks. Option A is incorrect as cutover is essential for operations, per deployment planning; option C is wrong because sign-off alone does not cover all risks; option D is inadequate as defect counts ignore operational readiness. For deployments, integrate rehearsals into exit criteria. Develop contingency plans based on rehearsal outcomes.
A logistics company is completing a transportation management system and is in the UAT and go-live readiness checkpoint under a DevOps-oriented SDLC with automated deployments and manual approval gates. UAT results show all functional scenarios passed, but users report that the new route-planning screen is confusing and increases time-to-complete by about 20% compared with the legacy system. Leadership wants to proceed to meet a contract start date. Which criteria should be prioritized to determine go-live readiness?
Whether the deployment pipeline can complete in under 10 minutes, since rapid releases offset any usability concerns.
User experience and operational efficiency for key workflows, ensuring the new process does not materially degrade service levels at go-live.
Whether system documentation is fully updated, since UAT results already confirm the system is acceptable.
Whether the number of UAT defects is lower than the prior project, regardless of impact on user productivity.
Explanation
This question examines go-live readiness in a DevOps SDLC, prioritizing user experience and efficiency over schedule or non-functional metrics. Key facts include functional passes but a 20% increase in task time due to confusing interfaces, with pressure to meet contract dates. Option A aligns with best practices by focusing on operational efficiency to avoid service degradation, ensuring sustainable adoption. Option B is incorrect as deployment speed does not offset usability issues, per user-centric design principles; option C is wrong because documentation alone does not address efficiency, violating holistic readiness; option D is inadequate as defect counts ignore impact, contrary to impact-based evaluation. For similar cases, incorporate usability metrics into readiness criteria. Use feedback loops to iterate on user experience pre-deployment.
A retail bank is at the final go-live decision point for a branch teller system replacement using a phased rollout methodology with parallel run in selected branches. UAT in a pilot branch passed most scenarios, but cash drawer balancing reports do not match transaction totals when a transaction is reversed after end-of-day processing. Operations proposes going live and manually adjusting the report for rare reversals. Based on the user acceptance testing results, what is the most appropriate action?
Proceed with go-live if the pilot branch manager signs off, since pilot sign-off is sufficient for enterprise deployment.
Proceed with go-live because the issue occurs after end-of-day and does not affect real-time customer transactions.
Move the issue to performance testing because reconciliation reports are batch processes and not part of UAT scope.
Defer go-live until the reversal and end-of-day reconciliation logic is corrected and re-tested, because it affects cash controls and financial accuracy.
Explanation
This question tests UAT defect resolution in phased SDLCs, deciding on deferral for financial controls. Key facts include mismatched balancing reports for reversals post-end-of-day, with manual adjustment proposed. Option C aligns with best practices by deferring for fixes to ensure accuracy and controls. Option A is incorrect as timing does not negate impact; option B is wrong because pilot sign-off is insufficient for enterprise; option D is misguided as reconciliation is functional, not performance. For control defects, require full resolution pre-rollout. Validate end-of-day processes in pilot UAT.
A construction firm is at the UAT stage for a project costing system in a waterfall SDLC with formal acceptance testing. UAT scripts were executed, but users did not validate role-based access (e.g., project managers vs. accountants) because test accounts were shared to save time. Go-live is scheduled for next week. How should the IT team address this issue before going live?
Conduct targeted UAT using unique role-based test accounts to validate access and segregation of duties, and require remediation of any access issues before go-live approval.
Rely on the vendor’s standard roles and proceed, since shared accounts demonstrate that users can complete tasks efficiently.
Proceed with go-live because role-based access is an IT security control validated during penetration testing, not UAT.
Defer the access review until the first internal audit after go-live to avoid delaying the schedule.
Explanation
This question evaluates ensuring role-based validation in UAT for waterfall SDLCs, addressing incomplete testing. Key facts include script execution but shared accounts skipping access checks, with go-live soon. Option B aligns with best practices by requiring targeted UAT for access and duties segregation. Option A is incorrect as access is a UAT concern for security; option C is wrong because vendor roles may not fit needs; option D is inadequate as deferring to audit delays controls. For access issues, include role-specific scenarios in UAT. Enforce segregation of duties in readiness reviews.
A media company is in the final SDLC phase for a digital subscription platform built using Agile with a release train. UAT passed purchase and cancellation flows, but testers reported inconsistent tax calculations for customers in one jurisdiction when a promotional discount is applied. The business suggests launching anyway because the issue affects less than 2% of transactions. Based on the UAT results, what is the most appropriate action?
Defer go-live or exclude the affected jurisdiction until tax logic is corrected and re-tested, because incorrect tax calculation can create compliance and financial exposure.
Close UAT and rely on vendor assurance that tax engines are always compliant by design.
Proceed with go-live and classify the issue as a cosmetic defect because the tax is displayed only on the receipt.
Proceed with go-live because the defect rate is low, and correct customer tax amounts through refunds after the next release.
Explanation
This question tests handling compliance defects in UAT for Agile SDLCs, evaluating deferral for financial exposure. Key facts include inconsistent tax calculations with discounts in one jurisdiction, affecting few transactions, with a launch suggestion. Option B aligns with best practices by deferring to avoid compliance risks and ensure accuracy. Option A is incorrect as refunds introduce rework, per efficiency principles; option C is wrong because vendor assurances do not guarantee compliance; option D is misguided as tax issues are not cosmetic. For tax-related defects, prioritize legal compliance in readiness. Conduct jurisdiction-specific testing in UAT.
A financial services firm is at the end of the SDLC (deployment readiness) for a loan origination platform developed under Scrum with a separate release management gate. UAT was executed by loan officers using production-like data; all critical paths passed, but testers discovered that the system allows a loan to be submitted without attaching a required income verification document if the user saves the application as a draft first. The team is considering go-live with this defect logged as “medium” because it occurs only in a specific sequence. What potential risk identified during testing requires immediate attention?
A performance risk, because saving drafts could increase database storage and slow down reporting.
A vendor lock-in risk, because the platform uses proprietary document storage formats.
A compliance and control failure risk, because the workflow can bypass a required documentation control and may lead to noncompliant loan processing.
A user adoption risk, because loan officers may prefer the legacy system if a draft feature exists in the new platform.
Explanation
This question assesses risk identification in UAT for deployment readiness in a Scrum SDLC, specifically compliance risks from workflow bypasses in regulated environments. The key facts involve a defect allowing loan submission without required documents via a draft save, classified as medium despite occurring in a specific sequence, with all critical paths passing. Option A aligns with best practices by recognizing this as a compliance failure that could lead to noncompliant processing, ensuring controls are enforced pre-go-live. Option B is incorrect as it misclassifies the issue as user adoption rather than a control gap, ignoring regulatory compliance principles; option C is wrong because performance is not the primary concern here, per risk assessment frameworks; option D is irrelevant as vendor lock-in does not relate to the defect, violating focused defect analysis. In analogous cases, conduct risk assessments during UAT to prioritize compliance over convenience. Implement change gates that require remediation of control failures before release.
A healthcare provider is completing the deployment phase of a new patient scheduling system built using a hybrid SDLC (waterfall requirements and design, Agile configuration). UAT included scripted tests and a small set of exploratory tests by clinic staff; most defects were minor, but users reported that appointment reminders sometimes display the wrong clinic address for patients who recently changed primary location. The go-live decision is scheduled for tomorrow, and leadership is focused on meeting the regulatory reporting timeline. Which criteria should be prioritized to determine go-live readiness?
Whether the defect backlog is below a numeric threshold set at project kickoff, even if high-severity issues remain open.
Whether critical business workflows and patient-facing communications are accurate, with high-severity defects remediated and re-tested, and sign-off obtained from process owners.
Whether all test cases were executed, regardless of severity, to demonstrate complete UAT coverage.
Whether performance testing results meet targets, since functional defects can be corrected after go-live without impacting operations.
Explanation
This question examines go-live readiness criteria in a hybrid SDLC, emphasizing the need to prioritize critical workflows and defect remediation over timelines or non-essential metrics. Key facts include a defect in appointment reminders displaying incorrect addresses for patients who changed locations, with most defects minor but this one affecting patient-facing communications in a healthcare context under regulatory pressures. Option C aligns with IT project management best practices by ensuring high-severity defects in core processes are fixed and signed off, promoting patient safety and compliance. Option A is incorrect as complete test coverage without severity consideration ignores risk-based testing principles; option B is wrong because a numeric defect threshold overlooks unresolved high-severity issues, per quality assurance standards; option D is misguided as it prioritizes performance over functional accuracy, violating the principle that critical defects must be resolved pre-deployment. For similar situations, use a readiness checklist that weights business impact and stakeholder sign-off. Establish clear exit criteria for UAT to guide go-live decisions objectively.