BA Academy — self-paced module
By the end of this module, you will be able to:
The build is underway or complete. Before anything reaches production, the project enters its confirmation work: demonstrating what was built, testing it from every angle, and securing the client's formal agreement that it is ready. In the generic lifecycle this course uses, this is the Test phase, sitting between Build and Deploy. It is also, for many BAs, the phase where they are most visibly in charge: quality confirmation is BA home territory.
Testing begins with showing. Demos are how the team regularly proves progress and collects feedback, and the BA is very often the person driving them (as Module 10 noted, the sprint review is frequently your show).
Four practices separate a confident demo from a fumbling one:
| Sprint Demo | End-to-End Demo | |
|---|---|---|
| Purpose | Showcase completed user stories from the current sprint | Validate complete functionality across multiple sprints |
| Audience | Internal team, product owner, some stakeholders | Broader stakeholder group, including business leaders and end users |
| Focus | Features developed; demonstrate functionality, gather refinement feedback | Full integrated features; cover the end-to-end process |
| Frequency | End of each sprint (1-4 weeks) | Before major releases, or after several sprint cycles |
| Goal | Validate the sprint's outcome; ensure alignment with business requirements | Ensure the product meets business objectives and is ready for release |
The distinction matters because the two demos answer different questions: "did we build these stories right?" versus "does the whole thing hang together as a business process?" Confuse them and you either bore executives with story-level detail or skip the integration proof the release decision needs.
Two words that sound alike and mean crucially different things:
A solution can pass verification and fail validation: built exactly to spec, and the spec missed the point. This is why BAs sit at the heart of testing: you carry the context of what stakeholders actually meant (you were in the room in Module 3), so you can catch the gap between "matches the ticket" and "solves the problem." Keep both questions alive through every testing cycle.
A thorough QA process solidifies trust and increases user adoption. BAs play a critical role in ensuring a Salesforce implementation's quality: validating that the system meets business needs, functions correctly, and delivers value. The groundwork starts long before test execution:
Here is the mindset shift that makes testers valuable: the best way to identify potential issues is to actively look for ways the system can fail. Do not just verify that things work as expected; attack the solution with incorrect inputs, unexpected actions, and extreme use cases:
The goal is to uncover weaknesses and edge cases real users will eventually hit, on your schedule instead of theirs.
Salesforce's layered permissions (Module 7) mean the system behaves differently for every role, so testing must cover all perspectives:
Testing across roles is how you catch security gaps, permission issues, and missing functionality that single-persona testing sails past. Practically, this means logging in as test users for each persona: your Module 7 security matrix doubles as the persona list.
Structure every story's tests in three bands:
Positive testing (expected scenarios): create, update, and delete records as intended; confirm dashboards and reports display correct data; verify automations trigger under normal conditions.
Negative testing (error handling): enter incorrect or incomplete data: does the system prevent bad entry? Delete a restricted record: does the system stop it? Access a report without permission: is it blocked?
Edge case testing (unusual scenarios): import 10,000+ leads at once: does the system slow or fail? Assign the same lead to multiple users: duplication or overwrite issues? What happens when an approval request sits pending too long?
These bands ensure the system handles the unexpected gracefully instead of breaking. If the structure feels familiar, it should: it mirrors the acceptance criteria formats from Module 4, where you learned to write negative scenarios into the definition of done. Testing is where those criteria get cashed.
Return to the WellCare Solutions case study (Module 4). You wrote user stories and acceptance criteria; now design their tests. Two worked solutions:
Story: Lead Tracking (sales rep tracks leads and sees their stage):
Story: Contract Renewal Alert (rep notified 90/60/30 days before expiration):
Study the pattern: every acceptance criterion generated at least one positive test, and the negative and edge tests came from asking "how could this go wrong?" against each criterion. That question, asked systematically, is test design.
Six testing types appear on a typical project, each with an owner:
| Test Type | Responsibility | Description |
|---|---|---|
| Unit testing | Developer | Test functionality as it is developed, improving until it fulfills the predetermined requirements |
| QA testing | QA team | Conducted in a dedicated QA environment; verifies the solution works as expected technically and functionally |
| Systems Integration Testing (SIT) | Technical Architect | Tests interactions between systems end-to-end; ensures all components integrate correctly |
| Data validation | Client team, guided by the delivery team | Ensures migrated data meets requirements and design: structures, calculations, and values functioning correctly. Completed before UAT begins |
| User Acceptance Testing (UAT) | End users | Users test the application against business-case scenarios to confirm it aligns with requirements and design |
| Regression testing | Everyone | Verifies previously tested functionality still works after fixes, configuration changes, or new functionality |
Two rows deserve underlining. Data validation must finish before UAT starts: testers who find garbage data stop trusting the system, and UAT becomes an argument about data instead of functionality. And regression testing belongs to everyone, always: every fix is a chance to break something that used to work (recall the order-of-execution interactions from Module 11).
Test scripts support a consistent and thorough testing process: they guide users through a predefined series of steps to verify the system functions as expected, ensure comprehensive coverage, and document accurate results.
The key components of a test script:
Write test steps for a person who has never seen the system, because in UAT, that is exactly who executes them. "Create a lead" is not a step; "Click New on the Leads tab, enter the required fields, click Save" is.
Testing is a cycle, not a gate: from documented requirement, to acceptance criteria (the shared definition of done), to test scripts written in partnership with the client, to tests performed, feedback given, changes made, and tests reinitiated: the cycle continuing until acceptance criteria are met. Throughout, the Requirements Traceability Matrix records results, linking each requirement to its test scripts and outcomes so nothing slips through the cracks. The BA typically helps plan those testing activities, identifying test scripts and test data, and keeps the RTM current as evidence accumulates. When the go/no-go conversation arrives (Module 14), that RTM is the receipt you hand the decision-makers.
UAT is end-user testing performed in a sandbox or test environment to verify that a project or enhancement works as intended, and that what was originally requested is actually being delivered. It is the last stage before go-live: after the technology team's own QA passes, the business gets its hands on the system, executes test cases, and rules pass or fail. In the words of a Salesforce business analysis director: think of it as the last chance, the final due diligence before production, and the formal certification that the system is sufficient for business use.
UAT matters for three reasons:
And a fourth, sobering reason from the practitioner interview: UAT is where the business catches what everyone else missed. The BA is imperative here precisely because BAs understand the functionality and the intention of the system: they carry the project context from requirements onward, and their detail orientation uncovers problems a testing specialist parachuted in at the end would never see. UAT is not uniquely a Salesforce practice, either: any technology project ends with the business saying "yes, this works, we are ready."
Drawn from both the source curriculum and practicing BA leaders, the BA typically:
One human note from the source material worth taking to heart: testers might be brand new to the system. Patience is key. A UAT tester who feels stupid stops reporting problems, and silent testers are how broken systems reach production.
The full path, from readiness to sign-off:
From the practitioner playbook, the prep that makes UAT succeed:
Preparation is the recurring theme: in the words of the practitioner interview, tons of prep leads to a successful UAT. By the time testers touch keyboards, a well-run UAT is mostly already decided.
The single most contentious distinction in any UAT, so define it before testing starts:
Without this line, UAT becomes a wishing well: every tester's "wouldn't it be nice if..." lands as a defect, the fix list balloons, and go-live slips. With the line, good ideas are captured respectfully (in the backlog) without holding the release hostage. Expect to invoke this distinction weekly, and expect pushback: the requirement documentation and RTM you have maintained since Module 4 are what make the conversation factual instead of political.
Issue-tracking discipline: BAs assist in tracking issues using the project's predetermined processes and tools; resolved issues are always retested; and all fixes happen in development environments following standard development processes: nobody hot-fixes production during UAT.
A bug report is a communication artifact, and its quality determines fix speed. Best practices:
And while fixing bugs is usually the developer's task, the BA adds value before a bug ever reaches a developer: attempt to reproduce the issue consistently; verify user permissions and role-based access (an enormous share of "bugs" are actually permission behavior working as designed: your Module 7 knowledge earns its keep here); double-check the user's steps and conditions; and document additional evidence. A BA who filters and enriches bugs this way saves the team days of ping-pong.
The standard prioritization scale:
| Severity | Description | Examples |
|---|---|---|
| Critical | Blocks a test script or scenario from progressing; without resolution, the configuration cannot be accepted into production | Security or access failures; entire application, component, or function not working; severe data loss or corruption; a crucial requirement unaccommodated |
| High | Major issue with source data or calculations; without resolution, the system cannot be accepted into production | Incorrect data values versus the source; a non-critical process not matching current day-to-day operations; data validation fixes needed for in-flight data |
| Medium | Does not conform to requirements, but a suitable workaround exists; acceptable to release into production | Minor issues not blocking script execution; non-critical fields not showing; permission and access quirks |
| Low | Minor issues with no impact on system usage | Format inconsistencies; report layout details like color and formatting |
| Enhancement | A change request outside predefined scope and requirements; does not affect functionality or data | Requests to change the business process from what was defined during discovery |
Severity drives the go-live conversation directly: criticals and highs block; mediums ship with workarounds and a fix plan; lows join the post-launch backlog. Which is exactly where the next module in the lifecycle picks up: deciding, with evidence in hand, whether you are ready to go live (Module 14).
8 questions. Answer at your own pace, then check the explanation for each.
Nice work. Review any question again using the menu (top right), or move on.
Continue to Module 13: BA as Trainer: Enablement & Change Communication →