Test: probabilmente la parte più sottovalutata dello sviluppo di applicazioni

Perché dovrei pagarti per testare il tuo lavoro?

Questa è una domanda che ho sentito molto nel corso degli anni quando ho discusso dei budget di test con i clienti. Per chi non lo sapesse, suona come una domanda giusta. Tuttavia, chiunque sia coinvolto nello sviluppo del software sa quanto i test possano essere complessi e dispendiosi in termini di tempo. Il test è, infatti, una delle parti più importanti di qualsiasi progetto di sviluppo software.

Una grande piattaforma di e-commerce è una cosa incredibilmente complessa con milioni di righe di codice, gigabyte di dati e molti punti di integrazione. Ci sono così tante parti mobili interconnesse; così tanti anelli della catena che è molto facile che qualcosa vada storto. L'applicazione verrà utilizzata in milioni di modi diversi attraverso una moltitudine di browser su numerosi dispositivi desktop e mobili. Il progetto di sviluppo sarà durato almeno 6 mesi con molte persone diverse che ci lavorano. Il numero di aree e scenari che potrebbero essere testati è quasi illimitato. È una meraviglia che qualcosa funzioni!

I test possono essere suddivisi in diverse aree, ma ciascuna area di test è importante da considerare. Ogni progetto è un po' diverso; ad alcuni clienti piace affrontare da soli gran parte del test, ad altri piace esternalizzarlo mentre altri si aspettano che il loro sviluppatore faccia tutto. Anche il test non è un'entità fissa; puoi fare molti test e puoi fare un po'. Più testerai, più ridurrai il rischio del progetto, ma più tempo ci vorrà e più costerà.

Test unitario

Uno unit test è uno che verifica piccole "unità" di codice per assicurarsi che funzionino come previsto. Ad esempio, quando un modulo viene inviato, dovrebbe salvare i dettagli immessi in una tabella del database. Si tratta di un test autonomo che garantisce in modo specifico e solo che l'unità funzioni come previsto. Utilizzando una vera metodologia di sviluppo basata su test, uno sviluppatore scriverà prima un test prima di creare effettivamente qualsiasi codice in modo che il codice possa essere considerato completato solo quando il test ha superato. In pratica, lo unit test viene utilizzato solo in alcune aree chiave dell'applicazione per garantire che le funzioni principali funzionino come previsto. Sebbene gli unit test possano ridurre la probabilità che si verifichino problemi funzionali, possono anche aumentare i tempi di sviluppo.

Prova del fumo

Probabilmente sentirai la tua agenzia di sviluppo parlare molto di test del fumo. Un test del fumo è un sottoinsieme pragmatico di casi di test che coprono i percorsi e le funzioni chiave dell'utente in tutta l'applicazione. Per lo meno, il tuo sviluppatore dovrebbe eseguire test di fumo prima di consegnarti qualcosa per UAT.

Test dell'interfaccia utente

Il test dell'interfaccia utente (UI) può essere una cosa molto complessa e dispendiosa in termini di tempo. La vasta gamma di dispositivi mobili, tablet e desktop, sistemi operativi e browser che verranno utilizzati per accedere a un sito Web significa che è quasi impossibile testare manualmente ogni combinazione in modo completo. A causa del vasto numero di diverse varianti che devono essere trattate, i test dell'interfaccia utente sono un candidato perfetto per i test automatizzati. Gli strumenti di test automatizzati sono in grado di seguire un percorso pianificato attraverso il tuo sito Web e verificare se i risultati attesi vengono raggiunti. Possono anche registrare ogni viaggio in modo che ognuno possa essere riprodotto. Sebbene questo metodo non sia perfetto, può ridurre significativamente il numero dei principali problemi dell'interfaccia utente che un sito Web potrebbe dover affrontare.

Alcuni servizi di test di terze parti come Bug Finders offrono un servizio crowdsourcing in cui centinaia di tester umani freelance di tutto il mondo vengono utilizzati per testare un sito Web e vengono pagati quando trovano un problema. Questo approccio può essere un modo relativamente conveniente per testare la tua applicazione su centinaia di combinazioni dispositivo/piattaforma/browser. È normale che un ciclo di test porti a circa 200 problemi sollevati. La sfida consiste spesso nel classificare e dare priorità ai problemi in modo da concentrare le tue risorse sulla gestione di quelli più importanti. Ogni sito Web avrà un arretrato costante di problemi di basso livello che è improbabile che vengano mai risolti.

Test di regressione

Il test di regressione è una parte estremamente importante dello sviluppo in corso. È progettato per verificare se eventuali modifiche a una parte dell'applicazione hanno causato un problema a un'altra parte. Ad esempio, una modifica a una funzione JavaScript utilizzata per convalidare il modulo di contatto potrebbe potenzialmente influire sui moduli utilizzati all'interno del checkout. A causa della natura complessa di qualsiasi piattaforma di e-commerce, i problemi di regressione non sono rari, quindi l'ideazione di un solido piano di test di regressione è fondamentale per garantire che l'esperienza degli utenti non sia influenzata negativamente da questi problemi.

UAT

Il test di accettazione dell'utente (UAT) è una parte fondamentale di qualsiasi progetto di sviluppo e prevede che il cliente esegua un test completo end-to-end della piattaforma prima del lancio. UAT è il processo che vedo sottovalutato più spesso. È anche la parte di un progetto che è la prima a soffrire quando i tempi sono stretti. Tuttavia, è probabile che ciò porti a un tasso di fallimento più elevato. Per qualsiasi nuova creazione di siti Web, consigliamo di pianificare almeno 2 mesi di UAT. Il tuo sito Web di e-commerce è solo una parte di qualsiasi attività commerciale e il processo end-to-end che comprende ricerca, checkout, gestione degli ordini, pagamento, spedizione, servizio clienti, finanza e tutte le altre parti della catena deve essere testato.

