PoC - Come approfittare al massimo una Prova di Concetto

Come approfittare al massimo una prova di concetto con AAT?

A cosa serve fare una prova di concetto? Cosa devo tenere in considerazione? Quali conclusioni mi aspetto di ottenere?

Tutti coloro che sono coinvolti in progetti Appian vedono come l'impegno dei tester debba essere adattato a specifici aspetti: picchi nelle consegne, incremento progressivo per effettuare test di regressione...

E quando dobbiamo iniziare un progetto, onestamente, la qualità di solito non è l'aspetto più prioritario, né il testing manuale, né quello automatico (guarda i nostri articoli su questo blog), ma...

Sappiamo che sarà qualcosa di fondamentale e che richiederà una specifica carica di risorse, che dobbiamo dimensionare, e sappiamo cosa succede se non dimensioniamo correttamente!

Se hai molta esperienza nei progetti Appian, sarai in grado di dimensionare correttamente il tuo team di QA. In generale, se il team di sviluppo ha esperienza, i requisiti sono più o meno corretti, e se non automatizzi, ti servono circa 0,4 tester per designer.

E se automatizzi... Hai sufficiente esperienza sul prodotto che stai per utilizzare per dimensionare il team di QA? In genere, la risposta è no, che sia perché hai esperienza sul prodotto ma non su progetti Appian - dove il ritmo dei cambiamenti è più elevato rispetto ad altre tecnologie - o viceversa, perché hai esperienza in Appian ma non sul prodotto.

Questo è esattamente l'obiettivo di una PoC (Proof Of Concept, o Prova di Concetto).

Con una PoC devi confermare il percorso che stai intraprendendo, quanto agile ti rende, quanto velocemente progredisce, come si adatta alla tua metodologia, come coinvolge tutto il team e quali vantaggi ti porterà.

 

La preparazione e i tuoi requisiti per la PoC

 

