UAT and BA Documentation Interview Questions for Business Analytics

System testing is done by the QA team to verify that one system works against its functional and non-functional specifications. SIT (system integration testing) checks that connected systems exchange data correctly, such as CRM to billing to payment gateway. UAT (user acceptance testing) is done by business users to confirm the solution supports real business processes and is ready for go-live. UAT asks whether this is fit for our business, not just whether it matches the specification.

A test scenario is a high-level statement of what to test, usually derived from a business process or user story, such as Customer applies a discount coupon at checkout. A test case is a detailed, executable set of steps with preconditions, test data, expected result and actual result, such as applying an expired coupon to a 1,000 rupee cart shows an expiry message. One scenario usually produces several test cases covering positive, negative and edge conditions.

UAT sign-off is the formal acceptance by the business that the solution meets agreed requirements and is fit to go live, often with a list of known open defects and agreed workarounds. It should be given by the accountable business owner or product owner, not by the IT team or the BA. The BA prepares the evidence: test execution summary, defect status and traceability to requirements. Sign-off is recorded in writing, usually by email or in the test management tool.

Severity describes the impact of a defect on the system or business, such as critical when payments fail or low for a spelling mistake. Priority describes how urgently it must be fixed, which is a business decision. They can differ: a wrong company logo on the login page is low severity but high priority before a launch, while a crash in a rarely used year-end report may be high severity but lower priority if the report is months away.

Alpha testing is done internally, by employees or a selected group, in a controlled environment before the product is released to outsiders, and aims to catch major issues early. Beta testing releases the product to a limited group of real external users in real conditions to gather feedback on usability, performance and missing features before general release. For a mobile app, beta often uses store testing tracks, and feedback is fed into the final release backlog.

Release notes describe what changed in a specific release: new features, enhancements, fixed defects, known issues and any actions users must take. They are short and version-specific. A user manual or user guide explains how to use the whole system to complete tasks, with step-by-step instructions and screenshots, and is updated as the product evolves. BAs often review both, because users rely on them in the first weeks after go-live.

Test case ID: UAT-LOGIN-03. Precondition: registered customer with a verified mobile number. Steps: 1. Open the app and enter the registered mobile number. 2. Tap Send OTP. 3. Enter the 6-digit OTP received by SMS within 3 minutes. 4. Tap Verify. Expected result: the customer lands on the account dashboard, and the login is recorded in the activity log. Related negative cases: wrong OTP shows an error, and three wrong attempts lock login for 30 minutes.

A UAT test plan defines how acceptance testing will be run. It covers scope and out-of-scope items, business processes to be tested, entry and exit criteria, roles such as testers, UAT lead and sign-off authority, test environment and test data, schedule and cycles, defect management process with severity definitions, communication and reporting, and risks. The BA usually drafts it with business owners so testers know exactly what they are accepting and when.

Entry criteria are conditions that must be met before UAT starts, for example system and integration testing completed, no open critical defects, UAT environment and test data ready, test cases reviewed and testers trained. Exit criteria define when UAT is complete, for example 100 percent of critical test cases executed, at least 95 percent passed, no open critical or high defects, and workarounds agreed for remaining medium ones. Clear criteria stop arguments about readiness near go-live.

It is a regression: the fix for one defect broke existing functionality, which usually means changes were not impact-analysed and there is no regression suite. Log it as a new high-priority defect linked to the fix. Agree with the team that every UAT build comes with release notes listing the changes, and that QA runs an automated or core manual regression pack before handing the build to business testers. Also add the broken flow to the UAT regression checklist.

A typical SRS includes purpose, scope and definitions; overall description with users, operating environment, assumptions and constraints; functional requirements, each with a unique ID, description, priority and acceptance criteria; external interface requirements for UI, APIs and integrations; non-functional requirements such as performance, security, availability and compliance; data requirements; and appendices with diagrams and a traceability reference. Each requirement should be clear, testable and traceable to a business need.

A data dictionary is a catalogue of data elements used in a system or report: field name, business definition, data type, length, allowed values, mandatory or optional, source system, owner and example values. A BA maintains it so business users, developers and testers use one definition, for example what counts as an active customer. It prevents mapping errors in integrations and migrations, speeds up testing and reduces disputes about why reports do not match.

A RAID log tracks Risks, Assumptions, Issues and Dependencies for a project. Each entry has an ID, description, owner, impact, status, mitigation or action, and due date. A risk is something that may happen, an issue is something that has already happened, an assumption is believed true but unverified, and a dependency is something the project needs from others. A BA uses it to record requirement assumptions and dependencies, and reviews it weekly so nothing is silently forgotten.

Situation: a new developer built a GST calculation from an old FRD version, and the error was caught only in UAT. Task: fix the defect and prevent repeats. Action: I moved all requirement documents into one shared space with version history, added a change log and status labels such as draft or approved, and linked each user story to the latest approved section. Result: in the next two releases we had no defects caused by outdated specifications.

