Competenze di Testing per Sistemi Distribuiti

Due competenze per agenti di codifica IA che progettano ed eseguono test guidati da rivendicazioni per sistemi distribuiti e stateful. Insieme producono un piano di test Markdown strutturato e un report dei risultati con verdetti a 10 stati e una classificazione esplicita della colpa SUT / harness / checker / ambiente. Un revisore legge i due artefatti e decide se rilasciare; non è necessario rieseguire nient'altro.

Funziona con Claude Code, Codex, Copilot CLI, Cursor, Gemini o qualsiasi agente che legga Markdown ed esegua shell. Le competenze sono semplici file SKILL.md. L'agente le esegue; il piano e il report dei risultati sono l'output.

Una competenza progetta il piano. L'altra lo esegue. Un piano parte dalle rivendicazioni del prodotto, genera ipotesi legate a tali rivendicazioni e scrive scenari nominati in base alla rivendicazione che ciascuno tenta di falsificare. Per scenari critici per la coerenza, ogni scenario associa anche un modello astratto (register | queue | log | lock | lease | ledger | …) a uno schema di cronologia delle operazioni, un checker nominato e un nemesi con prove di atterraggio osservabili. Il piano termina con un argomento di adeguatezza della copertura e una dichiarazione di confidenza conservativa.

Perché

L'impostazione predefinita per testare sistemi distribuiti e stateful — scrivere pochi test di integrazione e concludere — trova una piccola frazione dei bug che effettivamente rompono questi sistemi in produzione: partizioni di rete parziali, concorrenza non deterministica, crash-recovery, aggiornamento/rollback, idempotenza sotto replay, ordinamento sensibile al tempo.

Queste competenze impongono un flusso di lavoro opinabile che attinge dalla conoscenza duramente conquistata sul campo:

Guidato da rivendicazioni, non da test. Si parte da ciò che il prodotto promette. Ogni scenario falsifica una rivendicazione sotto un guasto. Un test nominato in base alla sua rivendicazione è più difficile da indebolire di uno nominato in base alla sua configurazione.
L'adeguatezza della copertura è un risultato. Il piano termina con un argomento che gli scenari scelti sono sufficienti per rilasciare, più un elenco onesto di ciò che rimane non verificato.
Riutilizza gli strumenti del SUT. La competenza di esecuzione scopre test esistenti, runbook e scaffolding per iniezione di guasti prima di inventare qualcosa di nuovo.
Modello + cronologia + checker, non solo caos. Per rivendicazioni di sicurezza, durabilità, idempotenza, isolamento, ordinamento o appartenenza, ogni scenario dichiara un modello astratto, uno schema di cronologia delle operazioni, un checker nominato (linearizzabilità, serializzabilità, coerenza di sessione, nessun ack perso, esattamente-una-volta, …) e come tratta gli esiti ambigui (timeout, commit sconosciuti, tentativi). Caos più un modello e un checker, non solo caos.
Nessun passaggio silenzioso. Ogni PASS cita prove di esecuzione dell'oracolo e il segnale che prova che il guasto è effettivamente scattato. I verdetti provengono da un insieme di 10 stati, quindi "lo script del caos è stato eseguito correttamente" non può essere letto come "la rivendicazione è sopravvissuta al guasto." Ogni FAIL porta un'etichetta di colpa SUT / harness / checker / ambiente in modo che i riproduttori raggiungano la coda giusta.

Cosa ottieni

End-to-end, le due competenze producono:

docs/testing-plans/<slug>.md              ← piano con §0–§9 (vedi sotto)
test-sessions/<slug>/<UTC>/
  ├── session-log.md                       ← linea temporale + toolbox + sonda ambiente
  ├── logs/                                ← stdout/stderr per scenario
  ├── metrics/                             ← snapshot metriche
  ├── artifacts/                           ← harness temporanei, dump
  └── findings/
      ├── <scenario>.md                    ← verdetto per scenario (scritto durante l'esecuzione)
      └── report.md                        ← riepilogo + adeguatezza + delta confidenza

La struttura del piano (un revisore può leggerlo e decidere se rilasciare senza rieseguire i test):

0. Riepilogo architetturale     — sistema come realmente esiste
1. Ambito
1b. Rivendicazioni sotto test    — la spina dorsale
1c. Rivendicazioni mancanti scoperte  — deriva documentazione ↔ codice
2. Modello SUT
3. Inventario test esistenti    — ciò che è già coperto
4. Ipotesi modalità di guasto    — legate agli ID rivendicazione
5. Matrice di copertura          — rivendicazione × ipotesi
6. Selezione delle tecniche     — dal catalogo
6b. Requisiti ambientali
7. Scenari                      — ciascuno nominato in base alla rivendicazione, con
                                  File test target + Scheletro
   7.M Disciplina modello /     — obbligatorio quando lo scenario falsifica
       cronologia / checker       una rivendicazione in {sicurezza, durabilità,
                                  idempotenza, isolamento, ordinamento,
                                  appartenenza}: modello sotto test, schema
                                  cronologia operazioni, checker nominato,
                                  nemesi + prove di atterraggio, gestione esito
                                  ambiguo, piano di riduzione (colpa SUT/harness/checker/ambiente)
7b. Argomento di adeguatezza copertura — perché questi test sono sufficienti
7c. Incertezza residua          — ciò che rimane non verificato e perché ok
7d. Dichiarazione di confidenza — il verdetto del revisore
8. Cosa questo piano NON copre
9. Domande aperte / followup

Esempio blocco §7.M (estratto da un piano)

### Scenario S3: linearizable_append_under_partition
- Falsifies if it FAILs: C1 (ogni append riconosciuta è durevole
  e linearizzabile), C5 (elezione leader completata entro 5s)
- Carico: 8 client, 70% append / 30% lettura, 5min, skew chiavi zipf
- Guasti: partizione asimmetrica che isola il leader corrente a T+60s
  per 30s
- Oracolo: linearizzabilità tramite Porcupine su cronologie per chiave

§7.M (disciplina modello / cronologia / checker)
- Modello sotto test:    log
- Cronologia operazioni: schema predefinito a 11 campi (id op, id processo,
                       ts invocazione/completamento, tipo op, chiave, input,
                       output, errore, marcatore timeout, nodo visto,
                       epoca guasto). Registrato in-process + audit lato server.
- Checker:               linearizzabilità (Porcupine) per chiave, poi
                         nessun ack perso rispetto allo stato finale
- Nemesi + atterraggio:   partizione asimmetrica (iptables drop una
                         direzione). Prova di atterraggio = contatore drop iptables
                         va da 0 a 14.712 nell'arco di 30 secondi
                         E il log raft emette "leader-lost; starting
                         election" entro 2 secondi dall'iniezione.
- Esiti ambigui:          timeout → timeout_marker=true, complete_ts
                         =null, trattato come potrebbe-essere-riuscito;
                         i tentativi sono op separate che condividono l'input
- Piano di riduzione:     se FAIL, biseca finestra guasto + fissa seme, quindi
                         classifica SUT / harness / checker / ambiente
                         per references/test-case-reduction.md

distributed-system-testing — Updated!