Sotto il cappello dei performance test c'è un ampio spettro di test che vengono eseguiti.

Di fatto vengono simulati i comportamenti degli utenti reali verso un prodotto, che sia un sito, che sia un'applicazione, che sia magari un insieme di API che vengono richiamate dal sito, in modo da simulare quello che è la "journey" di utilizzo dell'utente reale.

In questo modo posso andare a vedere come si comporta il mio sistema e vedere se ci sono dei colli di bottiglia o dei problemi di prestazione, cioè determinate richieste che causano un rallentamento maggiore del sistema o una eccessiva rapidità con cui arrivano gli utenti.

Salve a tutti, siete all'ascolto di INSiDER - Dentro la Tecnologia, un podcast di Digital People e io sono il vostro host Davide Fasoli.

Oggi parleremo con UNGUESS di "performance test", ovvero di tutti quei test che verificano che un sito web, un software o un servizio mantengano elevate prestazioni anche in condizioni di stress o uso intenso.

Prima di passare alle notizie che più ci hanno colpito questa settimana, vi ricordo che potete seguirci su Instagram a @dentrolatecnologia, iscrivervi alla newsletter e ascoltare un nuovo episodio ogni sabato mattina, su Spotify, Apple Podcast, YouTube Music oppure direttamente sul nostro sito.

Da diversi anni Google sta lavorando e investendo milioni di dollari nel settore della computazione quantistica.

Come risultato è proprio Google l'azienda che dal 2019 detiene la supremazia in questo settore.

E qualche giorno fa l'azienda ha presentato un nuovo chip quantistico che questa volta potrebbe aprire la strada alla costruzione di computer commercializzabili e su larga scala.

La più grande sfida ad oggi nel lavorare con i "Qbit" o Quantum Bit, di cui avevamo parlato in una puntata, è legata alla soppressione del rumore e alla correzione degli errori.

I Qbit infatti sono molto instabili e il loro stato può variare rapidamente restituendo risultati sbagliati o indesiderati.

Con la nuova architettura di Google, chiamata "Willow", sono stati fatti dei passi da gigante in questo ambito, riducendo gli errori esponenzialmente grazie all'introduzione di alcuni Qbit dedicati proprio a proteggere le informazioni dal rumore.

Questo ha permesso non solo di aumentare ulteriormente i Qbit del chip, ma come detto all'inizio, potrebbe essere una svolta nel produrre chip su larga scala e utilizzabili commercialmente, aprendo nuove possibilità nell'utilizzo di algoritmi pratici ad oggi impossibili da eseguire su computer tradizionali.

OpenAI questa settimana ha lanciato ufficialmente Sora, il modello avanzato di intelligenza artificiale presentato a febbraio, che permette la generazione di video realistici in alta risoluzione attraverso stringhe di comandi testuali, immagini statiche o altri video di partenza.

Attualmente il nuovo sistema di OpenAI è disponibile solamente per gli abbonati ai piani Plus e Pro di ChatGPT, dal costo rispettivamente di 20 e 200 euro al mese.

Inoltre al lancio sono stati esclusi il Regno Unito, la Svizzera e l'intera area economica europea.

Tuttavia OpenAI ha dichiarato di voler estendere l'accesso a Sora anche a questi paesi.

La versione di Sora rilasciata questa settimana è stata potenziata notevolmente rispetto al modello annunciato a inizio anno, tant'è che ora è sia più veloce ma anche più efficiente nella generazione di video, rendendo l'esperienza finale ancora più fluida e immediata.

Alcune differenze sono state introdotte anche sulla base della tipologia di abbonamento sottoscritto.

Chi possiede un piano Plus da 20 euro avrà infatti fino a 50 generazioni da 20 secondi massimo con una risoluzione di 720p, mentre chi è sottoscritto alla versione Pro da 200 euro potrà generare video illimitati in 1080p, con l'ulteriore possibilità di scaricare i contenuti senza watermark.

Una buona esperienza utente o "UX", e in particolare l'interfaccia utente o "UI", si occupano di garantire che un software o un sito web abbia un design accattivante e intuitivo.

