First assisted tests

How can you use AI to obtain simple, verifiable test cases that are faithful to the requirements?

1250 € per session, excl. VAT

In short

This half-day session of 3 hours introduces assisted writing of simple functional tests. Using a fictitious form, participants identify the rules to check, request suggestions from an approved AI tool and correct the results. They leave with a test table and a quality checklist.

Why this training?

A test phrased as ‘check that the form works’ does not allow you to decide whether the observed behaviour is correct. Explicit input data, reproducible steps and an observable expected result make the check usable. AI can quickly suggest several scenarios, but it can also invent a rule or produce numerous duplicates. The workshop teaches participants to check each suggestion against a short specification, rather than confuse the number of tests with useful coverage. Running case study: The fictitious organisation ‘Brumelis Prêts’ is preparing an equipment booking form. The specification requires a completed name field, an integer quantity from 1 to 5 and acceptance of the terms and conditions. Valid input displays a confirmation; any violation blocks submission. Other behaviours remain to be clarified. Transfer to the workplace: After the session, choose a small internal form and describe its rules without sensitive data. Reuse the prompt, then have five tests reviewed by a colleague before running any of them. Compare the shortcomings identified with those in the first table produced during the workshop.

Objectives of this training

  • Identify explicit rules and missing information in a specification.
  • Distinguish between a normal case, invalid input and a boundary value.
  • Formulate a generation request with a precise output format.
  • Correct suggested cases by checking their fidelity to the rules.
  • Measure requirements coverage and the completeness of the table.

Who is it for and what are the prerequisites?

Roles and tasks concerned

  • Product assistants and project managers new to functional acceptance testing.
  • Junior developers and key users required to check a form.

Prior skills

  • No prior AI knowledge required.
  • Ability to use a digital form and read a simple table.

What you will work on

  1. Read a requirement before testing

    Objective: Turn the form’s description into verifiable rules. Requirement, test case and defect; the difference between expected and observed results; the limitations of a specification.

  2. Request an initial proposal

    Objective: Build a simple, sufficiently well-defined prompt. Context, source rules, expected columns and an instruction not to fill in missing requirements.

  3. Check inputs and boundaries

    Objective: Correct the suggestions without arbitrarily extending the scope. Normal case, empty field, non-integer quantity and boundary values; isolating one error per test; detecting duplicates.

  4. Evaluate the resulting table

    Objective: Measure documentation quality without claiming to validate the software. Rule coverage, row completeness and human review; the distinction between a written test and an executed test.

What you take away

  • A sheet listing the form’s rules and points requiring clarification.
  • A reusable generation prompt with a table structure.
  • A corrected table of eight to ten simple test cases.
  • A completed checklist with a coverage assessment.

Method and assessment

  • Short explanations followed by immediate practice using the running case study.
  • Individual work followed by work in pairs, with peer review of the outputs.
  • Guided group discussion: what works, what needs correcting and what remains a human decision.
  • Preparation: Arrange access to a generative AI assistant approved by the organisation. Prepare the supplied fictitious specification and a blank table; use only fictitious or anonymised cases.

Observable criteria: Each test references an explicit rule, with no invented behaviour. ; Each row includes an identifier, preconditions, data, steps and an observable expected result. ; The table covers valid input, mandatory fields and the boundary quantities 0, 1, 5 and 6. ; Duplicates are removed and ambiguities are recorded separately. ; The assessment states the number of rules covered out of the total and the number of complete rows..

Frequently asked questions

Do you need to know how to programme?

No. The exercises focus on manual tests described in a table.

Are the tests run on an application?

No. The session includes a paper simulation, not technical validation of the form.

Can you use production data?

No. Only fictitious or anonymised data is used in the approved tools.

Does AI determine the correct behaviour?

No. The specification is the reference; an ambiguous expectation must be clarified by the person responsible for the functional requirements.

Last updated: