softify.pro Flow — Testato da COCO

Control. Clarity. Flow.

Ogni prodotto software serio, prima o poi, sviluppa un secondo prodotto dietro il prodotto.

I clienti potrebbero non vederlo mai. I visitatori potrebbero non sapere mai che esiste. Ma amministratori, operatori e sviluppatori ne dipendono ogni giorno.

Per softify.pro Flow, quell'applicazione è Administration — la console operativa responsabile della gestione di utenti, ruoli, livelli di accesso, stati di autenticazione, ambienti di database e altre configurazioni che tengono sotto controllo un'installazione di Flow.

La sua schermata di login porta tre parole:
Control. Clarity. Flow.

Furono scelte originariamente per descrivere l'esperienza che volevamo che gli amministratori avessero operando il sistema.

Ma descrivono anche, sorprendentemente bene, come crediamo che il software debba essere testato.

Questo ha reso softify.pro Flow — Administration un candidato ovvio per un test reale di COCO.
Non una dimostrazione da laboratorio.
Non una raccolta di pulsanti isolati preparati appositamente per una demo AI.
Un'applicazione desktop multipiattaforma reale, con logica applicativa reale, finestre multiple, backend di database multipli, autenticazione, permessi, localizzazione e abbastanza stato da rendere regressioni apparentemente piccole difficili da individuare manualmente.

Per la dimostrazione pubblica qui mostrata, COCO ha lavorato esclusivamente con dati dimostrativi generati. L'applicazione era concessa in licenza alla azienda fittizia Presentation GmbH, e non sono state usate informazioni clienti, credenziali o dati personali di produzione.

L'obiettivo era semplice:
lasciare che COCO affrontasse l'applicazione come farebbe un tester e determinasse se l'intero flusso di lavoro amministrativo si comporta ancora come il software dichiara.

The Challenge

A prima vista, testare un'applicazione di amministrazione sembra semplice.

Aprila.
Accedi.
Clicca attraverso diverse finestre.
Controlla che tutto sembri corretto.

Questa ipotesi cambia rapidamente man mano che l'applicazione cresce.

softify.pro Flow — Administration non è un singolo modulo statico. È una raccolta di viste operative interconnesse dentro un unico guscio applicativo.

Tra le altre cose, un amministratore può lavorare con:

• account utente
• ruoli e livelli di accesso
• informazioni di autenticazione
• stato dell'autenticazione a due fattori
• informazioni sul sistema operativo
• informazioni di rete e IP
• configurazione del database
• opzioni di ordinamento e presentazione
• selezione della lingua in tempo reale
• informazioni sull'applicazione e sulla licenza

L'interfaccia attualmente supporta undici lingue. L'applicazione opera anche con MySQL e PostgreSQL backend di database. Presa singolarmente, nessuna di queste funzionalità rappresenta un problema di test insolito.

La difficoltà nasce dalle loro combinazioni.
Una tabella utenti può funzionare correttamente in inglese ma mostrare il nome di una colonna obsoleto in croato.
L'ordinamento può funzionare correttamente collegato a MySQL ma comportarsi diversamente dopo il passaggio a PostgreSQL.

Un cambio di lingua può aggiornare la maggior parte degli elementi dell'interfaccia lasciando un messaggio di stato non tradotto. L'applicazione può cambiare database con successo ma conservare informazioni obsolete dalla connessione precedente. Una nuova release può introdurre una funzione mentre la finestra "Informazioni" descrive ancora quella precedente. Il programma non deve necessariamente andare in crash perché una di queste situazioni sia una regressione. Anzi, alcuni dei difetti software più fastidiosi sono proprio quelli in cui tutto sembra funzionare.

L'applicazione si avvia.
La finestra si apre.
Il pulsante risponde.
Ma qualcosa sotto non è più del tutto corretto.
Ecco perché il test di regressione ripetitivo è importante.

Ed è esattamente il tipo di lavoro in cui gli esseri umani diventano progressivamente meno bravi dopo aver ripetuto la stessa sequenza decine di volte.

Why Manual Testing Becomes Expensive

Testare qualcosa una volta è facile.
Testarlo in modo affidabile dopo ogni release rilevante è diverso.