Ma è altrettanto necessario che questa interfaccia risponda in modo immediato e senza interruzioni a ogni nostra interazione.

Oltre all'interfaccia grafica, quindi, la velocità e la reattività di un software sono elementi cruciali per determinare il livello di soddisfazione dell'utente.

Ma come si può garantire che un sito web mantenga elevate prestazioni anche in condizioni di stress o di uso intensivo, magari da parte di migliaia di utenti contemporaneamente? Per approfondire questo tema è con noi Edoardo Vannutelli, Testing Automation Senior Manager e Co-Founder di UNGUESS.

Benvenuto Edoardo.

Grazie mille, è un piacere essere qua.

Questa è la seconda puntata che realizziamo con voi, con UNGUESS, qualche mese fa abbiamo parlato con Alessandro Caliandro di UX e UI appunto, quindi di esperienza utente e interfaccia utente.

E oggi invece ci concentriamo sulle prestazioni, sulle performance di un sito web, di un servizio, di un software.

In questo senso, quindi, che ruolo gioca la reattività di un sito o di un servizio per la soddisfazione dell'utente finale?

Ma, gioca un ruolo cruciale, con Alessandro avete parlato della UX, la User Experience, sicuramente la velocità è un fattore determinante per garantire anche una, concorre a definire una User Experience di valore.

Diciamo che più un software è lento, più un software ha delle interruzioni, non è costante le sue performance, più porta frustrazione all'utente.

Quindi ci sono alcuni elementi fondamentali che ci danno valore, quindi riduce, le buone performance riducono la frustrazione che l'utente potrebbe provare durante l'utilizzo del software, aumenta la produttività, posso fare più attività in un tempo ridotto, ho più tempo per usare altre funzionalità dello stesso prodotto.

Anche un fattore molto importante è la percezione della qualità, se io ho un software reattivo, un software che mi consente di fare rapidamente le operazioni che voglio andare a fare, che sia un bonifico bancario, ma anche solo la pubblicazione di un post in un qualche social network, la velocità mi fa percepire anche una qualità molto superiore,

soprattutto l'assenza di lag, cioè dei comportamenti dove la velocità non è costante, faccio tre operazioni, ho un tempo di attesa per portarla a termine, ho un "loading" molto più lungo rispetto agli altri, questo mi dà una percezione di un prodotto di qualità più bassa.

Tutto questo concorre a un coinvolgimento maggiore dell'utente, più è veloce, più è immediata, più apprezzo l'utilizzo di quel software e di conseguenza abbassa drasticamente il tasso di abbandono.

L'esempio classico un e-commerce, se io ho una ricerca molto complicata, una ricerca molto lenta, magari se inserisco un parametro di un prodotto che conosco e devo attendere molto perché mi si presenti, sono più portato a usare magari un altro e-commerce o un altro servizio che mi consente di acquistare il prodotto.

Anche perché oggi siamo abituati alla velocità e quindi ci metto un attimo a cambiare sito potenzialmente se è il primo dove sto cercando di acquistare qualcosa ad esempio non funziona ecco è molto facile cambiare potenzialmente l'esercente.

Esattamente, siamo abituati alla velocità e abbiamo una grande offerta.

Sono pochi i servizi esclusivi, cioè che mi danno... quei prodotti che mi offrono un servizio esclusivo.

Quindi sono orientato, ho molta selezione, molta scelta.

Da questo punto di vista oggi c'è più sensibilità sulla cura dell'estetica e dell'intuitività di un software, di un sito web, oppure c'è altrettanta attenzione alle sue performance?

Purtroppo nella realtà dello sviluppo c'è un po' di, ancora un po' di iato tra quelli che sono la parte di design e quella che è la parte di sistema, nel senso che chi fa design si aspetta che poi i sistemisti, gli sviluppatori, tutto quello che si occupa sia di creazione del software che di prodotto si muova indipendente e garantisca un livello d'uso.

