Certified-Business-Analyst Practice Test Questions

Explanation:

A high number of failed test cases during User Acceptance Testing (UAT) typically points to a fundamental disconnect between what was built and what the users expected. The most likely root cause among the options is a failure in the requirements communication process.

Why C is correct:
Missing test script details is a symptom of incomplete or ambiguous requirements. The test scripts are derived directly from the requirements and acceptance criteria. If the test scripts lack detail (e.g., specific data to use, precise steps to follow, or clear expected results), it means the original requirements were also vague. This vagueness allows for misinterpretation by the development team, leading to a product that doesn't meet the users' unstated or poorly defined needs, resulting in many test failures.

Why A is incorrect:
While missing test org access would prevent testing from happening at all, it would not cause test cases to fail. It would cause them to be blocked or not executed.

Why B is incorrect:
Missing test result details refer to poor documentation after a test has been executed. It doesn't explain why the test failed in the first place. The failure reason is the actual defect, not the lack of documentation about the failure.

Key Concept:
This question tests the BA's understanding of the direct link between Requirements Quality and Testing Outcomes. Vague requirements lead to ambiguous acceptance criteria, which in turn lead to poorly defined test scripts. When test scripts are not detailed and precise, the developed solution is likely to be incorrect, causing a high rate of UAT failures. The BA is responsible for ensuring requirements are clear and detailed enough to be tested effectively.

Explanation:

🎯 Role of the Business Analyst in Prioritization
When a development team is unsure which user story to start, the Business Analyst (BA) plays a key role in providing the contextual information needed for effective prioritization and decision-making during Sprint Planning or Backlog Refinement.

B. Identify dependent components (Most Relevant Action)
Identifying dependent components is critical because technical and functional dependencies are a non-negotiable factor in determining the order of work.

Dependency Blockers: A team cannot successfully start or finish a user story if it relies on another piece of configuration or code that has not been completed.
Sequencing: The BA facilitates the discussion to determine the correct sequence. For example, a user story to "Display a custom field on a report" depends on a prior story to "Create the custom field on the Account object." The custom field story must be prioritized first.

The BA works closely with the technical team and Product Owner to identify these dependencies and ensure that prerequisite stories are scheduled for the sprint.

❌ Why Other Options Are Less Appropriate
A. Verify acceptance criteria
Verifying or refining acceptance criteria is a standard part of Backlog Refinement (Grooming) that ensures a story is ready for a sprint (meets the Definition of Ready). While necessary, it does not, by itself, determine the order of work compared to other ready stories. Prioritization is based on value, risk, and dependencies, not just criteria clarity.

C. Delete the definition of done
This is incorrect. The Definition of Done (DoD) is a critical, agreed-upon checklist of quality standards (e.g., Code reviewed, UAT complete, performance tested) that every story must meet to be considered "finished." Deleting it would remove quality control and drastically increase project risk, making it an entirely inappropriate action.

Explanation:

✅ Why B. Facilitate workshops with stakeholders is correct
Facilitating workshops allows the Business Analyst to guide a collaborative, structured conversation that uncovers:

Root causes of service issues
Stakeholder priorities and perspectives
Process gaps and improvement opportunities
Alignment on next steps and ownership

Workshops create space for cross-functional dialogue, enabling stakeholders to co-create solutions based on customer feedback. This approach is especially effective when feedback is broad or complex, and when multiple teams (e.g., support, sales, IT) are involved.

By using facilitation techniques like journey mapping, pain point analysis, or impact-effort grids, the BA helps the team move from problem awareness to actionable improvements.

❌ Why not the others?
❌ A. Analyze CSAT numbers with stakeholders to identify major pain points
While CSAT (Customer Satisfaction) scores are useful for quantifying sentiment, they don’t explain the “why” behind the issues. Numbers alone lack context and nuance, and may not reflect process-level insights. They’re best used within workshops, not as a standalone method.

❌ C. Review support team feedback survey results with stakeholders
Support team surveys provide internal perspectives, which are valuable — but they may be biased or incomplete. They don’t capture the full customer experience or cross-team dependencies. Reviewing them is helpful, but not sufficient for driving meaningful change without broader stakeholder engagement.

📘 Reference
Explore this in the Trailhead module:
📘 Business Analyst Collaboration

Explanation:

When a Business Analyst joins a new Salesforce project at Universal Containers (or any client), the very first document that provides a complete high-level overview of why the project exists and what it will deliver is the Statement of Work (SOW).
The SOW is the project-specific contract document that typically includes:

