Potresti avere un CI verde e comunque rilasciare un'app rotta. Il build passa, la QA dà il via libera, il rilascio esce e poi i primi utenti reali incontrano un prompt di autorizzazione che non torna mai, un bundle JavaScript obsoleto o un crash che si manifesta solo su un singolo skin Android. È questo il passaggio che la maggior parte dei processi di assicurazione della qualità trascurano, e che i team mobili imparano di solito in modo difficile.
Un approccio pratico processo di garanzia della qualità è un ciclo chiuso, non una lista di controllo che si ferma quando qualcuno segnala un difetto. Inizia con le specifiche e la progettazione dei test, ma diventa utile solo quando i risultati vengono reintrodotti nelle decisioni di rilascio, nella monitoraggio, nel rollback e nella prossima fase di testing. Se stai distribuendo applicazioni con CapacitorJS o Electron, quel ciclo è ancora più importante perché un bundle web difettoso può influenzare ogni utente contemporaneamente, mentre la revisione nativa rallenta le correzioni definitive.
Indice
- Qual è il processo di garanzia della qualità moderno che copre effettivamente
- Definire obiettivi, ambito e criteri di accettazione testabili
- Scegliere la giusta combinazione di testing automatico e manuale
- Integrare la QA nel tuo flusso di lavoro CI/CD
- Staging, rilascio canario e rilascio graduale senza supposizioni
- Osservabilità e metriche che individuano problemi prima che gli utenti li segnalino
- Recupero di incidenti, rollback e apprendimento delle lezioni giuste
Cosa copre effettivamente un processo di garanzia della qualità moderno
Un moderno processo di garanzia della qualità è un ciclo chiuso con punti di controllo chiari. La sequenza pratica è analisi delle richieste, pianificazione dei test, progettazione e sviluppo dei casi di test, configurazione dell'ambiente, esecuzione, tracciamento dei difetti, retesting e regressione, validazione della versione di rilascio e chiusura dei test. I controlli più importanti sono ancora quelli noiosi, la tracciabilità dalle richieste ai test e un formalismo loop di triage e verifica dei difettipoiché le correzioni non sono valide fino a quando non sono state confermate prima della chiusura, come descritto nel guida del processo di QA da TestSigma.
il ciclo non si ferma al rilascio
Una buona assicurazione della qualità non si ferma quando un candidato di rilascio è verde. Continua attraverso la validazione in produzione, i segnali di supporto, la ripresa degli aggiornamenti in tempo reale e il prossimo sprint di progettazione di test. È lì che molti team sbagliano, perché trattano i difetti come biglietti invece di come prove che i requisiti, i test o i guardiani di deploy devono cambiare.
Un modo utile per pensare all'assicurazione della qualità è come un sistema di gestione, non come un punteggio. Il passaggi del processo di assicurazione della qualità i punti di orientamento evidenziano che molti programmi trascurano i circuiti di feedback dei clienti e l'evaluazione inter-chanel, e che questo gap è importante anche per le squadre di app. Se il supporto continua a vedere le stesse lamentele dopo il rilascio, il processo non ha imparato, ha solo misurato.
Cosa misurare prima di aggiungere strumenti
Prima di acquistare più strumentazione, ottieni chiarezza sui segnali che il tuo team utilizzerà per decidere se un build è sicuro. Di solito significa definire la porta di rilascio, i proprietari per ogni porta e i criteri di rollback se qualcosa sfugge.
Un insieme pratico di partenza è semplice:
- Copertura delle richiesteCopertura delle richieste, che mostra se ogni regola visibile dall'utente ha almeno un test.
- Gravità e proprietà dei difettiGravità e proprietà dei difetti, in modo che il team sappia cosa blocca la release e chi risolve il problema.
- Portata della regressionePortata della regressione, in modo che le correzioni non riaprono vecchi problemi in flussi adiacenti.
- Segnali post-releaseSegnali post-release, in modo che i feedback di produzione cambino il ciclo di test successivo invece di rimanere in un dashboard.
Per le squadre che cercano di ridurre il lavoro manuale in processi operativi adiacenti, la guida sul riduzione dei costi del lavoro Dooza è un esempio utile di come una revisione strutturata e una mano chiara possono ridurre lo sforzo sprecato. La QA funziona allo stesso modo, quando il ciclo è esplicito, le persone smettono di indovinare. Se il tuo processo attuale ti dice solo cosa è fallito, non cosa cambia successivamente, è incompleto. Quella è la differenza tra un routine di testing e un sistema di qualità reale. Per un angolo di gestione della release che si adatta a quel mindset, questa guida interna su
Dooza labor cost reduction guide processo di gestione delle rilascio si abbina bene con lo stesso approccio a ciclo chiuso.
Definire Obiettivi, Scope e Criteri di Accettazione Testabili
La QA diventa più acuta quando il linguaggio del prodotto si trasforma in linguaggio testabile. Una richiesta come “rendi il checkout veloce” è impossibile da verificare in modo pulito, mentre “mostra la schermata di conferma del pagamento dopo che il provider restituisce successo e prima che l'utente chiuda l'app” è testabile, tracciabile e utile sia per l'ingegneria che per il supporto. Quella tracciabilità è uno dei punti di controllo fondamentali nel modello a ciclo chiuso dal paragrafo precedente.
Scrivi i criteri di accettazione nel modo in cui un tester può eseguirli
Per un'applicazione CapacitorJS, considera un flusso di pagamento. Se l'app utilizza una scheda di pagamento terza parte, i criteri di accettazione dovrebbero coprire cosa succede quando la scheda ha successo, fallisce, esaurisce il tempo o viene annullata. Se il flusso dipende dalle autorizzazioni della fotocamera, delle autorizzazioni della posizione o del consenso per le notifiche push, ogni branch ha bisogno del proprio esito visibile perché una richiesta di autorizzazione può comportarsi in modo diverso su iOS e Android.
Un modello leggero funziona bene:
- Data l'utente è autenticato.
- Quando tappano il pulsante di pagamento.
- Allora L'app presenta l'interfaccia di pagamento e conferma il successo o mostra uno stato di errore ripristinabile.
- E L'evento è tracciabile a un ticket di rilascio, quindi la QA può mappare le fallite su una richiesta.
Il punto non è rendere ogni frase formale. Il punto è assicurarsi che un essere umano possa capire se il feature sia stato eseguito senza discutere l'intento in seguito. È anche lì che la checklist interna in valida gli aggiornamenti dell'app Capacitor definisce lo scope del rilascio in base al rischio, non all'ottimismo
Un rilascio con scope è più facile da difendere di uno vago. Le superfici a rischio alta meritano una copertura più ampia, mentre le modifiche ai copioni o le correzioni isolate della UI possono essere controllate con controlli più leggeri se la superficie di dipendenza è piccola. In pratica, ciò significa segnalare qualsiasi cosa tocchi l'autenticazione, il pagamento, i permessi, il comportamento offline o le bridge native per una revisione più approfondita.
Regola pratica:
Se un feature può fallire in un modo che blocca l'utilizzo di base, ha bisogno di criteri di accettazione espliciti e almeno un percorso di validazione non unitario. Le feature che non possono essere esercitate bene con test di unità o di integrazione non devono essere ignorate. Hanno bisogno di un'altra layer, spesso un passaggio manuale, un controllo specifico per dispositivo o un passaggio di validazione di fase di rilascio. È vero soprattutto per le app Electron che dipendono da dialoghi di sistema, accesso ai file o stranezze del browser che i test dei componenti non modelleranno fedelmente.
Features that can’t be exercised well in unit or integration tests shouldn’t be ignored. They need another layer, often a manual pass, a device-specific check, or a release-stage validation step. That’s especially true for Electron apps that depend on OS-level dialogs, file access, or browser quirks that your component tests won’t model faithfully.
Se riesci a definire il contesto giusto, la QA non sembra più una discussione all'ultimo minuto. L'equipe sa cosa deve essere dimostrato, cosa può essere campionato e cosa richiede gli occhi umani perché il confine dell'automazione finisce lì.
Scegliere la giusta miscela di test automatizzati e manuali
L'automazione riceve l'attenzione perché scala, ma riesce a catturare solo ciò che può modellare. I test manuali vengono scartati come lenti, ma spesso sono l'unica via per catturare il deriva visivo, gli issue specifici del dispositivo o la stranezza del flusso che emerge quando un utente utilizza l'app. Un processo di garanzia della qualità equilibrato richiede entrambi, e lo split dovrebbe seguire il rischio, non l'ideologia. Ciascun layer è più adatto a
I test unitari e di integrazione sono più forti quando la logica è deterministica. In una pila CapacitorJS o Electron, ciò significa Jest per la logica commerciale, i riduttori di stato, gli aiuti e il comportamento dei componenti, più i test di integrazione per i confini di __CAPGO_KEEP_0__, l'elaborazione degli aggiornamenti e le branche di gestione delle autorizzazioni.
Unit and integration tests are strongest when the logic is deterministic. In a CapacitorJS or Electron stack, that means Jest for business logic, state reducers, helpers, and component behavior, plus integration tests for API boundaries, update parsing, and permission-handling branches. Cypress fits well when you want browser-driven end-to-end coverage of the web layer, while Detox-style flows matter when you need device-level mobile interaction and you can afford the maintenance cost.
La verifica manuale guadagna il suo posto dove il contesto conta. Le sessioni di esplorazione individuano percorsi di navigazione inaspettati, un mismatch del dark-mode, un sovrapposizione del tastierino su un dispositivo piccolo, o un modulo che si chiude troppo presto su una versione di sistema operativo. Ciò conta anche per l'accessibilità, perché l'ordine del lettore di schermo, le trappole di focus e gli issue di contrasto sono spesso più facili da scoprire provando l'applicazione che non fidandosi delle sole verifiche statiche.
Se desiderate una visione più ampia delle categorie di automazione e dei compromessi, Le strumenti di testing di Appjet.ai sono una utile punto di riferimento di confronto. Per le squadre che stanno standardizzando la loro pila, l'overview di testing automatizzato aiuta a definire dove di solito si trova il confine. L'automazione versus la verifica manuale per scenario Scenario Scelta migliore
Perché
| Logica commerciale pura in un modulo condiviso | Automatizzato | La verifica manuale guadagna il suo posto dove il contesto conta. Le sessioni di esplorazione individuano percorsi di navigazione inaspettati, un mismatch del dark-mode, un sovrapposizione del tastierino su un dispositivo piccolo, o un modulo che si chiude troppo presto su una versione di sistema operativo. Ciò conta anche per l'accessibilità, perché l'ordine del lettore di schermo, le trappole di focus e gli issue di contrasto sono spesso più facili da scoprire provando l'applicazione che non fidandosi delle sole verifiche statiche. |
|---|---|---|
| Se desiderate una visione più ampia delle categorie di automazione e dei compromessi, | Le strumenti di testing di Appjet.ai sono una utile punto di riferimento di confronto. Per le squadre che stanno standardizzando la loro pila, l'overview di testing automatizzato aiuta a definire dove di solito si trova il confine. | Feedback rapido, input stabile, facile da ripetere |
| Gestione delle chiamate del provider di pagamento | Automatizzato più manuale | La logica può essere scritta, ma l'esperienza utente richiede una validazione umana |
| Prompt di autorizzazione su iOS e Android | Manuale per primo | Il comportamento del sistema e lo stato del dispositivo possono cambiare il flusso |
| Retrocessione visiva su una schermata di impostazioni | Manuale più strumenti visivi | I bug di layout sono più facili da individuare con un passaggio reale |
| Comportamento di sincronizzazione offline e riattivazione | Automatizzato più test di dispositivo | La necessità di copertura ripetibile per il timing, le ripetizioni e la ripresa dello stato |
| Feedback beta su una nuova bandiera di feature | Manuale | Il comportamento reale spesso rivela le lacune che i test non coprono |
Dove i tester beta esterni aiutano
Gli tester beta esterni sono utili quando il tuo team interno ha troppo contesto condiviso. Non riprodurranno le tue assunzioni, il che è il punto. Sono particolarmente efficaci per i candidati di rilascio che coinvolgono l'accesso iniziale, le autorizzazioni di prima esecuzione o flussi che dipendono dal comportamento di utente sconosciuto.
La trappola è l'eccessiva enfasi su un lato o l'altro. Un piano di test che è tutto automatizzato trascura la sfumatura umana. Un piano di test che è tutto manuale diventa costoso, incoerente e facile da saltare quando i tempi stringono. La risposta giusta è spesso una base automatizzata stabile con una copertura umana deliberata sulle superfici più probabili a rompersi nel mondo.
Integrare la garanzia di qualità nel tuo pipeline CI/CD
La qualità della garanzia dovrebbe essere garantita, non solo spostare gli artefatti. Il pipeline funziona meglio quando ogni fase ha un unico lavoro, perché la mescolanza di preoccupazioni rende le fallite più difficili da comprendere e più lente da risolvere. Un buon processo di garanzia di qualità colloca i controlli dove bloccano il cattivo code presto, poi preserva lo stesso artefatto mentre si muove verso il rilascio.
Colloca le verifiche economiche per prime
Su ogni commit, esegui le verifiche che sono veloci e deterministiche. La formattazione, le verifiche di tipo, i test unitari e i test di integrazione focalizzati dovrebbero fallire prima che qualcuno spenda tempo per creare binari nativi. Ciò mantiene il rumore basso e rende la prossima fase, la costruzione, degna del costo di calcolo.
Dopo di che, i costrutti chiusi dovrebbero produrre binari iOS e Android firmati quando cambiano i binari nativi code. Se il cambiamento è solo nella layer web di un'app Capacitor, hai ancora bisogno della pipeline per costruire il bundle web, verificarlo e pacchettarlo in modo che possa essere promosso in modo sicuro. La chiave è l'identità degli artefatti, il bundle che ha superato le prove dovrebbe essere lo stesso che raggiunge la fase di staging o produzione.
Promuovi gli artefatti, non solo gli ambienti
La promozione dell'ambiente senza la promozione dell'artefatto è dove le squadre creano deriva. Vuoi che lo stesso bundle si muova da QA interna a staging a produzione ogni volta che è possibile, altrimenti stai testando una cosa e spedendo un'altra. Ciò si applica proprio quanto agli app Electron, dove la confezione e la firma dovrebbero far parte della porta di uscita di rilascio, non un postscripto.
Regola pratica: Se un costrutto non può essere tracciato da commit a artefatto firmato a versione distribuita, la tua pipeline manca della catena di prova QA richiede.
Per le squadre Capacitor, gli strumenti di aggiornamento in tempo reale possono ridurre il divario tra verifica e rilascio. Un bundle web testato può andare a staging senza ricostruire i binari nativi, il che rende l'iterazione molto più veloce quando la shell nativa non è cambiata. impostazione di integrazione continua questa guida è rilevante qui perché CI dovrebbe sapere come pubblicare un bundle validato nel canale giusto automaticamente.
La versione breve è semplice. CI CD non dovrebbe chiedere, “È passato il build?” Dovrebbe chiedere, “È stato questo artefatto esatto a superare le verifiche giuste, nell'ambiente giusto, con la porta di controllo giusta davanti agli utenti?”
Aggiungi un controllo di integrazione in fase avanzata
Alcune fallite si manifestano solo quando sono coinvolti sistemi esterni. È in questo momento che un passaggio end-to-end mirato è utile, soprattutto per i provider di autenticazione, i gateway di pagamento, i token di push o le flussi di verifica via SMS. Se hai bisogno di un punto di riferimento più ampio per la copertura dei test di integrazione nei flussi di lavoro della piattaforma, il guida di integrazione di attivazione via SMS è un utile riferimento che ricorda che le dipendenze esterne meritano una verifica esplicita, non la speranza.
Quando il pipeline è costruito in questo modo, la QA smette di essere una cerimonia separata. Diventa parte della consegna stessa.
Rilascio in Staging, canarino e in fasi senza la congettura
Staging, canarino e rilascio in fasi non sono intercambiabili. Risolvono problemi diversi, e le squadre si mettono in difficoltà quando usano uno come se fosse tutti e tre. Un processo di garanzia della qualità sano tratta loro come strategie di rilascio separate con radii di impatto separati e punti di decisione separati.
Ciascuna fase di rilascio è destinata a
Staging è l'ultimo checkpoint di alta fedeltà prima della produzione. Dovrebbe riflettere la produzione il più possibile per consentire ai team di validare l'edizione, il flusso dei dati e la confezione di rilascio in condizioni realistiche.
Canary è per imparare da una piccola porzione di utenti reali. Rende visibili gli errori specifici del dispositivo e della rete che lo staging spesso trascura perché il mondo è più caotico di qualsiasi ambiente pre-prod.
Roll-out fasi amplia gradualmente l'esposizione dopo i primi segnali appaiono sani. È il modo più sicuro per espandere il raggio d'azione perché non si scommette tutta la base di utenti su una sola decisione di rilascio.
Come i canali di tipo Capgo si mappano alla strategia di rilascio
Il design dei canali è importante per gli strumenti di aggiornamento in tempo reale. Un canale può servire ai test interni, un altro può mirare ai gruppi di beta, un terzo può tenere la prima ondata di produzione e un quarto può esistere solo per il rollback di emergenza. Quella separazione dà all'ingegneria e al supporto un modo per isolare il rischio senza dover attendere una nuova sottoscrizione del negozio.
Questa è anche dove l'assegnazione di dispositivo mirata aiuta. Se un utente o un dispositivo specifico richiede la debug, un canale può essere impostato solo per quel caso, il che mantiene il resto della base su una versione nota buona. Capgo supporta quel tipo di flusso di assicurazione della qualità mirata per Capacitor app, che è utile quando il bug è difficile da riprodurre e hai bisogno di osservare un dispositivo senza cambiare lo stato di rilascio di tutti gli altri.
I criteri di graduazione dovrebbero essere espliciti
Un build dovrebbe avanzare solo quando la prova dice che può farlo. Di solito significa che la fase precedente ha superato le sue verifiche definite, non è apparso un nuovo schema di crash e la coda di supporto non si riempie con la stessa lamentela. Se il segnale è incerto, tieni il build dove è.
Una semplice regola di promozione aiuta:
- QA interna a staging, solo dopo che l'artefatto esatto supera i controlli di fumo e le flussi di utente critici.
- Staging a canary, solo dopo che l'ambiente di alta fedeltà corrisponde al comportamento previsto.
- Canary a rilascio graduale, solo dopo che gli utenti precoci mostrano un comportamento stabile e il supporto può spiegare il rilascio in termini semplici.
- Rilascio graduale a produzione completa, solo dopo che l'osservabilità di produzione rimane pulita a sufficienza per far sì che il tuo team possa fidarsi della tendenza.
È questo il momento che elimina la congettura. La promozione diventa una decisione basata su prove, non una celebrazione del progresso.
Osservabilità e Metriche che Catturano Problemi Prima che gli Utenti Li Segnalino
Una volta che il rilascio è live, la QA non scompare. Cambia forma. L'osservabilità in produzione è la parte del processo di garanzia della qualità che ti dice se il rilascio si è comportato come i test dicevano che si sarebbe comportato, e se gli utenti stanno incontrando fallimenti che il tuo ambiente di laboratorio non ha mai visto. Per le app mobili e cross-platform, significa guardare ai segnali per dispositivo, salute degli aggiornamenti e modelli di errore insieme. Guarda i segnali che riflettono il dolore degli utenti
Il metriche più utili sono quelle che si correlano con il vero guasto. Le sessioni senza crash, i tassi di errori JavaScript, i tassi di fallimento di rete, l'adozione degli aggiornamenti e i tassi di fallimento degli aggiornamenti ciascuno racconta una parte diversa della storia. Se l'app manca di uno di quei segnali, il supporto finisce per sentire parlare del problema prima che l'ingegneria lo faccia.
Per un'app __CAPGO_KEEP_0__ o Electron, i log per dispositivo contano perché lo stesso rilascio può comportarsi in modo diverso su versioni OS, fattori di forma o stati di aggiornamento. Una piattaforma di aggiornamento live può esporre dati di adozione e fallimento per dispositivo, il che dà all'ingegneria un modo per vedere se è necessario un rollback o se il problema è isolato in una piccola porzione.
For a Capacitor or Electron app, per-device logs matter because the same release can behave differently across OS versions, form factors, or update states. A live-update platform can expose adoption and failure data by device, which gives engineering a way to see whether a rollback is needed or whether the issue is isolated to a small slice.
Osservabilità e metriche che catturano problemi prima che gli utenti li segnalino
Le dashboard falliscono quando nessuno assume la responsabilità della risposta. Ogni metrica richiede un proprietario, una condizione di allarme e un passo successivo standard. Se le fallite degli aggiornamenti aumentano, qualcuno deve decidere se sospendere il canale, tornare indietro sul pacchetto o pubblicare una nuova patch.
Un setup pratico assomiglia a questo:
- Monitoraggio dei crash e degli errori, per rilevare l'instabilità dell'applicazione in modo rapido.
- Tracciamento dell'adozione degli aggiornamenti, per vedere se gli utenti ricevono il pacchetto corretto.
- Alert per il tasso di fallimento, per catturare i pacchetti difettosi prima che il supporto si accumuli.
- Drilldown a livello di dispositivo, per consentire alla squadra di separare le fallite ampie dalle informazioni di rumore specifiche della piattaforma.
Un dashboard è utile solo quando cambia una decisione, altrimenti è solo uno screenshot con più schede.
I segnali di produzione del feed vengono reimpostati nella prossima release
Le migliori squadre QA convertono i dati post-rilascio in nuovi test. Se una classe di dispositivo specifica non è riuscita ad applicare un aggiornamento, aggiungi un caso di validazione per quel percorso. Se un tentativo di rete si comportava male su una piattaforma, rendi quella modalità di fallimento parte del prossimo piano di test. È così che l'osservabilità diventa un input per la qualità piuttosto che un lato del pannello di controllo degli operativi.
Lo strumento di rilascio diventa parte della QA al posto di essere solo la distribuzione. Quando le squadre possono vedere quali dispositivi sono stati aggiornati, quali sono falliti e quale versione del pacchetto è in linea, possono rispondere prima che gli utenti inondino il supporto. I log per dispositivo di Capgo e i guardiani del canale si adattano bene a quel modello per le squadre che hanno bisogno che il processo di rilascio rimanga spiegabile dopo il lancio.
Recupero da Incidenti, Annullamento e Apprendimento delle Lezioni Giuste
Il momento in cui un rilascio cattivo atterra è dove il processo di assicurazione della qualità dimostra se era reale. Una squadra può avere una pianificazione forte, una copertura di test decente e un flusso di lavoro pulito, poi perde tutto il valore se non può riprendersi velocemente o imparare dalle sue mancate.
Triage per primo, spiegazione seconda
Quando un rilascio va male, il primo compito è confermare lo scopo. È isolato a un sottoinsieme di dispositivi, legato a una versione specifica o che colpisce l'intera platea? Una volta chiaro, la squadra può scegliere tra l'annullamento, la sospensione del canale o un intervento chirurgico di patching.
Per piattaforme di aggiornamento in tempo reale, una modifica JavaScript o CSS può essere spesso annullata in pochi minuti senza dover attendere la revisione di App Store o Play. Ciò conta perché la differenza tra un'esperienza negativa e un incidente controllato spesso dipende da quanto velocemente il team può fermare la diffusione. Il guida di risposta all'incidente è il riferimento di riferimento giusto se il suo team desidera un playbook operativo più pulito per quella fase.
Scrivi la revisione dell'incidente in modo che cambi il comportamento
Un documento post-incidente richiede più di una causa radicale. Dovrebbe registrare cosa è stato osservato, quali segnali erano disponibili, quale era la prima assunzione sbagliata e cosa avrebbe potuto catturare l'errore prima. Se la stessa classe di difetto potrebbe accadere nuovamente, il documento dovrebbe produrre un cambiamento nelle criteri di accettazione, un nuovo caso di test o una barriera di CI.
Le uscite di revisione utili includono:
- Un criterio di accettazione correttose la richiesta originale era troppo vaga.
- Un nuovo test di regressionese la falla era tecnicamente prevenibile.
- Un guardrail di distribuzionese l'errore avrebbe dovuto rimanere in staging più a lungo.
- A nota di supporto, se le squadre di supporto ai clienti hanno bisogno di uno script migliore per la prossima volta.
Regola pratica: se il post-mortem non modifica una porta, un test o una regola di distribuzione, è probabilmente solo documentazione.
Quel ciclo di apprendimento è ciò che distingue la QA matura dal teatro di rilascio. Il rilascio è fallito, la squadra l'ha contenuto e il processo è diventato più rigoroso nel punto preciso in cui era debole.
Capgo aiuta le squadre a rendere quel ciclo più breve facendo partire aggiornamenti live, mirando ai canali e fornendo ai proprietari di rilascio visibilità a livello di dispositivo quando qualcosa va storto. Se si cerca di costruire un processo di garanzia della qualità più sicuro per le applicazioni CapacitorJS o Electron, visitate __CAPGO_KEEP_0__ Capgo Scritto da