Considera solo tre dimensioni: 11 lingue di interfaccia × 2 backend di database × molteplici flussi di lavoro applicativi.

Il numero di combinazioni cresce rapidamente.
Aggiungi ruoli utente diversi, stati di autenticazione, comportamento di ordinamento, modifiche di configurazione e ambienti operativi, e la matrice di test diventa troppo grande per essere trattata come una checklist manuale occasionale.

È qui che il test di regressione spesso comincia a erodersi.
Non deliberatamente.
Una scadenza di release si avvicina.
Qualcuno ricorda che l'applicazione è stata testata la settimana scorsa.
Uno sviluppatore controlla rapidamente la schermata più importante.

Il tedesco funziona.
L'inglese funziona.
MySQL funziona.
L'ipotesi diventa:
"Il resto probabilmente va bene."

Di solito è così.
Fino alla release in cui non lo è.
COCO esiste in parte per rimuovere questa ipotesi dal processo.

What COCO Actually Did

COCO ha avviato softify.pro Flow — Administration da uno stato applicativo a freddo, senza affidarsi a una schermata già preparata o a un flusso di lavoro posizionato manualmente.

La prima interazione è stata la stessa presentata a un amministratore umano: la finestra di login.

COCO ha identificato l'interfaccia di autenticazione contenente:

• nome utente
• password
• codice di autenticazione a due fattori

e la riga direttamente sotto l'identità softify.pro Flow:
Control. Clarity. Flow.

Da lì, COCO ha proseguito attraverso una sessione di regressione definita. Lo scopo non era semplicemente determinare se l'applicazione potesse essere aperta.

Lo scopo era verificare se lo stato dell'applicazione rimanesse internamente coerente mentre COCO interagiva con essa.

Authentication Is Only the Beginning

Il test del login è uno dei candidati più ovvi per l'automazione, ma un'autenticazione riuscita da sola dice molto poco sul resto di un'applicazione amministrativa.

Una volta dentro, COCO si è spostato nell'ambiente operativo vero e proprio. Ha ispezionato l'interfaccia di amministrazione utenti e verificato che le informazioni attese fossero presenti.

Questo includeva dati come:

• nomi utente
• password mascherate
• indicatori 2FA
• ruoli assegnati
• informazioni sul sistema operativo
• indirizzi IP

COCO ha poi interagito con la tabella anziché limitarsi a osservarla.
L'elenco utenti è stato ordinato per nome utente.
L'ordine risultante è stato ispezionato.
La parte importante non era se cliccare sull'intestazione della colonna producesse un qualche cambiamento visibile.

COCO ha verificato che lo stato risultante della tabella corrispondesse all'operazione richiesta.

Questa distinzione conta.
Un test funzionale chiede:
"Il pulsante ha risposto?"

Un test di regressione utile chiede:
"L'applicazione è finita nello stato corretto?"

Testing the Database Boundary

softify.pro Flow supporta più di un backend di database.

Questo rende il cambio di database un confine di regressione particolarmente importante.
COCO ha cambiato il backend attivo da MySQL a PostgreSQL.

Dopo il cambio, ha ispezionato di nuovo le informazioni utente.
Il test cercava più di una connessione riuscita.
Ha verificato se l'applicazione continuasse a presentare i record attesi e se le informazioni mostrate tramite l'interfaccia rimanessero coerenti.

COCO è poi tornato indietro.

Questo tipo di transizione è facile da sottovalutare.
L'interfaccia utente può rimanere visivamente identica mentre il livello di archiviazione sottostante cambia completamente.
Dal punto di vista di un amministratore, quella transizione dovrebbe sembrare quasi noiosa.
Gli stessi utenti dovrebbero essere ancora comprensibili.
Gli stessi ruoli dovrebbero avere ancora senso.

Lo stesso comportamento dell'interfaccia dovrebbe ancora valere.

Quella continuità apparentemente priva di eventi è esattamente ciò che va dimostrato.

Eleven Languages, One Application State

La localizzazione è un'altra area in cui il test superficiale è particolarmente pericoloso.

