Business and BA teams · 2 days (14 hours) · in-house, on-site or remote
Business analysis and acceptance testing: from a vague need to a written test plan
At a glance
- Duration
- 2 jours (14 heures)
- Format
- On site and remote
- Group size
- 10 participants maximum
- Level
- Intermediate
- Audience
- Business analysis teams and business owners in banking, insurance, mutual insurers and the public sector
- Prerequisites
- Having taken part in at least one IT project, in any capacity: business, business analysis, project management, testing or development
- Methods
- Short alternation between input and practice: no talk runs longer than twenty minutes without a hands-on exercise
- Assessment
- Before the session: a 10-question positioning questionnaire sent during framing, which establishes each participant's starting level and tunes the depth of modules 3 and 5
- Lead time
- Scheduled during framing, to suit your availability
- Pricing
- On a quote basis, depending on format, duration and number of participants. The first call is free.
- Accessibility and disability
- See the dedicated section
"It does not work the way we expected", discovered on release day, costs vastly more than two days of method. The pattern is almost always the same: the business described a solution instead of a need, the business rules were never written down, and acceptance testing was improvised the week before delivery. This session attacks the problem from both ends. Day 1: trace back to the real need and turn it into requirements that can actually be verified. Day 2: derive from those requirements an acceptance test plan that objectively decides whether a delivery is compliant, then qualify and track defects through to release.
Learning objectives
- Tell a request for a solution apart from a business need, and restate the request as a workable need
- Run a requirements workshop: preparation, probing questions, register of open points
- Write business rules and acceptance criteria that can be verified, edge cases and error cases included
- Build a risk-prioritised test strategy with an explicitly owned scope
- Design test cases using equivalence partitioning, boundary values and decision tables
- Assemble an acceptance test plan traced back to requirements and executable by someone other than its author
- Qualify a defect by severity and priority, tell it apart from a change request, and track it through to closure
- Write an acceptance report and phrase reservations that hold up before release
Detailed programme
01Day 1 · Where defects actually come from
1 hour- What a defect costs depending on when it is found: framing, development, acceptance testing, production
- The three recurring causes: a need expressed as a solution, a business rule never written down, acceptance testing improvised at the end
- Who verifies what: business, business analysis, engineering, testers — what each role can validate and what it cannot
- In-session diagnosis: each participant describes a defect actually found in production, and the group traces it back to its origin
02Day 1 · From request to need: running the requirements workshop
2 hours- Preparing the workshop: who to invite, which questions to write beforehand, which documents to demand before sitting down
- Surfacing the need behind the requested solution: restating, probing questions, hunting for the non-nominal cases
- Separating three things that always arrive tangled: the business need, the regulatory constraint and the interface preference
- Recording what is decided and what stays open: a register of pending points and who owns each decision
- Hands-on: the workshop is played out in pairs on the running case, one participant taking the business role
03Day 1 · Writing requirements you can test
2 hours- Anatomy of a business rule: input data, condition, expected result, behaviour on error
- Acceptance criteria that can be verified: how to get past "the system must be user-friendly"
- Edge cases, error cases and recovery cases: what specifications forget most reliably
- Turning a regulatory constraint (identity verification, data retention period) into a concrete, verifiable requirement
- Assessed output: each pair rewrites three vague requirements from the running case into testable ones, reviewed with the group
04Day 1 · Building the test strategy
2 hours- Scope: what gets tested, what does not, and why that is an owned decision rather than an oversight
- Prioritising by risk: business impact against likelihood of failure, and how to arbitrate when the schedule tightens
- Test levels and their sequence: unit, integration, functional acceptance, regression, business acceptance
- Environments and test data: the practical constraint that sinks most campaigns
- The acceptance testing schedule: real workload, availability of business testers, fix-and-retest loops
- Assessed output: the group builds the risk matrix of the running case and derives its test scope from it
05Day 2 · Designing test cases
2 hours- Going from a requirement to a set of test cases: what guarantees coverage, what merely looks like testing
- Equivalence partitioning and boundary values: running fewer cases, but where defects actually hide
- Decision tables for multi-condition rules, the ones intuition always covers badly
- Happy paths, error cases and end-to-end cases: three distinct testing intents not to be mixed up
- Anatomy of a case executable by someone other than its author: preconditions, test data, steps, expected result
- Assessed output: designing a full set of cases for a business rule with multiple conditions
06Day 2 · The acceptance test plan
1 hour 30- Structure of an acceptance test plan and how far it commits you towards a supplier
- Requirement-to-test-case traceability matrix: the only way to answer "what is not covered?"
- Test data: building it, anonymising it, reusing it from one campaign to the next
- Tooling without drowning: what a spreadsheet handles perfectly well, what genuinely justifies a tracking tool (Jira or equivalent)
- Assessed output: assembling the acceptance test plan of the running case from the cases designed the day before
07Day 2 · Executing, qualifying and tracking defects
2 hours- Running a campaign: execution order, handling blocked cases, keeping evidence of execution
- Writing a reproducible defect: context, steps, expected result, actual result, environment, evidence
- Qualifying: severity (business impact) against priority (urgency of the fix), and why conflating them paralyses a steering meeting
- Defect, change request or misunderstood need: the call that keeps the dialogue with engineering from stalling
- The tracking loop through to closure: fix, retest, regression check
- Hands-on: each pair executes the cases written by another pair, then qualifies the discrepancies found
08Day 2 · Signing off and securing the release
1 hour 30- Deciding: accepted, accepted with reservations, or rejected — and what each decision commits you to next
- Writing the acceptance report and phrasing reservations precise enough to be enforceable
- After delivery: watching the first days of live operation, running the regression campaign, capitalising the test case library
- Final assessment, walked-through correction, then an individual action plan: what each participant puts in place within two weeks
Who this session is for
- Business analysis teams and business owners in banking, insurance, mutual insurers and the public sector
- IT departments in small and mid-size companies where defects surface in production rather than in testing
- Project managers and Product Owners who inherited acceptance testing without ever structuring it
- Service providers whose deliveries get contested for lack of criteria written up front
- Business testers who landed in the role out of necessity, with no dedicated training
What participants take away
- An acceptance test plan template: structure, traceability matrix, test data handling
- A requirements workshop facilitation grid: probing questions, common traps, register of open points
- A cheat sheet of test design techniques: equivalence partitioning, boundary values, decision tables
- A defect report template with its severity / priority qualification grid
- An acceptance report template including how to phrase reservations
- All the outputs produced by the group over the two days, consolidated and sent after the session
Prerequisites
- Having taken part in at least one IT project, in any capacity: business, business analysis, project management, testing or development
- No technical prerequisite: no coding, no test automation tool. The session covers functional acceptance testing, the kind business teams run themselves
- For in-house sessions, plan for a real project of yours whose specification extract can serve as material (anonymised if needed)
Teaching methods
- Short alternation between input and practice: no talk runs longer than twenty minutes without a hands-on exercise
- A running case, fictional but realistic, held across both days: online bank account opening, with its business rules, edge cases and compliance constraints
- For in-house sessions, the running case can be replaced by a specification extract from your own project, collected during framing and anonymised if needed
- Pair work with cross-review: each pair executes and challenges another pair's output, exactly as in real acceptance testing
- Materials handed over in session and reusable as they are: the templates, grids and cheat sheets listed below
- Groups capped at 10 participants, the condition for everyone to produce something and be corrected individually
Assessment of learning
- Before the session: a 10-question positioning questionnaire sent during framing, which establishes each participant's starting level and tunes the depth of modules 3 and 5
- During the session: every practice module ends with an assessed output (a rewritten requirement, a risk matrix, a set of test cases), corrected with the group against a grid announced at the opening
- End of day 1: a 15-question validation quiz covering framing, business rules and test strategy, corrected on the spot
- At the end: a final practical exercise. From a specification handed out in session, each pair produces an acceptance test plan extract of at least five cases, including one edge case and one error case, then executes another pair's cases and qualifies the discrepancies by severity and priority
- The final exercise is marked against four criteria announced from the opening: requirement coverage, executability by a third party, relevance of the edge cases, and quality of defect qualification
Where what I teach comes from
Adrien Bouthet, freelance IT project manager and Product Owner based in Bordeaux, 8 years of experience. What I teach here comes from assignments where acceptance testing was the last safety net before production. Since February 2025 I have been steering La Banque Postale's digital onboarding journeys — account opening, minor and adult paths, Livret A subscription — on a budget in the order of one million euros and with 2 external partnerships integrated through APIs, under KYC and GDPR constraints: I run the framing workshops, write the functional specifications, and both design and execute the acceptance scenarios. The setup holds at fewer than 3 production incidents per year. As a freelancer I have built the functional acceptance testing assets and fed the backlog on client projects, and grown the skills of business analysis teams. I trained as a software tester at the Wild Code School in 2020, and I have been teaching in Bordeaux schools as a trainer since 2020. Those figures come from steering assignments: they say where the method taught here comes from, not what a two-day session will produce in your organisation.
Real example
Concrete figures: on La Banque Postale's onboarding journeys, I designed and executed the acceptance scenarios of a setup worth around €1M integrating 2 external partners through APIs, under KYC and GDPR constraints, for an outcome of fewer than 3 production incidents per year. The test design and defect qualification modules of this session come straight out of that practice.
Read the case studyFrequently asked questions
Do participants need to code or use a test automation tool?+
No, and automation is not on the programme. The session covers functional acceptance testing: the kind business teams run themselves, by hand, to check that a delivery matches the need that was expressed. The most valuable participants here are often the least technical ones, because they know the real business cases.
Can we work on our own projects rather than the running case?+
Yes, and for in-house sessions that is the most profitable format. During framing I collect a specification extract or a real business request, anonymised if needed, and it replaces the running case in all or part of the exercises. The two days of output then become directly reusable on that project.
Our teams currently have neither an acceptance test plan nor a requirements repository. Is that a blocker?+
No, it is the most common situation and the session is built for exactly that starting point. Day 1 exists precisely to reconstruct workable requirements from whatever is there: tickets, meeting notes, emails, users' oral knowledge. Day 2 derives a first acceptance test plan from them.
What is the maximum group size?+
Ten. Beyond that, cross-reviewing the outputs no longer fits the announced duration and the session degrades into a lecture. When more people need training, we schedule several sessions rather than enlarging the group.
Is the session delivered at our offices or remotely?+
Both formats exist: on-site at your offices in Bordeaux and the Nouvelle-Aquitaine region, or remotely anywhere in France. Remotely the outline stays identical, but the two days are usually spaced a week apart, which leaves time to apply day 1 on a real case before day 2.
How is this different from hiring you as a business analyst?+
On a consulting assignment I produce the deliverables on your project myself: requirements, specifications, acceptance test plan, defect tracking. In training, your team learns to produce them and leaves with the templates to do it alone. The two combine well: an assignment on a first project, then a session to transfer the method.
Are two days really enough?+
Two days are enough to establish the method and produce a first acceptance test plan on a narrow scope: that is the stated objective and it is met. They are not enough to rework an entire existing requirements repository or to cover a whole application. When that is the actual need, the session acts as a starting point and reworking the repository belongs to a consulting assignment, not a training course.
Framework and terms
Funding
These sessions are invoiced directly to the company, out of its own skills development budget. They are not eligible for pooled funding schemes (OPCO, CPF, France Travail), which require Qualiopi certification.
Certification
This session is not a certifying course. I do not deliver any Scrum.org, Scrum Alliance, Scaled Agile (SAFe) or PeopleCert (ITIL) certification, nor any qualification registered with the RNCP or the Répertoire spécifique. The goal is operational: practices you can apply, not a diploma.
Contractual framework
Each session is covered by a professional training agreement (convention de formation professionnelle) signed before the start, setting out the objectives, the programme, the duration, the delivery arrangements and the agreed fee. The internal rules applicable to the session are handed to participants at the opening.
Certificate of attendance
A certificate of completion is handed to each participant at the end of the session. It states the objectives, the nature and the duration of the training, along with the results of the assessment of learning.
Accessibility and disability
Disability referent: Adrien Bouthet, contact@adrienbouthet.fr. Any situation requiring an adjustment (access to the premises, adaptation of the materials, of the pace or of the assessment arrangements) is examined during the framing phase, within 5 working days. If the adjustment exceeds our means, we refer to specialised resources (Agefiph, Cap emploi).
A business analysis team to train
Book a free first call. We frame the participants' real level, the scope to cover and the format: two consecutive days, or two days a week apart.
The matching service
Freelance business analyst (AMOA)