Diciamo che sono due realtà che vanno molto a braccetto.

nel senso dovrebbe esserci ancora più collaborazione, sarebbe bello che ce ne fosse sempre di più, dove i due temi, sia di usabilità che di performance del prodotto, collaborino insieme.

Diciamo che tipicamente è molto una scelta di brand, di brand o di chi produce il prodotto.

Si ha un focus più forte verso la UX e più forte sulla parte tecnologica delle performance.

Però devono essere coltivati entrambi.

La cosa molto bella è che dove c'è sinergia si può fare sponda.

Vale a dire ci sono delle soluzioni dove una particolare richiesta: ho un sito e devo ottenere la lista dei miei prodotti acquistati negli ultimi 15 giorni, è una richiesta che sarà veloce se sono un privato.

Se sono magari un'azienda e sto facendo l'elenco degli ordini degli ultimi 12 mesi perché sono a fine anno, chiaramente quel tipo di richiesta dal punto di vista tecnologico è più lenta.

E quindi avere dall'altra parte una sponda UX che aiuti a dare un messaggio opportuno durante le attività, quindi mi disegni un'interfaccia grafica che mi faccia capire cosa sta succedendo alla macchina e mi giustifichi quel tempo di attesa o me lo mascheri, succede anche quello e non è un pattern cattivo di design,

però mi dia qualcosa di grafico che mi fa percepire un'attesa più bassa è molto importante.

Un esempio classico sono i "loader".

Se un loader accattivante che mi fa percepire, magari mi dice uno stato di che cosa sta processando, ho processato il mese di gennaio, febbraio, marzo, mi dà un feedback che mi rende quell'attesa più comprensibile e magari anche più piacevole da vedere.

Quindi diciamo è un gioco di sponda che viene fatto. Molto spesso, purtroppo è più delegato ai singoli che devono trovare poi una quadra per cui... è legato al punto di test.

Diciamo che forte pressione in questo momento viene messa dal lato sviluppo dove vengono chiesti tempi di risposta molto ridotti per avere più libertà in fase di UX.

Però da caso a caso varia molto.

Per fare un esempio - dimmi se può essere corretto di quello che hai appena detto - penso da una parte un sito web che premendo un tasto parte il caricamento e non succede nulla di nulla e dall'altro lato un sito che premendo il tasto, benché ci sia un limite perché come hai detto tu le informazioni devono essere recuperate, possono metterci del tempo, mi

fa vedere una barra di progressione di questo tempo di attesa, ecco.

Esattamente, esattamente, questo è lo scenario, hai sintetizzato perfettamente il caso.

e poi penso comunque che sia importante investire in questo ambito... appunto è un investimento perché come dicevi prima sono al rischio di perdere il cliente quindi bisogna andare avanti di pari passi sia con la UX e anche garantire appunto queste performance del servizio che si mette a disposizione.

Diciamo che oggigiorno sono proprio effettivamente le due parti di una mela, cioè la percezione del prodotto è data da entrambi i fattori. La qualità è difficile riuscire a perseguirla con un solo di questi aspetti.

E a proposito di questo, appunto del tema di oggi, ci spieghi nella pratica che cos'è un performance test, perché appunto è importante - questo in parte l'abbiamo già capito - e se ci sono anche degli esempi concreti che puoi farci di come un performance test ha salvato una situazione che altrimenti sarebbe stata disastrosa.

Sotto il cappello dei performance test c'è un ampio spettro di test che vengono eseguiti.

Sostanzialmente per sintetizzarli in estrema sintesi: di fatto vengono simulati i comportamenti degli utenti reali verso un prodotto, che sia un sito, che sia un'applicazione che sia magari un insieme di API che vengono richiamate dal sito in modo da simulare quello che la "journey" di utilizzo dell'utente reale

in questo modo posso andare a vedere come si comporta il mio sistema quindi i server, banalizzando un po' la cosa ma giusto per capirci quindi il database, il server web, l'eventuale interfaccia e vedere se ci sono decolli di bottiglia o dei problemi delle prestazioni cioè determinate richieste che causano un rallentamento maggiore del sistema,

