Check before validating

How can you identify defects in a generated application and check that a correction works?

  • Lovable
  • Claude Code
  • Codex

1250 € per session, excl. VAT

In short

This half-day session of 3 hours offers a guided introduction to testing a generated application. Participants translate simple rules into checks, reproduce defects and check a correction. They leave with a completed test workbook and a factual summary, without equating a successful demonstration with complete reliability.

Why this training?

A convincing interface can conceal an impossible booking, missing validation or information lost after refreshing. Checking only the ideal journey leaves these defects invisible and leads to accepting the generated result too quickly. Feedback such as ‘it does not work’ does little to help with corrections. Describing the steps, the expected result and the observed result makes it possible to request a targeted change, then have a human check its effect. Continuing case study: The fictional organisation ‘Avelune Prêts’ has a generated equipment booking application. A booking must include a fictional name, an available item of equipment and a return date later than the departure date. Participants check these rules on a training version containing deliberately introduced defects. Transfer to work: Reuse the workbook for a simple journey in an authorised application, with anonymised data. Have the technical lead review the defects before any correction and retain the before-and-after results.

Objectives of this training

  • Distinguish expected behaviour from an observable defect.
  • Write six test cases covering a normal journey, an error and a boundary condition.
  • Carry out manual checks and record their results.
  • Describe a reproducible defect and its severity.
  • Compare results before and after a guided correction.

Who is it for and what are the prerequisites?

Roles and tasks concerned

  • Beginners discovering generated applications who want to learn how to check them.
  • Non-technical project leads who need to comment on an initial version of an application.

Prior skills

  • No prior AI or programming knowledge required.
  • Ability to use a browser and complete a form.

What you will work on

  1. Observe without confusing appearance with compliance

    Objective: Identify what the booking rules allow you to check. Expected result, observed result, functional defect and limitations of a demonstration; distinction between manual and automated tests.

  2. Build revealing test cases

    Objective: Prepare six complementary checks. Normal journey, empty field, unavailable equipment, inconsistent dates and boundary value; importance of a known initial state.

  3. Execute and document discrepancies

    Objective: Produce usable evidence rather than an impression. Reproducibility, screenshot without sensitive information, severity according to impact; distinction between failure and inability to execute.

  4. Check a proposed correction

    Objective: Check a change without assuming its reliability. Generating and modifying code from instructions with Lovable, Claude Code or Codex; human review, protection of secrets and regression checking. Consult the official documentation for the procedures specific to each tool.

What you take away

  • Completed workbook containing six test cases.
  • Reproducible, prioritised defect report.
  • Targeted correction instruction with human review points.
  • Before-and-after summary specifying successes, failures and tests not run.

Method and assessment

  • Short explanations followed by immediate practice on the continuing 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 the isolated training application and to an organisation-authorised tool from among Lovable, Claude Code or Codex. Prepare fictional bookings, a retained initial version and the expected rules; exclude personal data, real identifiers and secrets.

Observable criteria: Each test specifies data, steps and the expected result. ; The six cases cover at least one valid journey, one invalid input and one boundary value. ; The defect can be reproduced from the report alone. ; The correction is followed by the same test and two regression checks. ; The summary explicitly distinguishes between passed, failed and unexecuted tests..

Frequently asked questions

Do you need to be able to read code?

No. The exercises focus on visible behaviour; guidance is provided for the technical review of the correction.

Are all three tools used?

No. A single authorised tool is enough; the checking principles remain the same.

Can an internal application be tested?

The session uses the fictional case study. Any transfer requires authorisation, a suitable environment and anonymised data.

Do successful tests authorise deployment to production?

No. This introductory check replaces neither a security review nor full technical validation.

Last updated: