Checking vs Testing
Distinzione fondamentale argomentata da DevOps & AI Toolkit nel video "End-to-End Testing With AI Agents": tutto quello che chiamiamo "testing" non è testing — è checking. 1
Checking
- Decidi in anticipo cosa dovrebbe essere vero, lo scrivi, qualcosa conferma se vale ancora 1
- Ha un soffitto: chiunque abbia scritto il check ha preso l'idea di "corretto" da qualche parte 1
- Se l'idea viene dal software stesso → il check può solo concordare → è il software che valuta il proprio compito 1
- I test handwritten dell'autore erano "una fotografia di come il software era fatto la settimana in cui li ha scritti" 1
Testing
- Andare a scoprire. Nessuno ti ha dato una lista 1
- Poking, provando cose stupide di proposito 1
- Notando che il messaggio di errore è tecnicamente accurato e completamente inutile 1
- Testing è come scopri di esserti sbagliato su ciò che credevi 1
Perché il testing è sparito dalle pipeline
Il testing non scala, non si automatizza e non si sa in anticipo se un pomeriggio di esplorazione troverà qualcosa: difficile da giustificare in un piano, facile da tagliare quando la data slitta. Per questo divenne il mestiere dei tester dedicati, che criticavano la test automation con ragione ("quegli script non testano niente, confermano ciò che qualcun altro ha assunto"). Ma il loro ruolo richiedeva un handoff: con due rilasci l'anno una settimana di indagine era economica, con più rilasci al giorno diventa un muro. Il ruolo è sparito, spesso senza sostituti, ed è rimasto il checking perché era la parte che stava dentro la pipeline. 1
Ora anche il testing si sta automatizzando: agent come l'Explorer di Momentic esplorano il prodotto senza specifiche e riportano ciò che sembra sbagliato (vedi Agentic Testing). Nell'analogia dell'auto (progettata da persone, costruita da robot, provata in pista da un pilota) la parte centrale ha iniziato a mangiare anche il test su strada; resta la progettazione. 1
Perché la distinzione importa con gli AI agent
Un test rosso si risolve in 4 modi; quando un agent (vedi Agentic Harness) esegue il loop di fix, sceglie da solo tra: 1 1. Fixare il codice (unica che cambia il software) 2. Riscrivere il test fino a farlo passare 3. Smettere di eseguire il test 4. Decidere che il fallimento era "atteso"
Le opzioni 2-4 funzionano ugualmente sia che ci sia un problema vero sia che non ci sia. Quando l'agent decide, la PR è già verde prima che tu guardi → il momento di judgement si è spostato dove non sei tu. 1
TDD come unica via di scampo
Un check scritto prima dell'implementazione non può essere venuto dall'implementazione → non è il software che valuta il proprio compito. È ancora checking, ma almeno non è "software grading its own homework". 1
Vedi anche: Agentic Testing, AI Agent in DevOps, Agentic Harness