un'eccessiva concorrenza degli utenti che possono creare problema, o una eccessiva rapidità con cui arrivano gli utenti.

Il sistema del mondo tecnologico in questo momento, negli ultimi anni ha fatto una migrazione verso cloud molto forte e si sta portando sempre più verso servizi "serverless" dove non ho fisicamente il pezzo di ferro a casa quindi che monitoro.

Questo dà una grossa facilità di uso perché posso ampliare molto la scalabilità del mio prodotto.

Quindi posso avere quello che prima era: acquisti un server, lo configuri e lo metti nella data center; adesso è: faccio un click su una delle piattaforme cloud e aggiungo server.

Questo ha portato a team di controllo molto superiori.

Una maggiore scalabilità, una maggior rapidità ma anche una potenziale esplosione dei costi o un potenziale abbassamento delle performance perché ho un controllo meno fino in alcuni casi.

Quindi il test tipicamente nell'ambito delle performance ci sono due macro aree: una prima macro area è dire faccio sul sito o sull'applicazione le operazioni che mi aspetto e controllo che la parte back-end risponda nei tempi congrui.

Se sono nel mondo web molta attenzione viene anche posta... una volta che ho recuperato i dati dal mio server che il browser li renderizzi nel modo corretto.

Quindi me li mostri nei tempi giusti, non perda, diciamo così, non investa troppo tempo per renderizzare graficamente un contenuto, magari non aspetti di avere tutti i dati prima di mostrarmi la pagina, per cui l'header, il contenuto, la parte centrale me le mostri, poi se ci sono dati che devono essere caricati dinamicamente vengono caricati in modo progressivo.

In tutto questo scenario ci sono tanti punti di intervento, mi concentrerei più sulla prima parte di cui ho parlato che sono i test di carico più verso il lato server che sono più immediati.

Abbiamo tanti esempi nell'arco dei progetti che abbiamo fatto di potenziali casi disastrosi, uno in particolare in preparazione dell'ultimo Black Friday dove c'erano due problemi lato loro, una struttura relativamente nuova, si aspettavano un picco di clienti che poi effettivamente c'è stato e per come era impostato il database, quindi la parte software che memorizza i dati,

avevano un collo di bottiglia molto forte relativo ad alcune tipologie di ricerca.

Quindi facendo certe ricerche era molto rapido.

Su altre tipologie di ricerche, su prodotti più particolari che avevano dei dettagli in più: una dimensione di taglio, una dimensione di colore, il rallentamento era molto forte.

E questo ha fatto sì che chi gestisce il database all'interno di questa azienda abbia identificato il problema, abbia fatto piccole modifiche in realtà, ma abbia migliorato del 70% le performance di quelle chiamate, quindi una cifra molto grande.

E questa cosa è anche un problema poco visibile se non fai un test di questo tipo, perché non ho un'evidenza, ce l'ho su grandi numeri, ma non posso vedere.

Un altro caso è stato la concorrenza.

Sempre questo cliente ha identificato che il sistema resisteva bene, aveva dei tempi di risposta molto buoni anche con tanti utenti.

ma quando l'arrivo degli utenti era molto rapido, quindi tanti utenti che si connettono, controllano qualcosa e non proseguono nella journey all'interno del sito, ma è solo una verifica puntuale, il sito andava in difficoltà.

Questo era molto pericoloso perché potrei avere tanta gente che è spinta sul mio sito, magari a valle di un'operazione commerciale di promozione, una pubblicità per esempio.

Pensate a un sito che vende prodotti per la cucina e compare come pubblicità all'interno di un programma tipo Masterchef, quindi con un grosso ritorno di utenti.

In quel momento io ho un picco e quel picco di utenti potrebbe compromettermi anche l'utilizzo da parte di chi invece è un utente ricorrente, è già all'interno di una journey di acquisto molto importante, quindi anche ha meno percezione di un sito.

Quindi questi sono fattori.