Ad esempio, se il tuo processo sta analizzando operazioni che devono essere validate,

  • Scegli un'operazione di alto livello, che solitamente è l'inizio dei flussi di questo tipo.
    • Misura quanto velocemente un tester senza conoscenze di programmazione può automatizzarla. Uno schermo normale non dovrebbe richiedere più di 5 minuti.
    • Guarda quanto sia facile per un Product Owner capire il test generato. Dovrebbe essere in grado di riconoscere le azioni e le validazioni presenti.
    • Assicurati che tu possa creare il test senza dover aspettare che il designer abbia creato il suo contenuto, in modo da poter aderire senza problemi a una metodologia BDD.
    • Convalida come si collega alle tue storie utente. Dovresti avere una visione funzionale.
    • Prova come genera le evidenze: file Word con screenshot, video della navigazione, integrazione con suite di test come ALM, ecc.
    • E ora, fai sì che ogni membro del team provi ad eseguire il test: designer, analisti, Product Owner e tester. Tutti devono essere in grado di eseguire un test.
  • Simula un cambiamento dei requisiti.
    • Vedi quanto velocemente chiunque nel progetto, a partire dagli analisti, trova i test che sono influenzati dal cambiamento (analisi dell'impatto).
    • Fai sì che chiunque nel team misuri il grado di impatto. Non vuoi specialisti, vuoi che la qualità sia presente in tutto il team!
    • Misura il tempo impiegato per apportare il cambiamento; ovviamente deve essere sempre molto inferiore rispetto al lato Appian, inferiore all'impatto di crearlo per la prima volta.
    • Valuta se nel lato Appian il cambiamento è stato applicato a un componente riutilizzabile e se hai avuto lo stesso livello di riutilizzo nel test.

 

  • Ora simula un cambio di versione di Appian.
    • Gli strumenti di test generici non capiscono Appian e non sanno cosa significa che tutti i componenti cambiano la loro struttura interna da un giorno all'altro. Ogni volta che c'è un cambio di versione, il rendering di un oggetto Appian potrebbe essere diverso.
    • Se lo strumento che stai valutando non comprende Appian, tutto ciò che è stato automatizzato potrebbe smettere di funzionare.
    • AAT ha un parametro di configurazione in cui indichi quale versione di Appian stai utilizzando, supportando dalla 18.3 alla più recente. Il cambio di versione è trasparente per te.

 

  • Ora valuta l'"industrializzazione".
    • Prevedi di delegare la creazione di un test a un professionista esterno.
    • Misura la curva di apprendimento dei diversi profili disponibili nella tua azienda o nel mercato, con e senza esperienza di programmazione.
    • Valuta cosa comporta l'aggiunta di nuovi ambienti, la migrazione a un ambiente locale senza connessione a Internet, se hai bisogno di database o altre infrastrutture, ecc.
    • Considera come si integrerà con un pipeline DevOps, se può essere eseguito su Kubernetes (o simili) per scalare indefinitamente.
    • Prevedi le licenze calcolando la partecipazione di tutto il team e senza limiti di esecuzione in parallelo.
    • Assicurati che ogni team possa eseguire i propri test completi ogni notte per discutere tutto nelle riunioni giornaliere.

 

  • E infine, prepara i tuoi numeri:
    • Prepara KPI per calcolare il tempo di creazione e aggiornamento del test.
    • Crea un modello dei costi per la formazione, le licenze e l'esecuzione.
    • Assicurati di essere allineato con le metodologie BDD e altre che potrebbero essere richieste.
    • Misura le problematiche che hai prima e dopo l'automazione, e il loro tasso di miglioramento.

...

Raccomandazioni

 

  • Hai un esperto che ti guidi e ti aiuti a iniziare nel modo giusto: chi automatizza i test in Appian deve conoscere la piattaforma e le caratteristiche dei progetti Appian.
  • Lo strumento deve riconoscere gli oggetti della piattaforma Appian.
  • I cambi di versione (ce ne sono almeno 4 all'anno) sono critici per il tuo test e la tua soluzione di automazione deve garantirti un impatto quasi nullo. Gli strumenti generici tendono a fallire su questo punto.

Conclusioni e processo decisionale

Come hai visto, una PoC non è qualcosa di banale.

Una volta definita e eseguita, devi ricevere un riassunto della PoC dal fornitore e preparare le conclusioni e prendere decisioni.

Noi prepariamo sempre un report con i dettagli che abbiamo discusso. Il nostro team conosce Appian e comprende i progetti che ci vengono richiesti, ed è per questo che aiutiamo i nostri clienti a valutare le loro conclusioni mettendo in evidenza i rischi che i prodotti di ambito generale ignorano completamente.

In ogni caso, con la nostra PoC, otterrai una visione innovativa, realizzata da un team di professionisti dedicati esclusivamente ai progetti Appian.

Quando ne avrai bisogno, con AAT avrai uno strumento specializzato pronto ad aiutarti, che ti permetterà di mantenere un impegno per la qualità proporzionato al team di sviluppo, non alla storia del progetto.

E ricorda,

non tutto deve essere automatizzato. Ci sono molti modelli di adozione di uno strumento come ci sono progetti. Quello che conta è che in ogni modello, il ritorno sull'investimento sia sostanziale.

Devi cercare la massima flessibilità e non essere legato al concetto che se non automatizzi una certa quantità, non vale la pena automatizzare.

Related Articles

Image
Follow Us on...
CEITA LinkedIn
London, Barcelona, Madrid, Jaipur
© 2023 CEITA SL. All rights reserved
Save
Cookies user preferences
We use cookies to ensure you to get the best experience on our website. If you decline the use of cookies, this website may not function as expected.
Accept all
Decline all
Session Management
Adobe Experience Cloud
Used for debugging purposes in the Adobe Experience Cloud and contains information about debugging sessions.
Accept
Decline
Analytics
Tools used to analyze the data to measure the effectiveness of a website and to understand how it works.
Google Analytics
Accept
Decline