- Project goals and objectives
- Background and business justification
- High-level scope (in-scope / out-of-scope)
- Key stakeholders and roles (client sponsor, program manager, etc.)
- Deliverables and milestones
- Assumptions, constraints, and risks
- Timeline and budget summary

This is exactly what the BA needs before kickoff to prepare for discovery, align on vision, and start planning workshops.

Why the other options are wrong:
A. System Requirements Specification (SRS)
This is a detailed technical document created later in the project (usually after discovery and requirements gathering).
It contains functional/non-functional requirements, use cases, data models, etc.
→ It does not exist yet at “prior to project kickoff” stage.

C. Master Service Agreement (MSA)
The MSA is the overarching legal contract between the client and the consulting partner that covers payment terms, IP rights, liability, confidentiality, etc.
It applies to all projects under the partnership but contains zero project-specific details (no goals, scope, stakeholders, or timeline for this Universal Containers project).

References:
Trailhead – “Prepare for a Project Kickoff” (Business Analyst Fundamentals)
→ “Review the Statement of Work (SOW) to understand scope, objectives, and stakeholders.”

Trailhead – “Project Documentation”
→ SOW = “Defines what will be done, by whom, and when.”

Official BA-201 Exam Guide → Section 1: Customer Discovery (18%)
→ “Interpret project charters and statements of work to align on vision and scope.”

PMI & Salesforce Partner Best Practices
→ Every Salesforce implementation partner (Accenture, Deloitte, Slalom, etc.) shares the SOW first with the incoming BA.

Bottom Line:
B. Statement of Work (SOW) is the only document that gives the BA the full picture of the project’s goals, stakeholders, background, and scope before kickoff.

Explanation:

In an Agile environment using Scrum (implied by "sprint," "sprint demo," and "backlog"), the contents of a sprint are determined during sprint planning. During this meeting, the entire team, guided by the Product Owner and Business Analyst, decides which items from the prioritized backlog can be completed within the sprint's capacity.

A. Prioritize the sprint backlog with stakeholders: The fact that an "important" item requested by a key stakeholder (marketing team) was missed from the deliverables indicates a breakdown in the prioritization process. The BA likely failed to ensure that the marketing team's needs were accurately prioritized, clearly communicated as critical, and successfully included in the sprint commitment. The BA should have ensured all stakeholders were aligned on the sprint goals and the committed deliverables, making the missing automation a visible gap during planning or the demo itself.

Why other options are incorrect
B. Calculate the sprint capacity correctly: While capacity planning is essential, incorrect calculation of capacity would lead to incomplete work or scope creep, not necessarily the omission of a known, important feature from the sprint plan altogether.

C. Create a burndown list of sprint tasks: A burndown chart is a tracking mechanism used during the sprint to monitor progress. It does not affect which items are selected during sprint planning or how they are prioritized.

Explanation:

Even though the question oddly mentions “in the middle of a sprint” and Kanban together, the key point is:

Kanban = continuous flow, work is pulled based on priority and capacity, not fixed-time sprints like Scrum.

When a new important item comes in:
The BA should add it to the backlog.
Reprioritize with the Product Owner / stakeholders so that this new work sits appropriately in the queue.
The team will pull it next when they have capacity and WIP (Work In Progress) limits allow.

That matches Option A:
Ask the team to reprioritize the backlog and work on the item at the top.

Why not B or C?
B. Ask the team to commit to the work for the next sprint.
“Next sprint” is a Scrum concept, not Kanban.
Kanban isn’t about committing to future sprint scopes; it’s about continuous flow and prioritized pull.

C. Ask the team to pivot and complete the work immediately.
This breaks WIP limits and disrupts flow.
In Kanban, you don’t constantly interrupt existing work unless it’s a true emergency. Instead, you reprioritize and let the team pull the new top item when capacity frees up.

So, staying true to Kanban principles, the BA should reprioritize the backlog and let the team pull the new top-priority item when they can → A.

Explanation:

When a Business Analyst (BA) is unsure about the level of testing or user acceptance testing (UAT) needed for a story — especially one that involves backend functionality like a trigger — the best practice is to collaborate with stakeholders (end users, QA team, and developers) to define clear UAT requirements.

User Acceptance Testing (UAT) ensures that the solution meets business needs, not just that it works technically.
So, the BA should:

- Engage the stakeholders and product owner to understand how this trigger affects business processes.
- Define acceptance criteria and UAT test cases that validate the trigger’s impact from a user perspective.
- Work with the development team to ensure appropriate technical testing (like unit tests) is also planned, but not mix it with UAT responsibilities.

