Piattaforma
QA automatizzato per una delivery software AI seria
Ogni modifica scritta dall'AI viene testata come la vivrebbe un utente — in un browser reale, prima che venga rilasciata e dopo che è stata pubblicata.
Ciao QA è il livello di test automatizzato della piattaforma: replay browser deterministici, test auto-riparanti, smoke gate prima della pubblicazione e controlli di produzione dopo la pubblicazione. A differenza delle suite di test che si degradano man mano che l'applicazione cambia, i test di Ciao si riparano da soli quando l'interfaccia evolve — così la copertura tiene il passo con lo sviluppo alla velocità dell'AI invece di restarne indietro.
Pubblicato 2026-07-03 · Ultimo aggiornamento 2026-07-03
L'AI scrive più velocemente di quanto gli umani possano testare
Lo sviluppo assistito da AI sposta il collo di bottiglia. Codice che una volta richiedeva uno sprint arriva in un pomeriggio — e ognuna di quelle modifiche può rompere il checkout, il login o il report che un direttore legge ogni lunedì. Cliccare manualmente attraverso l'app non scala a questo ritmo, e le suite di test tradizionali decadono nel momento in cui l'interfaccia si sposta sotto di loro.
Ciao QA è costruito per questo ritmo. Esegue replay browser deterministici, test auto-riparanti, smoke gate prima della pubblicazione e controlli di produzione dopo la pubblicazione — automaticamente, a ogni modifica, come parte dello stesso ciclo che ha scritto il codice.
Come funziona il QA
Il QA gira come parte del ciclo di delivery — qui non c'è nessuno strumento separato da adottare o pipeline da mantenere.
1. I flussi vengono catturati come replay
I percorsi utente chiave — accesso, creazione di un record, checkout — vengono catturati come replay browser deterministici: gli stessi passaggi, gli stessi input, gli stessi risultati attesi, a ogni esecuzione.
2. I test girano in un browser reale
I replay vengono eseguiti contro l'applicazione reale nel modo in cui la vivrebbe un utente — rendering reale, rete reale, autenticazione reale — non contro componenti simulati.
3. I test si riparano invece di degradarsi
Quando l'interfaccia cambia legittimamente — un pulsante si sposta, un'etichetta viene riformulata — i test auto-riparanti si aggiornano da soli per adattarsi alla nuova realtà invece di fallire su un selettore obsoleto e finire cancellati.
4. Gli smoke gate tengono la porta
Prima di ogni pubblicazione, gli smoke gate eseguono i replay critici. Un gate fallito blocca la pubblicazione, così la versione rotta non passa attraverso di esso.
5. I controlli di produzione chiudono il ciclo
Dopo la pubblicazione, i controlli girano contro l'applicazione live per confermare che il rilascio si comporti correttamente in produzione, dove configurazione e dati sono reali.
6. I fallimenti tornano come lavoro
Un controllo fallito rientra nel ciclo con il contesto — quale passaggio è fallito e cosa ci si aspettava — dove la correzione può essere costruita e riverificata.
Perché è importante
Deterministico è importante perché i test instabili abituano i team a ignorare il rosso. Quando un replay fallisce, qualcosa è davvero cambiato — il che rende il segnale degno di essere considerato e il gate degno di fiducia.
L'auto-riparazione è importante perché l'alternativa è una suite che muore in silenzio. Una copertura che si mantiene da sola tiene il passo con i cambiamenti alla velocità dell'AI, così la centesima modifica viene testata a fondo quanto la prima. E i gate su entrambi i lati della pubblicazione significano che "ha funzionato in anteprima" e "funziona in produzione" sono entrambi verificati, non presunti.
L'abitudine che questo crea è il punto. Quando ogni pubblicazione è vincolata da un gate e ogni rilascio è controllato in produzione, rilasciare smette di essere un atto di coraggio. I team fanno più modifiche, in pezzi più piccoli, perché il costo di sbagliare è una pubblicazione bloccata anziché un lunedì rotto — e il registro di controllo mostra ogni gate che ciascun rilascio ha superato.
Chi lo usa
Il QA è uno dei sei ruoli nell'organizzazione software AI di Ciao, e persone diverse vi si affidano in modo diverso.
- Non ingegneri che rilasciano app reali — Le persone da cui non ci si può aspettare che scrivano suite di test ne ottengono comunque una — catturata dai flussi che la loro app ha realmente.
- Responsabili di ingegneria — Gate invece di promesse: una pubblicazione che ha fallito il suo smoke gate non esce, chiunque l'abbia richiesta.
- Agenzie — Ogni applicazione cliente ottiene percorsi protetti senza un budget QA per progetto o una suite mantenuta a mano per ogni cliente.
- Team di operazioni e supporto — I controlli di produzione intercettano le regressioni nell'app live, così i problemi emergono come segnalazioni anziché come ticket di supporto.
Note di sicurezza e governance
- ✓ Gli smoke gate girano prima di ogni pubblicazione; i controlli di produzione dopo.
- ✓ I replay sono deterministici — stessi passaggi, stessi dati, stesso risultato atteso a ogni esecuzione.
- ✓ L'auto-riparazione mantiene viva la copertura mentre l'interfaccia evolve.
- ✓ I risultati QA alimentano la salute del progetto in Conductor, visibile su tutta la flotta.
- ✓ Gli esiti dei test si uniscono al registro di controllo append-only insieme a merge e deploy.
Una suite mantenuta a mano contro Ciao QA
Il confronto con una suite mantenuta a mano è strutturale, non estetico.
| Suite di test mantenuta a mano | Ciao QA | |
|---|---|---|
| Creazione | Gli ingegneri scrivono e aggiornano gli script | I flussi vengono catturati come replay man mano che l'app viene costruita |
| Cambiamenti dell'interfaccia | I selettori si rompono; i test vengono saltati | I test si auto-riparano per adattarsi alla nuova interfaccia |
| Prima del rilascio | La CI gira se qualcuno l'ha configurata | Gli smoke gate bloccano una pubblicazione fallita |
| Dopo il rilascio | Monitoraggio, se configurato | I controlli di produzione verificano l'app live |
| Fallimenti instabili | Riesegui e spera | Replay deterministici — il rosso significa che qualcosa è cambiato |
Domande frequenti
Cosa significa deterministico qui?
I replay eseguono gli stessi passaggi con gli stessi input e le stesse aspettative ogni volta. Un fallimento quindi significa che l'applicazione è cambiata, non che il test ha vacillato — ed è ciò che rende ragionevole vincolare una pubblicazione ad essi.
Devo scrivere i test io stesso?
No. I percorsi chiave vengono catturati mentre l'applicazione viene costruita, e puoi aggiungere i flussi più importanti per la tua attività. Gli ingegneri possono ispezionare ed estendere ciò che gira — fa parte del progetto, non è una scatola nera.
Cosa succede quando uno smoke gate fallisce?
La pubblicazione si ferma. Il fallimento torna con il contesto — il passaggio, l'aspettativa, cosa è successo invece — così la correzione può essere fatta e riverificata. Quando il gate è verde, la pubblicazione procede.
Cosa sono i controlli di produzione, e perché eseguirli dopo la pubblicazione?
Anteprima e produzione differiscono: configurazione, dati, integrazioni e traffico sono reali solo in una delle due. I controlli di produzione girano contro l'applicazione live dopo ogni rilascio per confermare che si comporti correttamente dove conta, e le segnalazioni confluiscono verso Doctor e SysOps per diagnosi e risposta.
Questo sostituisce gli ingegneri QA?
No — cambia su cosa spendono il tempo. Il lavoro meccanico di mantenere vivi i test browser è automatizzato; gli umani decidono quali percorsi sono critici, rivedono cosa intercettano i gate e alzano l'asticella nel tempo.