Annesso a questo noi lavoriamo sempre più con applicazioni molto connesse tra di loro, per cui io ho il mio sito magari si appoggia a delle API esterne per fare servizi diversi: la verifica della carta di credito, piuttosto che magari l'identificazione geografica di dove sono, il sito che mi restituisce le mappe.

Questi servizi sono sia gratuiti che a pagamento e hanno dei vincoli d'utilizzo.

Un caso particolare ci è capitato con un cliente che gestisce un grosso salone italiano, da uno stress test è emerso che il sistema a cui si appoggiava per l'invio delle mail non era stato opportunamente dimensionato per i volumi di utenti che si aspettavano di avere.

Pensate, cambio contesto, la vendita di un biglietto di Vasco Rossi, tipicamente viene aperto, viene aperta la capienza magari di San Siro o dell'Olimpico a Roma, quindi una grande quantità di posti, in pochi minuti vengono bruciati tutti quei posti perché vengono acquistati, ma tipicamente deve esserci dietro un sistema che è in grado di mandare quel volume di

mail in un lasso di tempo congruo, perché a valle di un'operazione di questo tipo devo ricevere anche la mail.

Quindi se vogliamo, questo aspetto non è forse cruciale nel primo impatto di acquisto dell'esperienza d'uso, ma è di vitale importanza nell'utilizzo, se non mi arriva per mail il biglietto per accedere al concerto o per accedere all'evento, comunque l'esperienza d'uso è molto negativa e potenzialmente dannosissima, visti i volumi.

Sì, molto interessante. Quindi bisogna analizzare tutta la catena e potenzialmente potrebbe essere non colpa dello sviluppatore che ha sviluppato un determinato sito web, ma anche a chi...

si appoggia. Fra l'altro hai citato anche la questione dei concerti, si potrebbero definire anche i cosiddetti "click day" in cui molte persone si connettono allo stesso sito web tutte insieme, ecco, magari quando la portata al sito web giornaliero è un centesimo di quella.

E a volte magari non sono neanche persone, cioè sono bot. Hai fatto l'esempio di un concerto e come il fenomeno del "secondary ticketing" porta di fatto a dei flussi anche superiori a quelli che potenzialmente sarebbero...

Attesi, assolutamente. Sì sì, questo è un problema molto diffuso e ci sono sempre più servizi che nascono per andare a intercettare i bot e limitarne l'utilizzo dei bot.

perché potenzialmente quelli potrebbero essere infiniti quindi neanche fare un performance test... cioè non si può fare un performance test illimitato ecco bisogna calcolare quelli che sono le persone.

Sì, diciamo che uno dei punti fondamentali nel momento in cui si fa un setup di un test di carico è identificare un obiettivo chiaro.

Quindi, dato una fotografia il più possibile completa del servizio o dei servizi che concorrono a costruire il prodotto che l'utente utilizza, avere quante più informazioni possibili su quella che è la journey effettiva dell'utente, quanti utenti mi aspetto. Nel Black Friday precedente quanti sono stati gli utenti,

quante pagine hanno consultato prima di arrivare a finalizzare un acquisto, è qual è il comportamento dentro la pagina e quindi andare a simulare il comportamento quanto più vicino possibile al comportamento utente e qua la raccolta di dati è estremamente importante perché se ho uno storico o una proiezione realistica a partire da uno storico posso fare un lavoro molto più accurato.

Come dicevi giustamente tu tracciare tutta la catena di tutti quei servizi che concorrono all'esperienza d'uso e poi identificare degli obiettivi, ci sono i test di carico che sono complessivi sulla journey, e-commerce è il classico dell'acquisto o possono esserci test di carico puntuali su singoli servizi, ho il sistema di registrazione dove metto

il mio CAP e mi restituisce il numero di... la via, piuttosto che qualche altro dato relativo al mio indirizzo per facilitare la mia digitazione, vedere che quel servizio che tipicamente non è stato sviluppato con una pressione di un carico clamoroso, in quell'occasione - Black Friday piuttosto che l'acquisto di un biglietto appunto di un grande artista - sono particolarmente sotto stress.

