Event

Meetup #61 : Des 7 principes du test aux 7 principes de la qualité (en agile), Meetup Programmez

When

Thursday, 2026-11-19, 12:30-13:30 Paris (06:30-07:30 EST)

Where

online; the connection link goes to attendees a few days before

Format

brown-bag talk (BBL), in French

Host

François Tonic (Meetup Programmez)

Speaker

Marc Hage Chahine

Link

Event page

The talk starts from the software-testing principles as foundations and asks how to make them work in multidisciplinary agile teams, where quality covers more than testing. Three threads: sharing responsibility for quality across the whole team; tying test practice to usage, collaboration and prioritisation; and evolving the approach to build products that are useful, robust and durable. One example from the field shows the testing principles extended into a wider view of quality. The audience is everyone on a product (QA, developers, product owners, managers), and the stated aim is to make quality a "levier collectif de performance".

Marc Hage Chahine writes La taverne du testeur, a French blog on testing; recent posts carry his byline. Two series there bracket this talk:

• Les 7 principes du test, one post per principle, from part 1 (2021-10-25) to part 7 (2022-06-17), after an earlier overview, du bon sens avant tout (2018).
• Les 7 principes du Modern Testing (2026-04-06), crediting a Ministry of Testing article; its principles put the business, the team and the customer ahead of the tester: "the customer judges quality", build test skills across the team.

He wrote Tout sur le test logiciel (Ellipses), reviewed by Le Monde Informatique on 2019-07-02 as a guide to the trade that also prepares for ISTQB certification. He is listed as a coordinator of the CFTL's collective book Évolution des tests logiciels (2024) [unverified]: the claim comes from a search snippet of the CFTL PDF; the PDF itself was not opened.

From the ISTQB CTFL syllabus v4.0.1, section 1.3 (page 17), with the reference each one cites:

1. Testing shows the presence, not the absence of defects (Buxton 1970).
2. Exhaustive testing is impossible; use test techniques, prioritisation and risk-based testing to focus effort (Manna 1978).
3. Early testing saves time and money; start static and dynamic testing as early as possible (Boehm 1981).
4. Defects cluster together; a few components hold most defects or cause most operational failures, and the clusters feed risk-based testing (Enders 1975).
5. Tests wear out; repeated tests find fewer new defects, so modify tests and data and write new ones, though repetition still pays in automated regression (Beizer 1990). Earlier syllabi called this the pesticide paradox; v4.0.1 does not use the name.
6. Testing is context dependent (Kaner 2011).
7. Absence-of-defects fallacy; verification does not ensure the system meets users' needs or business goals, so validate as well (Boehm 1981).

Speculation, written 2026-11-13, before the talk. These are questions to bring, not claims about what the speaker will say. Each names the principle it touches and the page it comes from.

• Presence of defects (1) and early testing (3). If a green run cannot show absence, should a suite have to show it can show presence: a planted fault, caught by a named check, before the suite is trusted? Harness first built the oracle and fault injector before the shop and planted fifteen faults; its advice is to ask a supplier for the fault list and which check catches each. Is "test early" in agile teams about timing, or about building the means of checking before the thing checked?
• Exhaustive testing is impossible (2). Once a team chooses what not to test, who counts whether what it did choose was reached? In Harness first, one fault was called seven times per browser run and changed an output once; reach counts made that visible, where pass/fail would have called it a pass.
• Defects cluster (4). Clustered by where the failure shows, or where the defect sits? Of 29 first violations in the same note, 25 appeared on a customer's search, select, detail or save, while the faults sat in the indexer, the fit-rule interpreter and the taxonomy cascade. Risk-based testing fed by symptom counts would point at the page.
• Tests wear out (5). Green is not evidence: default properties ran 55,731 states with no violation and caught 0 of 30 planted faults; four properties written for the forms caught 19, and a generator that could finish a form raised it to 26 of 26. The syllabus remedy (new tests, new data) worked; does the speaker measure wear-out, or infer it?
• Testing is context dependent (6). When hardening comes due turns "context" into six detectable moves (deployable, contract, reachable, secure, observable, handoff), each earned by a failure. Does the agile version of this principle name the moment the context changes, or leave it to judgement?
• Absence-of-defects fallacy (7), and quality as the whole team's job. The five questions a CISO asks end with "does it do what the business thinks it does?", the row an agent is worst at judging about its own work; the two ladders split correctness from operations so that each has an owner and one next step. The elenctic review asks the owner rather than the tester ("did you mean for this to accept negative prices?"). Do his seven quality principles assign validation to a role, or to a question anyone may ask?