Il functional testing è un approccio di test di software che verifica se le caratteristiche di un'applicazione funzionano come previsto in base ai requisiti specificati.
Nello sviluppo del software esistono numerosi tipi di test del software. Ognuno affronta il compito con un approccio leggermente diverso. Il functional testing si allinea più strettamente con il concetto di esperienza utente e si concentra su una domanda critica: le caratteristiche software funzionano come previsto e in conformità con i requisiti specificati?
La qualità del software viene spesso valutata da diversi punti di vista nell'ambito del ciclo di vita dello sviluppo del software. Per quanto riguarda i functional testing, i tester devono convalidare le funzionalità di base e confermare che le funzioni software supportino in modo competente i requisiti aziendali. L'esecuzione dei test consente ai team DevOps di confrontare i risultati dei test con quelli attesi.
Il testing è una parte essenziale del processo di sviluppo, e il functional testing permette ai team di QA di svolgere una sorta di assicurazione qualità prima del fatto, offrendo loro una finestra chiara su come probabilmente workflow funzioneranno quando sarà il momento di lanciarli davvero.
Resta al passo con le tendenze più importanti e interessanti del settore relative ad AI, automazione, dati e oltre con la newsletter Think. Leggi l' Informativa sulla privacy IBM.
Vengono messi in evidenza diversi elementi operativi, a seconda del tipo di test software utilizzato come parte della strategia complessiva di testing. Il functional testing valuta la compatibilità complessiva tra diversi moduli software, il che ha un impatto diretto su altri aspetti correlati, come le interazioni utente attese e la fattibilità dell'interfaccia utente.
L'ambiente di test fornito dai functional testing è considerato un esempio di black box, in cui i tester non ottengono insight sui meccanismi interni del sistema (come avviene nei test white-box) e ricevono invece un report "Pass/Fail" che indica se il sistema e le sue pipeline funzionano come desiderato.
Il functional testing segue solitamente un processo di test che richiede sei fasi:
Così come esistono varie forme di modelli di testing software, esistono diversi tipi di functional testing. Sono numerosi e questo è solo un elenco parziale. I tipi di functional testing comprendono un'ampia gamma di sfumature e sono elencati qui in ordine alfabetico.
Nel testing software, i tester spesso seguono il processo formale di testing con test ad hoc. Questa forma informale di test esplorativo è guidata interamente dalle abilità e dall'intuizione dei testatori. Non esiste una struttura definita. Invece, sono gli istinti dei tester a guidare le tecniche di test utilizzate.
Esempio: "buddy testing", in cui uno sviluppatore e un tester uniscono le forze e lavorano insieme per migliorare un modulo o un'app. In questa forma di test ad hoc, il tester di solito trova eventuali bug o altri aspetti da correggere, mentre lo sviluppatore si concentra sulla realizzazione di queste correzioni.
Le application programming interface (API) consentono lo sviluppo software e consentono la connessione di diverse app o sistemi. Il testing API garantisce che i punti di connessione API funzionino secondo necessità. Fornisce inoltre supervisione sui permessi degli utenti e sul modo in cui i dati vengono gestiti tramite API.
Esempio: l'"headless testing" avviene quando manca un'interfaccia utente o un campo di input dati per l'interfaccia utente. In tali situazioni, i dati di input condivisi con un servizio o un'app di interfaccia possono spesso essere testati al meglio tramite test API.
Molte organizzazioni vogliono che il loro processo di test rifletta davvero l'esperienza reale degli utenti reali. Per tali aziende, scenari di test complessi garantiscono il livello di accuratezza desiderato, anche se è opportuno sottolineare che una maggiore complessità richiede più lavoro iniziale per essere eseguita.
Esempio: l'elaborazione degli ordini online sembra solo un'operazione fluida. Dietro le quinte, ci sono molti processi da testare, come la facilità con cui gli articoli possono essere aggiunti al carrello online di un acquirente, la rapidità con cui funzioni come l'applicazione degli sconti vengono integrate e la facilità con cui tali acquisti possono essere effettuati.
Integration testing viene spesso eseguito contemporaneamente ai test unitari, grazie a benefici come il rilevamento precoce dei problemi e una gamma più ampia di copertura dei test. Oltre ad aiutare a far corrispondere i formati dei dati, i test di integrazione forniscono insight sul funzionamento e sulle prestazioni dei microservizi.
Esempio: supponiamo che un order management sia integrato con un tipo di modulo che governa l'elaborazione dei pagamenti. L'integration testing mostra dove potrebbero verificarsi problemi futuri tra le due entità e fornisce agli sviluppatori un blueprint per risolvere i problemi di Integrazione prima e in modo meno costoso.
In un mondo perfetto, una volta superato un test funzionale, verrebbe sempre superato. Ma questo non corrisponde alla realtà, dove il software è spesso influenzato da sviluppatori che potrebbero inconsapevolmente indurre errori con nuove modifiche al codice. I test di regressione assicurano il mantenimento di una linea di base costante.
Esempio: ogni volta che vengono apportate modifiche al codice, viene utilizzata una forma o un'altra di test di regressione. Questo include eventuali aggiornamenti correlati, come quelli effettuati dopo una correzione di bug, l'introduzione di nuove funzionalità o dopo un aggiornamento software.
Il sanity testing è un modo rapido e agile per verificare che le funzionalità esistenti non siano state compromesse dall'aggiunta di cambiamenti relativamente minori o correzioni di bug. I test di integrità tendono a essere utilizzati come un modo rapido per confermare che una nuova funzionalità non comprometta le altre funzionalità del sistema.
Esempio: come per i test di regressione, il sanity testing permette di "riavvolgere" il sistema fino a funzionalità precedenti per verificare i miglioramenti delle prestazioni, confermare il funzionamento di base e assicurarsi che il sistema funzioni come previsto. Ogni volta che vengono apportate modifiche al codice, viene utilizzata una forma o un'altra di test di regressione. Questo include eventuali aggiornamenti correlati, come quelli effettuati dopo una correzione di bug, l'introduzione di nuove funzionalità o dopo un aggiornamento software.
Come si dice, "dove c'è fumo, c'è fuoco". Sembra che questo adagio abbia ispirato il nome "smoke testing". Lo smoke test viene condotto nelle prime fasi del processo di sviluppo e, una volta eseguito, valuta la funzionalità end-to-end. Se la funzionalità fallisce, i team QA apportano le correzioni necessarie.
Esempio: gli smoke test possono essere utilizzati per verificare l'integrazione continua e le pipeline continue come controllo finale prima di poter implementare nuove build di software (o modifiche importanti al codice).
Talvolta chiamati test end-to-end, i test di sistema servono a valutare il funzionamento congiunto del software di un intero sistema software. Il test di sistema spesso comporta l'analisi di più sistemi software separati che possono o meno funzionare in sinergia all'interno di un determinato sistema software.
Esempio: gli scenari end-to-end permettono ai tester di valutare workflow completi. Per le operazioni di retail online, questo può significare l'intera esperienza retail che il consumatore vive, dall'ordine d'acquisto originale fino all'intero processo di evasione.
Il test unitario è una forma di test in un microcosmo. Qui non stiamo testando un intero sistema, solo un pezzo limitato di codice. Una sezione di codice viene valutata in un ambiente di test isolato e, se il test unitario fallisce (basandosi su un confronto tra dati di test e obiettivi di funzionalità), ulteriori test possono essere effettuati a livello di sistema.
Esempio: gli elementi computazionali piuttosto basilari vengono testati bene tramite test unitari. Consideriamo una funzione semplice che converte le temperature Celsius alle loro controparti Fahrenheit. L'ambiente di test contiene il codice in questione e i casi di test coinvolti.
Come fase avanzata dei test software, il test di accettazione degli utenti mira a incorporare e imparare dai test di prestazioni condotti dalle persone che rappresentano il target demografico del software prodotto. Questi utenti finali conferiscono maggiore realismo al processo di test.
Esempio: un utente di un piano software passa al livello di servizio successivo, ottenendo così il diritto di sbloccare funzionalità completamente nuove. I test di accettazione da parte dell'utente verificano che l'utente potrà vedere aumentare l'accesso alle caratteristiche come previsto.
Come suggerisce il nome, il non-functional testing valuta comportamenti dell'applicazione che di solito non sono considerati vitali per garantire la funzionalità. Tuttavia, offrire un'esperienza utente ben organizzata e piacevole è ora considerato una parte essenziale dello sviluppo software. I non-functional testing i possono rivelare potenziali problemi di sistema, specialmente quando il software viene massimizzato per dimostrare una maggiore scalabilità.
Il test di carico è una forma fondamentale di non-functional testing. In teoria, un sistema dovrebbe essere in grado di elaborare migliaia di richieste di sistema con lo stesso senso di urgenza con cui invia una singola richiesta di sistema. Tuttavia, questa logica non è supportata da un'esperienza realistica. I test di carico servono a verificare se i sistemi riescono a gestire picchi di carico e persino picchi di workload estremi.
Un'altra forma di non-functional testing presta particolare attenzione alle prestazioni. È fondamentale per le buone prestazioni che un sistema risponda alle richieste in modo fluido e rapido. Il piano di test nei test delle prestazioni valuta per quanto tempo gli utenti devono attendere affinché le loro richieste vengano elaborate. Se creati con attenzione, i test delle prestazioni possono aiutare a ridurre al minimo la latenza fin dalle prime fasi.
Data l'importanza della sicurezza dei dati, non sorprende che una forma di test si rivolga specificamente a questa causa più moderna. Le metodologie di test di sicurezza come Dynamic applicazione Security Testing (DAST) e Static applicazione Security Testing (SAST) aiutano i tester a verificare le vulnerabilità di sicurezza. I metodi di test di sicurezza aziendali vengono selezionati in base alle potenziali minacce.
Un tipo di non-functional testing riguarda esclusivamente la qualità dell'esperienza utente (UX). Il test di usabilità è un processo di verifica manuale che è meglio utilizzare su piccola scala. Ciononostante, dovrebbe essere applicato ogniqualvolta possibile, soprattutto quando si eseguono spostamenti come la localizzazione di applicazioni, che possono essere pericolose quando si introducono complessità che possono innescare errori umani.
Mantenere una traccia accurata di tutti gli strumenti di functional testing può richiedere molto lavoro, poiché la maggior parte di essi supporta diverse piattaforme e tipi di applicazioni. Anche se non c'è modo di tenere il passo con questo fiorente marketplace - le stime si aggirano facilmente sulle centinaia e forse anche migliaia di functional testing prodotti - eccone alcuni che si distinguono per la loro comprovata popolarità e riconosciuta Utility.
Sfrutta la potenza dell'AI e dell'automazione per risolvere in modo proattivo i problemi in tutto lo stack di applicazioni.
Utilizza il software e gli strumenti DevOps per creare, implementare e gestire app cloud-native su più dispositivi e ambienti.
Accelera l'agilità e la crescita della tua azienda. Modernizza costantemente le applicazioni su tutte le tue piattaforme usufruendo dei nostri servizi di consulenza per il cloud.