E in tutto questo si collega anche la profilazione del tipo di traffico, come dicevi giustamente tu, ho tanti bot all'inizio che salgono improvvisamento, all'apertura, ho tanti bot che accedono al mio sito e poi vengono filtrati, vengono eliminati dai servizi che ti dicevo prima che ci sono.

Però devo controllare che finché viene identificato quel traffico il sistema stia su... che continui a rispondermi in tempo utile per cui possa attivarsi il sistema che uccide i bot.

Dall'altra parte devo verificare il comportamento discontinuo e il traffico.

Siamo sempre più orientati a delle soluzioni che hanno una struttura scalabile nel tempo.

Che è la questione cloud che facevi cioè: posso acquistare potenza di calcolo all'occorrenza.

All'occorrenza. E questo fa scattare un passo in più nei test di carico, cioè un primo impatto è voglio essere sicuro che il mio sistema garantisca le performance chi si aspetta il mio utente.

Il passo ulteriore è quello che io pago di performance e di scalabilità è coordinato al traffico che ho? Diciamo che potenza di calcolo infinite potrei mettere 3000 server che rispondono al mio sistema e mi garantisco una qualità perché c'è un utente che ha il suo server, chiaramente è sovrabbondante. Questo potrebbe avere senso magari il primo giorno di un evento,

il primo giorno di vendita, ma la settimana dopo dove questo servizio è ancora attivo è uno spreco.

Quand è che quantifico la dimensione corretta dei miei sistemi per rispondere ai diversi livelli di traffico, che è uno step ulteriore, quindi vado ad identificare quali sono le risorse che ho bisogno, a dimensionare le risorse rispetto al traffico che mi aspetto? E uno step ulteriore è andare a ragionare come faccio a vedere che il mio sistema scali

sufficientemente rapidamente, quindi aggiunga potenza di calcolo o la tolga, in maniera importante.

Questo, parliamo di alcuni clienti che abbiamo avuto che hanno portato un "saving", studiando bene questi aspetti e le politiche di "scale up" e "scale down", quindi di crescita della potenza di calcolo, scale up, e di crescita della potenza di calcolo in situazioni dove non c'è traffico o il traffico è ridotto, scale down. In questi scenari saving anche del 40-50%

rispetto a un budget annuale, quindi parliamo di cifre anche importanti, oggigiorno.

Sì anche perché senza cloud altrimenti dovevi fare un investimento iniziale incredibile che non tutti potevano permettersi di fare, quindi rende più accessibile anche a molti, a molte più persone, a molti più servizi questo tipo di...

la possibilità di fare appunto...

Esattamente, è anche un po' alla base del boom delle start-up, sentiamo di start-up che hanno cifre mila abbonanti e sono 4 o 6 persone, ma proprio perché possono vincolare il costo dell'infrastruttura alla capienza dei clienti che hanno.

Quindi se una scale-up può permettersi di dire adesso investo X milioni di euro in infrastruttura perché so che ho un traffico di un certo tipo, ho una clientela di un certo tipo, realtà più piccole hanno necessità di ancorare i loro costi alla quantità di tenti che hanno, alla quantità di clienti in questo caso che hanno.

Per quanto riguarda la valutazione che fate nel momento in cui bisogna porre in essere un performance test non c'è il rischio che e tu prima facevi l'esempio del Black Friday, non c'è il rischio che magari tenere in considerazione i dati dello scorso anno non sia sufficiente? Cioè come fate ad essere sicuri che il performance

test sia accurato, che poi possa rappresentare quella che sarà la realtà e quindi non creare problemi potenzialmente al servizio o al sito?

Ci sono diverse "proxy" che si mettono in essere.

Quello che dicevo prima, più il dato è accurato, più la proiezione che ci porta, se pensiamo all'e-commerce, più la proiezione che ci porta il sito: noi l'anno scorso abbiamo avuto 10.000 utenti, ci aspettiamo di averne un 30% di più, un 20% di più.