A defect is logged as New with steps, expected and actual results, and evidence. It is reviewed in triage and moves to Open or Assigned, or to Rejected, Duplicate or Deferred. The developer fixes it and marks it Fixed or Ready for retest. The tester retests: if it passes it moves to Closed, and if not it is Reopened. Tracking status and age helps the UAT lead report readiness and spot defects stuck too long.

Escalate immediately to the business sponsor with the impact: each day without testers delays sign-off and go-live. Ask for named testers with protected time, even part-time. Meanwhile, prepare so no time is lost: finalise test cases, check the environment and data, and plan a short tester briefing. If testers cannot be released, propose re-planning UAT dates rather than letting IT or the BA test on the business's behalf, because acceptance must come from the users.

Run a joint triage with the business owner, QA and development. Compare each item against the signed-off requirements and acceptance criteria. Real defects stay in the defect log; items not covered by requirements are reclassified as change requests and prioritised separately through change control. Keep the tone neutral so users do not feel dismissed. Also review why the gap happened, for example prototypes were not shown early enough, and fix that for the next release.

Go back to the requirement and acceptance criteria. If the system matches the agreed requirement, the developer is right, and the business need is a change request. If the requirement is unclear or the design misread it, it is a defect, and the requirement wording should be fixed. Discuss it in triage with both parties, using examples. Either way, close the loop with the tester so they understand the outcome and keep trusting the process.

Identify which documents are actually used: usually a product overview, process maps, business rules, data dictionary and integration details. Update those first rather than everything. Make documentation part of the Definition of Done, so a story is not complete until related docs are updated. Keep living documents in a shared wiki with owners and last-reviewed dates, and archive outdated files clearly. Test the result by having a new joiner use it during onboarding.

Title: Invoice applies 12 percent GST instead of 18 percent for service items. Environment: UAT, build 2.4.1. Steps: create an order with service item SRV-101 at 1,000 rupees for a customer in Maharashtra and generate the invoice. Expected: CGST 90 and SGST 90, total 1,180. Actual: CGST 60 and SGST 60, total 1,120. Severity: high, as it affects tax compliance. Attachments: invoice PDF and screenshot. Linked requirement: FR-TAX-07.

Plan: agree scope, entry and exit criteria, testers and schedule with the business owner. Prepare: write scenarios and test cases from requirements, set up the environment and test data, and brief testers. Execute: run test cases in daily sessions, log defects with evidence and hold a daily triage. Monitor: report progress, pass rate and open defects by severity. Close: check exit criteria, get the business sign-off with known issues documented, and hold a short lessons-learned review.

Situation: a new claims system passed QA, but in UAT a claims officer tried a real scenario with two policies on one claim. Task: as BA I had to assess and resolve it quickly. Action: I confirmed the requirement never covered multi-policy claims, quantified that 8 percent of claims were affected, and agreed a manual workaround while the change was built. Result: we went live on time, delivered the fix in the next release, and I added real case samples to future test design.

Start from the test cases and list the data each needs: customer types, product variants, edge values and historical records. Decide whether to use masked copies of production data, synthetic data or both, because real personal data must be anonymised under data protection rules such as the DPDP Act. Prepare data for negative and boundary cases, keep a refresh plan for repeated cycles, and assign owners. Poor test data is one of the most common causes of blocked UAT days.

A cutover plan is an hour-by-hour runbook for moving from the old system to the new one: freezing old transactions, final data migration, validation checks, configuration, smoke testing, switch-over and a rollback plan with clear decision points. A go-live readiness checklist confirms that UAT is signed off, users are trained, support and hypercare are staffed, data is reconciled, and communications are sent. The go or no-go meeting reviews this checklist before the cutover starts.

Operational acceptance testing (OAT) checks whether the operations and support teams can run the system in production: backup and restore, failover, monitoring and alerts, batch job scheduling, performance under expected load, security patching and support procedures. UAT checks whether business users can do their work. Both are needed before go-live. A system can pass UAT and still fail in production if nobody tested that the nightly batch finishes before the business opens.

Confirm the impact and reproduce it quickly. Work with development to estimate a fix and its regression effort. Then present options to the business owner with risks: fix and do targeted retesting before go-live, go live with a temporary workaround or manual process, go live with the affected feature switched off, or delay. The decision belongs to the business, documented at the go or no-go meeting. Never hide a critical defect to protect a date.

Explain the risks in business terms: without UAT, there is no evidence that real processes work, and production defects cost far more to fix and can affect customers and compliance. Offer alternatives: a shortened UAT covering only critical business flows, parallel running with the old system, a phased rollout to one branch or user group, or extended hypercare. If the sponsor still decides to skip it, record the decision and accepted risks formally.

Situation: two days before the go-live of a loyalty points system, UAT showed points were doubled for refunded orders. Task: give a clear recommendation at the go or no-go meeting. Action: I presented the defect, estimated financial exposure at about 6 lakh rupees a month and showed the fix needed three days including regression. Result: the sponsor agreed to a one-week delay. The release went live cleanly, and the sponsor later cited the decision as an example of good risk management.