UAT è spesso confuso o unito a SIT (System Integration Testing) dove testerai specificamente l'integrazione tra più sistemi. SIT fa parte del test end-to-end che garantisce che tutte le parti della catena funzionino correttamente insieme.

Un buon UAT prevede la creazione di casi di test e piani di test. Questi generalmente prendono la forma di un insieme di script (uno script è un insieme di attività da eseguire) che un tester manuale eseguirà e che supererà o fallirà il test in base al risultato. Non è insolito che un piano di test UAT end-to-end includa oltre 500 casi di test.

La A in UAT è uno dei motivi per cui è così importante. Alla fine del processo UAT, generalmente si riterrà che tu abbia accettato la domanda, quindi è importante che tu l'abbia testata a fondo per assicurarti che funzioni esattamente nel modo in cui ti aspettavi. Questo non significa che i bug non scoperti non saranno coperti da garanzia, ma se c'è una funzionalità che non funziona nel modo previsto, questo deve essere raccolto in UAT. L'altro motivo per cui è così importante è che è l'ultima possibilità di raccogliere i problemi prima che vengano pubblicati. È probabile che eventuali bug e problemi influiscano negativamente sull'esperienza dell'utente.

UAT richiede molto impegno da parte del cliente, cosa che spesso viene sottovalutata. Alcuni clienti utilizzano agenzie di test esterne per supportarli durante l'UAT, il che può ridurre significativamente il rischio di un progetto in cui il cliente non ha la forza lavoro per svolgere efficacemente l'UAT.

Test di sicurezza

A volte sono molto sorpreso di come alcuni rivenditori non prendano abbastanza sul serio i test di sicurezza. Non è raro scoprire che il rivenditore non sa quando ha eseguito l'ultima volta un test di penetrazione sulla propria piattaforma web. Questi sono generalmente quelli che non sono stati ancora colpiti da un attacco informatico (o non sanno ancora di essere stati colpiti). Nell'attuale clima in cui la criminalità informatica continua a crescere in frequenza e sofisticazione, e soprattutto con il GDPR all'orizzonte in Europa, i test di sicurezza sono sempre più importanti. Tutte le piattaforme web di e-commerce dovrebbero essere testate da una terza parte specializzata almeno una volta all'anno, ma idealmente due volte l'anno. È inoltre consigliabile eseguire regolarmente la scansione delle vulnerabilità dell'applicazione utilizzando software specializzati come Nessus. In Envoy tendiamo a scansionare le piattaforme Web dei nostri clienti su base settimanale per garantire che le vulnerabilità delle applicazioni vengano rilevate molto rapidamente. Per lo meno è necessario eseguire scansioni di sicurezza dell'applicazione prima di ogni rilascio in produzione. Non va bene aspettare 6 mesi fino al prossimo test di penetrazione quando hai introdotto una nuova vulnerabilità dell'applicazione.

Test delle prestazioni

Il test delle prestazioni viene generalmente utilizzato per determinare quanto traffico, richieste di pagine, utenti simultanei e volume degli ordini può gestire il tuo sito web. È un processo più difficile di quanto tu possa immaginare poiché, per testare accuratamente, devi imitare il comportamento dell'utente reale e, come saprai, gli utenti reali fanno molte cose diverse. Il meglio che puoi fare è imitare i tuoi percorsi utente chiave come la ricerca, l'aggiunta al carrello e il checkout. Idealmente, desideri eseguire test di carico sul tuo ambiente di produzione piuttosto che su un ambiente di staging in quanto ti darà un'immagine molto più realistica, ma è probabile che questo porti offline anche la tua piattaforma a un certo punto durante il test.

La maggior parte dei rivenditori tende a eseguire test di carico una volta all'anno, normalmente prima dei periodi di picco degli scambi come il Black Friday o il Natale. Il problema che ciò può causare è che, dall'ultimo test annuale, è possibile che siano state apportate numerose modifiche all'applicazione, alcune delle quali potrebbero aver avuto un impatto incrementale sulle prestazioni. Se un test di carico annuale mostra un calo delle prestazioni rispetto all'anno precedente, è molto difficile determinare quale cambiamento o cambiamenti nell'ultimo anno abbiano contribuito a tale calo delle prestazioni. Anche questo potrebbe non darti abbastanza tempo per risolvere i problemi di performance prima dell'inizio del picco di trading.

Per contrastare ciò, è consigliabile eseguire benchmark delle prestazioni prima di ogni nuova versione del codice. Questi non devono essere eseguiti in un ambiente di produzione purché ogni test venga eseguito nello stesso ambiente poiché l'obiettivo è determinare se le prestazioni sono aumentate o diminuite rispetto all'ultima versione. Questo approccio consente ai team di sviluppo di capire da dove provengono eventuali aumenti o diminuzioni delle prestazioni. Questo, ovviamente, richiede tempo e quindi aumenterà i tempi e i costi di sviluppo

Sebbene l'elenco sopra non sia esaustivo, puoi vedere che l'ambito dei test all'interno dello sviluppo del software può essere molto ampio e complesso. Ogni tipo di test richiede tempo e fatica e non dovresti semplicemente presumere che venga eseguito tutto come standard senza costi aggiuntivi. Le aziende con una forte attenzione ai test destineranno fino al 40% del tempo di qualsiasi progetto ai test, il che può essere una quantità davvero sorprendente. Un buon test può ridurre il rischio di un progetto e può ripagarsi da solo a lungo termine in quanto si tradurrà in meno bug, prestazioni migliori e una migliore esperienza complessiva per i tuoi clienti.