È relativamente facile verificare che un'applicazione possa avviarsi in un'altra lingua.
È molto più prezioso verificare cosa succede quando la lingua cambia mentre l'applicazione è già in esecuzione e mantiene uno stato.

COCO ha cambiato la lingua dell'interfaccia in tempo reale.

La sessione includeva transizioni tra lingue come:
Tedesco → Inglese → Croato
mentre la vista di amministrazione rimaneva attiva.

COCO ha osservato se gli elementi dell'interfaccia cambiavano correttamente sul posto:

• intestazioni di tabella
• controlli
• pulsanti
• etichette
• messaggi di stato

Anche la tabella sottostante e lo stato dell'applicazione dovevano sopravvivere a quella transizione.
Questo è importante perché il software multilingue è fatto di più che stringhe tradotte.
I cambi di lingua possono rivelare:

• risorse dimenticate
• etichette obsolete
• problemi di layout
• messaggi di stato non tradotti
• problemi di codifica
• reset dello stato
• problemi di ricreazione dei controlli

Una finestra che appare corretta quando avviata direttamente in croato può comunque comportarsi in modo scorretto quando l'utente passa dal tedesco al croato durante una sessione attiva.

Questa è la differenza tra controllare uno screenshot e testare un flusso di lavoro.

Restoring Application State

COCO ha successivamente ripristinato la configurazione di ordinamento predefinita dell'applicazione.

Anche qui, il test non è finito con il clic stesso.

Sono stati valutati l'ordine risultante e la conferma presentata tramite l'area di stato dell'applicazione. Questo tipo di verifica può sembrare insignificante rispetto al test dell'autenticazione o dell'accesso al database.

Non lo è.

Le applicazioni enterprise accumulano centinaia di piccole transizioni di stato come queste.
Gli utenti fanno affidamento su di esse senza pensarci consapevolmente.
Il software sembra affidabile proprio perché quelle interazioni restano prevedibili.
Il test di regressione esiste per proteggere quella prevedibilità.

Testing the Information Around the Software

COCO ha anche aperto la finestra "Informazioni su" dell'applicazione.

Perché testare una finestra Informazioni?

Perché la documentazione del software inizia dentro il software stesso.
Il numero di versione, la descrizione delle funzionalità e le informazioni di licenza presentate all'operatore dovrebbero corrispondere all'applicazione effettivamente in esecuzione.

Un'applicazione può funzionare perfettamente pur presentando informazioni di versione obsolete o descrivendo funzionalità che non corrispondono più alla release.

Questo non manda in crash un database.
Fa qualcosa di più sottile:
riduce la fiducia.

Per il software enterprise, l'accuratezza operativa include anche questi dettagli apparentemente piccoli. COCO li ha quindi controllati anch'essi.

Control.

La prima parola dello slogan di softify.pro Flow è anche il primo principio dell'ambiente di test.

Control significa sapere cosa viene testato, contro quale stato e con quali dati.

La dimostrazione pubblica di COCO non usa dati di produzione dei clienti.

Funziona con dati dimostrativi appositamente preparati, il cui stato atteso è noto.

Questo rende i risultati riproducibili.

Significa anche che le differenze tra le esecuzioni di test possono essere indagate anziché essere liquidate come cambiamenti casuali nei dati di produzione.

Cosa ancora più importante, COCO è progettato come sistema di test AI self-hosted.

Le evidenze di test, gli screenshot dell'applicazione e le informazioni sul flusso di lavoro interno possono rimanere all'interno dell'infrastruttura sotto il controllo del cliente o dell'operatore, invece di essere inviate di default a un servizio cloud di terze parti non correlato.

Per le applicazioni aziendali interne, questo non è semplicemente una preferenza infrastrutturale.
Può far parte del requisito di test stesso.

Clarity.

L'automazione non è particolarmente utile se il suo output finale è: FAILED
seguito da centinaia di righe di output tecnico che qualcuno deve ricostruire manualmente prima di capire cosa sia successo.

COCO è progettato per preservare una traccia di evidenza comprensibile.

Il report descrive:

• cosa è stato testato
• quale interazione ha avuto luogo
• in quale sequenza è avvenuta
• cosa ha osservato COCO
• quale stato era previsto
• dove il comportamento è differito quando qualcosa è fallito