Per cui c'è una parte che è un dato che noi riceviamo ogni input, una parte sono dei margini di sicurezza che a livello di procedura vengono impostati.

Per cui ho X utenti, posso ragionare su un carico leggermente superiore rispetto a quello che mi aspetto, posso ragionare su dei tempi più stringenti per la dotazione del performance.

Poi la certezza proprio non ce l'hai.

E qui entra il gioco il discorso che ti facevo prima.

Più io, oltre all'analisi del singolo carico, posso avere un'analisi di quanto rapidamente scala, io posso garantire che il set minimo, sempre banalizzando ma giusto per arrivare nel concreto: due server riescono a gestire bene 200 utenti.

La politica di scale-up è sufficientemente veloce, per cui da due server a quattro server riesco a passare in un tempo congruo alle "user-journey" del mio utente.

A questo punto, se l'infrastruttura è scalabile, diventa un tema, come dicevamo prima, numero di clienti, costi.

Però in questo modo io ho la garanzia di essere sicuro, di avere un sistema che risponde correttamente.

Per cui più noi riusciamo ad andare a, lasciami dire, identificare il gradino base e l'effettiva capienza, quanti utenti riesce a soddisfare la singola infrastruttura base e quanto vantaggio ci dà il delta di un gradino di scale-up, più posso andare a studiare una risposta.

Poi questo discorso è molto vincolato al picco di traffico.

C'è anche poi una parte che è sul lungo periodo.

Se prendiamo e-commerce l'attività è puntuale.

Entro, faccio un mio acquisto, esco sostanzialmente o faccio poco altro.

Se pensate a una soluzione tipo Netflix, per esempio, una volta che sono entrato - o una piattaforma di qualunque, o video, o di conference anche - io ho un picco in ingresso, posso avere un picco in ingresso, pubblicano l'ultima serie più amata, ma poi ho anche un long running, perché poi quegli utenti permango

nell'esperienza d'uso all'interno del mio sistema.

Per cui è articolato e per quello dicevo è molto importante la journey.

Poi la certezza matematica al 100% molto spesso non si può avere, però sai avere un grado di confidenza estremamente alto.

Sì poi immagino che con il tempo potete acquisire dati di quella che è la situazione concreta e quindi diventa sempre più difficile sbagliare ecco da quel punto di vista.

Assolutamente sì. Poi ci sono anche tanti fattori ambientali che vanno analizzati.

Se pensiamo per esempio un salone, giusto perché è un caso che abbiamo analizzato recentemente, io ho una capienza massima della struttura.

Più di quei biglietti non possono essere venduti.

Posso ragionare sulla simultaneità degli utenti e tante volte poi rispetto a quella che è l'analisi del massimo possibile immaginabile, bisogna andare a ragionare sull'esperienza d'uso perché è irrealistico pensare che centomila persone entrino allo stadio nello stesso istante e nello stesso istante aprono l'applicazione.

Si rischia di fare un calcolo eccessivamente ampio.

Per cui analisi di questo tipo e una valutazione di quelli che sono gli elementi a contorno dell'utilizzo del prodotto ci consente di avere una lettura molto precisa.

Sì, per questo dicevo anche prima che potenzialmente i bot, in questo senso, possono rappresentare per voi una sfida ulteriore se non correttamente bloccati perché tutti questi ragionamenti che hai fatto non valgono perché, come dicevo appunto, non ci sarebbe nessun limite.

Per chiudere quindi ti chiedo quali sono i principali errori che vengono fatti nei performance test che avete riscontrato.

Ma probabilmente il primo principe su cui siamo trovati a lavorare a partire da performance test fatti internamente da persone che si sono appena affacciate a quel contesto o magari realtà più consolidate, è scenari non realistici. L'esempio che ti dicevo prima, posso avere uno scenario non realistico per cui: mediamente al mio

salone ci sono mille persone all'interno. Il giorno di apertura alle 10 della mattina ce ne sono dieci volte tanto, per cui scenari non realistici ci sono traffico, magari dato su una media che considera una finestra troppo lunga, non la situazione di picco ma magari il numero di utenti nei quattro giorni di

