Il 29 gennaio siamo stati sponsor al QA Financial Forum 2020, il convegno numero uno in Italia per esperti di garanzia di qualità del software del settore Fintech & Insurance. Quali sono i trend di mercato? Come puoi dimostrare il valore dei costi del software testing? Puoi dimostrare di star migliorando la Quality Assurance rispetto al passato? Con queste domande si apre il QA Financial Forum, al quale hanno partecipato speaker provenienti dalle più importanti banche e assicurazioni sul territorio (e non solo). Ad esempio UBI Banca, Banco Mediolanum, N26, Quixa, Generali, Poste Italiane, UniCredit, Monte dei Paschi di Siena e tante altre. Vediamo allora quali sono i trend di software testing e QA in ambito Banking & Insurance di cui abbiamo parlato al QA.
Come puoi dimostrare il valore dei costi del software testing? Puoi dimostrare di star migliorando la Quality Assurance rispetto al passato? Con queste domande si apre il QA Financial Forum. Vediamo quali sono i trend di software testing e QA in ambito Banking & Insurance di cui abbiamo parlato.
Evoluzione della testing factory
Per raccontare al meglio questo aspetto, ripercorriamo un'esperienza di cambiamento e rafforzamento nel testing factory raccontata durante il QA Financial Forum.
Per questa banca* ci sono 2 fattori che hanno spinto al cambiamento: la conversione delle diverse fabbriche di sviluppo e la crescita continua dei servizi digitali. In questa fase di rafforzamento ed evoluzione, la Banca si è posta 2 obiettivi:
- approccio al continuous testing (che cambia il paradigma del test tradizionale)
- passaggio a processi di test industrializzati (il più scoglio da punto di vista culturale)
Per approcciare il cambiamento, il primo asset su cui investire sono per persone: bisogna cambiare le persone, diffondere la cultura della QA. Una volta iniziato il processo di cambiamento della cultura aziendale, l'evoluzione della testing factory ha seguito 5 fasi. Vediamole una ad una brevemente.
Primo step: passare ad un approccio shift left
C'è bisogno di una maggiore efficienza rispetto alla strategia waterfall (che si basa su ciclo di vita del software) per anticipare la bug detection. E' per questo che si passa ad un approccio shift left: la test factory partecipa al tavolo di lavoro.
Secondo step: rafforzamento del test funzionale
Consiste nell'iniziare l'attività di verifica con sessioni di test esplorativi. Questo avviene per analizzare i rischi potenziali, che non emergerebbero dallo scripted test che invece monitora solo quelli già conosciuti.
Terzo step: supportare la crescita delle progettualità agile
Al test manuale si è aggiunto il test automatico. Questa combinazione riesce ad aumentare la velocità di progettazione ed esecuzione dei test. Possiamo definirlo come un rafforzamento dell’automazione.
Quarto Step: riuscire ad anticipare la risposta della clientela
Per farlo, la banca in questione ha utilizzato il Crowdtesting (scegliendo AppQuality come fornitore). Il motivo è semplice: il crowd permette di chiedere ai propri utenti di approvare la user experience (oltre che a trovare i bug), permette di chiedere agli user finali di testare l'usabilità e dare un feedback di altissimo valore.
Quinto step: abilitare la metodologia Devops
Questo significa attivare il continuous testing. Il vantaggio è garantire la qualità ai ritmi serrati dei devops garantendo comunque la qualità.
*Per policy dell'evento, non possono essere ricondotti i dati e le informazioni alle banche che ne hanno discusso.
Il Fuzzing - Fuzz as fast as you can
Il Fuzzing è un approccio quasi opposto a quello del QA. Quello che interessa a un team che si occupa di questa metodologia di testing, ovvero degli hacker interni dell'azienda, è trovare le vulnerabilità nel software interno prima che siano gli altri a farlo.
Iniziamo dal concetto di zero day. Lo zero day indica una vulnerabilità, un bug nel software ancora non individuato. Chi è responsabile del software non conosce il problema, che se trovato può essere usato per creare danno all'azienda.
Obiettivo: trovare il bug prima che lo facciano gli hacker
E’ un gioco a chi è più veloce. Ma perché hackerare? Semplice, per vendere informazioni (sul mercato nero e non), o per entrare dentro il sistema. Ma quindi, siamo al sicuro? I nostri clienti sono al sicuro? Sono al sicuro, sicuramente sono più sicuri gli smartphone del pc. Questo però non vuol dire non essere a rischio. Un caso eclatante è quello di Jeff Besos, CEO di Apple, il cui cellulare è stato hackerato tramite un video ricevuto su whatsapp. Perché è successo? A causa di una vulnerabilità su Whatsapp generata dalla ricezione di un malformed mp4. Ma cosa se ne fa un hacker delle tue vulnerabilità o deti dati dei tuoi clienti? Basta pensare a zeriodium.com, azienda che compra le vulnerabilità trovate a un prezzo che arriva a $2,5mln. Meno retribuito invece lo zero day trovato da desktop (meno diffuso rispetto allo smartphone).
Uno zaro day vale fino a $2,5mln
Ma come si individuano le vulnerabiltà? Capirlo ci aiuta a difenderci meglio. Quello che abbiamo a disposizione sono gli stessi tool che ci sono nel QA. Ci sono due alternative:
- reverse engineering: consiste nel pensare a come un criminale potrebbe hackerare, a cosa potrebbe trovare e dove. Problema: è incredibilmente time consuming.
- fuzzing (che può essere completamente aumotizzato). E' stato introdotto negli anni '50 e sta diventando sempre più popolare. Inizialmente utilizzato in agenzie di sicurezza, sta entrando nell'ambito corporate per individuare i bug.
Il mantra del fuzzing è
Fa sì che il software crashi
E' quindi davvero un approccio opposto al QA, perché consiste nel riuscire a fornire al software un input corrotto (un pdf, un video, ecc) affinché il software crashi. Se crasha, molto probabilmente hai uno zero day. Il processo, una volta automatizzato, dovrebbe entrare in pipeline. Al momento ad utilizzarlo sono gli hacker, Google Project Zero, e ora anche le corporate che per natura dei loro servizi hanno una particolare attenzione alla sicurezza dei dati. Grazie al fuzzing si riescono a trovare quelle vulnerabilità in qualche secondo, mentre con le vecchie metodologie time consuming potrebbero volerci anche anni.
Italy, the blockchain country
Tutto nasce 11 anni fa quando Satoshi Nakamoto rilascia un whitepaper chiamato "A Peer-to-Peer Electronic Cash System" creando un metodo di pagamento tra pari. Se paragoniamo l'andamento del numero di utenti di Internet alla sua comparsa e la crescita dei wallet nella blockchain, ci accorgiamo che si somigliano molto. Nell’arco degli anni la crescita degli utenti che hanno scelto Internet come scambio di valore sarà uguale a quella degli utenti che hanno scelto Internet come canale di scambio di contenuti. Secondo Deutsche Bank, ci vorrà lo stesso numero di anni per avere lo stesso risutato. Secondo Gartner, il valore che la Blockchain è in grado di scatenare è enorme, quindi DOBBIAMO farne progetti, perché questa metodologia governerà lo scambio di valore tra pari.
Non tutte le aziende si sono buttate a capofitto sulla blockchain. Anzi in realtà non sono molte le aziende che hanno deciso di provarci. Il Politecnico di Milano (in particolare l'Osservatorio Blockchain) ogni anno rilascia una ricerca sull'andamento di questo mercato. Da queste ricerche vediamo che questi progetti stanno crescendo in modo lineare, ma la parte privata continua ad essere molto più forte (90% vs il 10% del pubblico). Quali industry ci lavorano di più? Chiaramente il finance.
Ecco 4 punti da tenere a mente quando pensiamo alla possibilità di cimentarsi nel mondo della Blockchain:
- ci vorranno ancora 5-10 anni perché questa tecnologia sia davvero diffusa. Questo significa che hai ancora tempo per iniziare e testarei metodi che ci sono per scambiare valore
- le banche e le compagnie di assicurazioni sono le più affezionate alla Blockchain perché garantisce efficienza
- il settore bancario italiano è avanti in questa rivoluzione. Si sta compiendo uno sforzo notevole di investimento, e per farlo si sta consorziando, perché è il momento di collaborare per acquisire know how (la competizione, poi, sarà su altro)
- preferiamo modelli permissioned per sapere con chi lavoriamo dall’altra parte
- il settore bancario in Italia è davanti agli altri per competenze, esperimenti, approccio, strategia
Fonte immagine: Osservatori Blockchain
Una QA personalizzata: la User Experience dei chatbot
I cicli di produzione e rilascio dei chatbot possono essere abbastanza lunghi e standard se non viene coinvolto l'utente finale. Ce lo racconta una delle Banche presenti al QA Financial Forum, che ha poi deciso di cambiare le carte in tavola. Il nuovo approccio di questa Banca è partire subito, poi cercare di sistemare le cose che dimostrano non funzionare. La necessità è nata dal fatto che la quantità di elementi, argomenti e informazioni da gestire era immensa. Si sono quindi resi conto che per loro era più importante essere attivi su quei temi che cubano una grossa mole di richieste. Hanno cercato di mettere in piedi un meccanismo che permettesse di essere reattivi, e per farlo hanno portato l'end desk all'interno del processo di design. Coinvolti fin da subito, gli operatori dell'end desk hanno condiviso quali le domande (e non gli argomenti) su cui ci sono grandi volumi e su cui l’operatore non potrebbe dare troppo aiuto in più rispetto a un chatbot. Ne è emerso che la maggioranza delle richieste rivolte agli operatori sono standard, ripetitive. Gli operatori stessi hanno adesso il compito di far training al bot in modo tale che ogni giorno vengano analizzate le interazioni che non hanno funzionato. Il giorno stesso, quindi, addestrano il bot. Questo permette al team IT di occuparsi solo della parte infrastrutturale e di avere già il giorno dopo un chatbot allenato su quella domanda. Quello che la Banca ha sottolineato è che la scelta vincente è coinvolgere gli user per rimediare in fretta ai malfunzionamenti.
Per scoprire di più su come allenare un chatbot bancario, leggi questo articolo.
Testare in Monoliti vs Microservizi
Iniziamo con delle definizioni. Parliamo di microservizi quando il software è sviluppato come diversi micro servizi che operano autonomamente. Il monolite, invece, è un enome software con tutti i servizi all'interno dello stesso software package. Quando abbiamo piccole applicazioni dove il cambiamento dei requisiti è molto basso, il monolite è la scelta migliore, Quando invece ci troviamo davanti al ridimensionamento di una app e di conseguenza al cambiamento dei requisiti, il costo aumenta sia per lo sviluppo che per il testing.
L'architettura a microservizi è fatta da un set di piccole applicazioni che possono essere costruite, sviluppate, testate e rilasciate indipendentemente. Danno quindi la libertà di sviluppare e testare le applicazioni per unità, con team di sviluppo indipendenti e, teoricamente, rilasci rapidi.
I benefici dei Monoliti:
- facili da sviluppare
- facili da testare
- facili in fase di deployment
- facili da scalare
Ma:
- se si tratta di un progetto di grandi dimensioni, è difficile da mantenere e coordinare
- se va in down, va TUTTO in down
- la performance rallenta all'aumentare della complessità
- è difficile innovare
I benefici dei Microservizi:
- Per piattaforme grandi e complesse
- deployment più facile per CI/CD
- più facili da testare
- più affidabili
- tecnologicamente indipendenti
Ma:
- si devono affrontare le difficoltà di una piattaforma distribuita
- comunicazione inter-servizi
- complessità di deployment
- la legge di Conway, secondo la quale le organizzazioni disegnano sistemi che sono copie delle strutture di comunicazione di queste stesse organizzazioni.
"le organizzazioni che progettano sistemi ... sono indotte a generare design che sono copie dei legami nelle organizzazioni stesse."
Da considerare, inoltre, che una piattaforma globale ha più regioni, più valute e più regolamentazioni da soddisfare, il che porta a più deployment e più test.
Quali sono quindi le sfide per il testing?
- i servizi globali "servono" gli utenti in regioni isolate
- servizi specifici per determinate regioni dipendono da servizi globali
- i test E2E sono ancora più fragili
- più regioni richiedono diversi rami di deployment
- Il testing scope cresce costantemente
- una sola app è adatta a tutte le regioni
Il Crowdtesting
Il Crowdtesting è l'unico metodo per anticipare la risposta della clientela. L'obiettivo è ottenere un'evidenza anticipata dei potenziali impatti sulla clientela attraverso una community esterna di soggetti eterogenei. In AppQuality, leader del Crowdtesting in Italia, abbiamo una community di tester distribuita in tutto il mondo (di cui 15.000+ solo in Italia). In base alla tipologia di test, Esperienziale o Funzionale, selezioniamo i tester dalla community. In particolare, scegliamo esperti bug finders per i test Functional, mentre per i test di UX selezionamo le persone che corrispondono alle buyer personas dell'azienda cliente.
Perché scegliere il Crowdtesting e non la Testing Automation? Semplice: il Crowdtesting è più veloce e meno costoso. E' più veloce perché si possono vedere i primi risultati in tempo reale già a 24h dall'inizio del test, meno costoso perché i tester vengono ingaggiati esclusivamente per il test (quindi non costituiscono un costo fisso) e vengono remunerati in base alla qualità del lavoro.
Vuoi approfondire una di queste tematiche? Scrivici a info@app-quality.com.
Non perderti i prossimi articoli: registrati alla Newsletter e ricevili via email!