This aligns with the BA’s role as a bridge between technical and business teams.

❌ Why the Other Options Are Incorrect:
A. Run all Apex tests using change set validation
→ This is a developer or admin activity that validates code before deployment. It’s part of unit testing or deployment validation, not UAT.
The BA is not responsible for running Apex tests.

C. Perform testing on all objects in the trigger
→ This is a technical validation step, not part of UAT. The BA doesn’t perform or design technical tests; they ensure business acceptance testing is defined and coordinated.

🔍 Reference:
Trailhead: User Acceptance Testing in Application Lifecycle Management
Salesforce Business Analyst Certification Guide: UAT planning is a key BA responsibility to ensure business needs are met.

Explanation:

The sales manager wants to customize the “Recently Viewed” list view, but in Salesforce, this particular list view is system-generated and not editable. The business analyst (BA) needs to handle this thoughtfully — not by jumping straight to technical changes, but by:

- Documenting the user’s desired outcome — what the sales manager is actually trying to achieve (e.g., “see specific fields by default on the first list view they use”).
- Researching the impact and feasibility of possible solutions — for example, whether an alternative list view can be set as default, or if a user training or process update would better meet the need.

This ensures that the BA understands the business intent and evaluates safe, compliant, and maintainable options before any configuration changes are proposed.

❌ Why not A or B?
A. Recommend that the user submit a ticket related to the field creation
The issue isn’t with field creation — the field already exists.
The problem is about list view customization and user permissions, not missing technical support.

B. Research AppExchange solution that offer customization options
Overkill for such a simple usability issue.
You don’t need to introduce third-party apps for something that’s governed by standard Salesforce behavior.

📘Reference
According to Salesforce BA best practices (as outlined in Salesforce Certified Business Analyst study materials and Trailhead modules such as “Analyze and Document Requirements”), a BA should first clarify the user’s intent, document the desired outcome, and then analyze the impact and feasibility of any requested change before recommending or implementing a solution.

Explanation:

✅ Why C. Current state analysis is correct
Before translating functional requirements into user stories, the Business Analyst should conduct a current state analysis to:

- Understand how processes currently work
- Identify pain points, inefficiencies, and gaps
- Gather feedback and context from stakeholders
- Clarify dependencies and constraints that may affect implementation

This document captures the real-world operational landscape and helps the BA validate whether the preliminary requirements are complete, feasible, and aligned with business needs. It’s a critical input for refining user stories and ensuring that future-state designs are grounded in reality.

It’s a critical first step in ensuring that the business needs are clearly understood and addressed in the user stories.

❌ Why not the others?
❌ A. Stakeholder analysis
This document identifies who the stakeholders are, their roles, influence, and communication needs. While useful for engagement planning, it does not provide process-level insights or help refine functional requirements.

❌ B. Business analysis plan
The BA plan outlines the approach, deliverables, timeline, and tools the BA will use during the project. It’s a planning artifact, not a source of requirement feedback or process detail. It helps manage the work, but doesn’t inform the content of user stories.

📘 Reference
Explore this in the Trailhead module:
📘 Business Analyst Project Lifecycle

Explanation:

A complete user story follows the structure: As a [Role/Persona], I want [Goal/Action], so that [Reason/Benefit].

The BA used the vague term "As a user" instead of the specific, relevant persona from the requesting team.

Missing Persona: The story was requested by the inside sales team. The correct persona should specify who needs the visibility and who performs the tailoring, such as:

- As an Inside Sales Representative
- As an Inside Sales Manager

Importance: Defining the correct persona is crucial because it helps the development team understand the context for access, permissions, and the specific user interface needed. A "user" could be anyone, but an "Inside Sales Representative" immediately clarifies the role and process flow.

❌ Incorrect Answers and Explanations
A. The goal is undefined
Explanation: The goal (the WHAT) is clearly defined: "I need visibility to customers' purchase history details." The development team knows exactly what information needs to be displayed.

C. The need is undefined
Explanation: The need (the WHY or Benefit) is clearly defined: "so I can increase efficiencies and improve closure rates by better tailoring sales offerings." This articulates the business value the story aims to deliver.

References
Salesforce Trailhead: The core structure of user stories is essential for effective Agile development on the platform.
Module: Agile Basics: Write Effective User Stories (This module defines the Role, Goal, and Benefit as the three required parts of a complete user story, emphasizing that the role must be specific).
IIBA BABOK Guide: User stories should be written to ensure requirements are unambiguous. Using a generic term like "user" is ambiguous when a specific persona is available.