salone per complessivi è una divisione un po' un po' forte. O scenari non realistici rispetto all'user journey. Entro, acquisto un prodotto, esco. No, tipicamente entro, ne navigo due o tre, scelgo quello che mi interessa di più, provo le diverse, leggo le diverse taglie, persisto all'interno della pagina

più tempo rispetto a quello che è pensato.

L'altro caso sono ambienti non adeguati. L'infrastruttura che tipicamente le aziende hanno per fare test, per fare prove, per test che non siano di carico ma sono test d'utilizzo, quindi test o esperienziali o test puramente di flusso, in quel caso sono scalati verso il basso, per cui non è un test attendibile,

perché mi trovo su un'infrastruttura molto scalata verso il basso rispetto a quello che sarà quella effettiva.

L'altro aspetto è il focus sul singolo componente.

La mia infrastruttura l'anno scorso funzionava bene, ho aggiunto una funzionalità in più, faccio il test di carico solo su quella funzionalità in più.

Bisogna vedere come interagisce il tutto.

Esattamente.

L'altro elemento molto importante è la mancanza di monitoraggio.

Ci sono tanti aspetti che devo monitorare all'interno del mio sistema.

Per cui, prendendo il caso base, sito web con attaccato un database, che è lo scenario un po' più semplice, che possiamo andare a vedere.

Però andare a vedere, per esempio, quando io ricerco un prodotto dentro il database, qual è l'andamento, di RAM, di CPU, qual è l'indice, quanto lunghe sono le "query", quanto si allungano.

Quindi... le query sono le chiamate per ottenere il dato dal database, perché magari non fosse avvezzo al nome.

E quindi, monitorare con attenzione tutti i componenti dell'infrastruttura, potenzialmente molto complessa, è estremamente importante.

L'altro caso che è quella cosa un pochettino che si sta cercando di mettere nel test di...

nei test di performance, test di carico, è avere testi discontinui, esco quest'anno, ho fatto un test, non faccio più indagini sull'efficacia, sulle performance del mio sistema, faccio un test a fine anno in vista della nuova uscita, da un Black Friday all'altro, mentre se si riescono a mettere continuativi, automatici o continuativi nel tempo, mano a mano che

sviluppo i componenti, riesco a indagarli uno per uno e garantire delle performance per cui mi trovo in prossimità del rilascio dove non è il bollino che certifica il tuo sistema regge 100 utenti, deve essere progressivamente un'infrastruttura dove i singoli componenti sono in grado e questo è uno degli errori più comuni e probabilmente anche una delle

prospettive più importanti, una delle sfide più importanti che ci saranno nei prossimi anni, inserirli come altri test nel ciclo normale dello sviluppo, non con la frequenza magari dei test di unità, però con una frequenza consistente.

Perfetto. Sì grazie Edoardo perché ci hai fatto capire appunto qual è l'importanza dei performance test sia da un lato per evitare di creare frustrazione nell'utente che utilizza un sito web, però dall'altro da come mi è perso di capire anche per evitare un costo eccessivo per una potenza di calcolo che non serve

a niente ecco, o che copre solo un singolo picco e basta. Alla prossima.

È stato un piacere. Alla prossima.

E così si conclude questa puntata di INSiDER - Dentro la Tecnologia, io ringrazio come sempre la redazione e in special modo Matteo Gallo e Luca Martinelli che ogni sabato mattina ci permettono di pubblicare un nuovo episodio.

Per qualsiasi tipo di domanda o suggerimento scriveteci a redazione@dentrolatecnologia.it, seguiteci su Instagram a @dentrolatecnologia dove durante la settimana pubblichiamo notizie e approfondimenti.

In qualsiasi caso nella descrizione della puntata troverete tutti i nostri social.

Se trovate interessante il podcast condividetelo che per noi è un ottimo modo per crescere e non dimenticate di farci pubblicità.

Noi ci sentiamo la settimana prossima.