Screenshot e prove di esecuzione possono accompagnare quella sequenza.
Lo scopo non è nascondere i dettagli tecnici.

È rendere il risultato comprensibile prima che qualcuno debba aprire un debugger.

Un ingegnere dovrebbe poter rispondere a:
Cosa è successo? prima di chiedere:
Dove nel codice è successo?

Questa distinzione accorcia drasticamente l'indagine quando appare una regressione.

Flow.

L'automazione UI tradizionale spesso pensa per elementi.

Trova selettore.
Clicca selettore.
Trova un altro selettore.
Controlla il valore.

Questo approccio resta utile, ma le applicazioni non si vivono come raccolte di selettori.

Le persone vivono flussi.

Accedi.
Apri l'amministrazione.
Trova un utente.
Cambia un'impostazione.
Cambia un database.
Cambia una lingua.
Verifica il risultato.

Continua a lavorare.

COCO tratta quindi la sequenza come un processo, non come una raccolta casuale di controlli.

Segue ciò che l'utente sta cercando di ottenere e valuta l'applicazione nel contesto.

Questo diventa particolarmente prezioso quando si testa software aziendale reale, perché i guasti si verificano spesso tra schermate o tra stati, non dentro un singolo pulsante.

Un flusso logistico può contenere un ordine, una prenotazione di magazzino, un'operazione di prelievo, una bolla di consegna e una conferma di spedizione.
Ogni singola schermata può apparire corretta mentre l'intero processo è sbagliato.
Lo stesso principio si applica qui su scala minore.
La finestra di amministrazione non è il prodotto.

Il flusso di lavoro attraverso di essa lo è.

Evidence Instead of Assumption

Uno dei compiti più importanti di COCO non è cliccare. È ricordare cosa è successo.
Il test di regressione umano finisce spesso con un'affermazione come:
"L'ho testato e sembrava tutto a posto."

Potrebbe essere del tutto accurato.
Ma settimane dopo, quando emerge un problema, le domande utili sono diverse:

• Quale release è stata testata?
• Quale database?
• Quale lingua?
• Quale stato utente?
• Cosa è successo prima del problema?
• Cosa esattamente era visibile?

In quale ordine sono state eseguite le azioni?
Le esecuzioni di test di COCO sono progettate per lasciare tracce.

Questo trasforma un risultato di test da un'opinione a qualcosa che può essere ispezionato.
Un'esecuzione riuscita diventa quindi utile anch'essa.
Stabilisce uno stato di riferimento noto rispetto al quale confrontare il comportamento successivo.

COCO Is Not the Decision Maker

C'è un confine importante nel modo in cui usiamo l'AI per il test del software.
COCO non intende sostituire la responsabilità ingegneristica.

Non decide come dovrebbe essere una regola di business.

Testa il comportamento rispetto a scenari, requisiti e aspettative definiti per l'applicazione.
Per decisioni sensibili riguardanti permessi, prezzi, inventario, transazioni finanziarie o altri stati aziendali critici, la definizione del comportamento corretto resta una responsabilità umana.

Questa distinzione conta.
L'AI è eccellente nel ripetere un test dettagliato senza perdere concentrazione.
È eccellente nel raccogliere evidenze.
Può ispezionare schermate, confrontare comportamento atteso e osservato e spiegare le discrepanze.
Ma è l'azienda a definire ancora cosa significhi corretto.

COCO rende testabile quella definizione.

The Test Nobody Wants to Repeat

C'è un motivo semplice per cui l'automazione aggiunge valore qui.
Un tester umano può certamente eseguire questa sessione di regressione.
La prima lingua riceve piena attenzione.
Probabilmente anche la seconda.
Poi un'altra.
Poi un'altra ancora.
MySQL è già stato controllato.
PostgreSQL deve ancora essere controllato.
Il test di ordinamento è già stato eseguito diverse volte.
La finestra Informazioni non è cambiata da mesi.

È venerdì pomeriggio.

E l'attenzione umana fa ciò che l'attenzione umana fa naturalmente.
Inizia a ottimizzare.
COCO no.
Nello spirito di COCO stesso:

• Non mi stanco di cliccare lo stesso pulsante in undici lingue. Non salto il passaggio PostgreSQL solo perché è venerdì pomeriggio. Non presumo che l'ordinamento abbia tenuto solo perché ha funzionato nella release precedente.

Per COCO, ogni sessione di regressione può essere trattata come se fosse la prima.
Questo non è intelligenza che sostituisce un tester umano.
È automazione che protegge il tester umano dalla parte del test in cui l'attenzione umana vale meno.

From Repetitive Testing to Engineering Evidence

Lo scopo più ampio di COCO non è massimizzare il numero di azioni automatizzate.
Mille clic automatizzati non hanno senso se nessuno capisce cosa dimostrano. Il risultato utile è la fiducia sostenuta da evidenze.

Per softify.pro Flow, questo significa poter dire che una release è stata verificata nelle aree operative che contano:

• autenticazione
• amministrazione utenti
• informazioni su ruoli e accessi
• stato dell'autenticazione a due fattori
• comportamento di ordinamento
• funzionamento con MySQL
• funzionamento con PostgreSQL
• localizzazione live
• feedback di stato
• informazioni sull'applicazione
• informazioni sulla licenza

e che il risultato è conservato in una forma che può essere rivista in seguito.
Lo stesso principio si estende ben oltre questa applicazione.
Un processo di login può essere testato così.
Un flusso di prenotazione può essere testato così.
Un processo logistico può essere testato così.
Un'applicazione desktop multipiattaforma può essere testata così.
Le schermate cambiano.
Le regole di business cambiano.
Il principio no:
definire il flusso di lavoro atteso, eseguirlo in modo coerente, raccogliere evidenze e rendere il risultato comprensibile.

Why We Test Our Own Software With COCO

C'è un altro motivo per cui softify.pro Flow conta come caso di studio di COCO.

È il nostro stesso software.
Questo elimina la comoda distanza che a volte esiste tra una dimostrazione tecnologica e le persone che la fanno.

Se COCO deve testare software enterprise, deve essere abbastanza utile perché noi ci fidiamo a usarlo con software che sviluppiamo e rilasciamo noi stessi.

Flow funge quindi sia da prodotto che da banco di prova.
Nuove capacità di test possono essere esercitate contro un'applicazione reale.
Comportamenti inattesi possono rivelare debolezze nell'applicazione, nel piano di test o in COCO stesso.

Ogni lato migliora l'altro.
Questo ciclo di feedback è molto più prezioso della costruzione di dimostrazioni artificiali progettate solo per avere successo. Un sistema di test non dovrebbe sembrare convincente perché la dimostrazione era facile.
Dovrebbe diventare convincente perché continua a trovare le piccole cose che gli esseri umani finirebbero per smettere di controllare.

The Result

softify.pro Flow — Administration ha ora un processo di regressione documentato e ripetibile che COCO può eseguire prima delle release rilevanti.

Il test copre entrambi gli ambienti di database supportati e l'interfaccia in undici lingue dell'applicazione, seguendo l'applicazione come farebbe un amministratore, invece di trattare ogni schermata come un bersaglio di test isolato.

COCO produce una traccia di evidenza che mostra cosa è stato testato, cosa è stato osservato e in quale ordine si è svolta la sessione.

Quella evidenza può rimanere sotto controllo locale.
Gli sviluppatori ottengono un punto di partenza riproducibile quando qualcosa cambia.
I tester umani passano meno tempo a ripetere interazioni prevedibili e più tempo a indagare le situazioni che richiedono davvero giudizio.

E softify.pro Flow riceve qualcosa di più prezioso di un indicatore verde PASS.

Riceve la prova che l'esperienza promessa sulla sua schermata di login continua a esistere dopo che il codice sottostante è cambiato.

Control. Sapere cosa viene testato e tenere l'ambiente sotto controllo.

Clarity. Capire cosa è successo senza dover ricostruire un log di automazione opaco.

Flow. Testare l'applicazione come un processo che le persone usano davvero.

Control. Clarity. Flow.

È stato scritto per il software.
Si è scoperto che descrive altrettanto bene la filosofia di test che ne sta dietro.