Che cosa è il functional testing?

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.

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:

1. Identificare le varie funzioni che il software deve eseguire.
2. Creare dati di input in base ai requisiti funzionali.
3. Stabilire gli output previsti in base alle specifiche funzionali.
4. Condurre casi di test.
5. Valutare il confronto tra gli output effettivi e output attesi.
6. Determinare se l'applicazione software funziona soddisfacentemente secondo le aspettative.

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à.

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.

• Appium: Il mercato dei functional test vanta molti strumenti open source, e Appium è in cima alla lista. Appium fornisce supporto per più linguaggi di programmazione. Inoltre, consente di automatizzare applicazioni native, mobile e web per le piattaforme iOS e Android.

• Katalon Studio: la piattaforma di automazione dei test Katalon Studio offre un mezzo per stabilire e valutare i risultati generati tramite test di regressione e test end-to-end. Presenta una caratteristica di registrazione e riproduzione e coordinamento multipiattaforma.

• Micro Focus Unified Functional Testing (UFT): UFT di Micro Focus è un altro strumento commerciale di testing, che offre ai tester una finestra chiara e multipiattaforma sull'uso di servizi web, application programming interface (API) e Interfacce Grafiche (GUI).

• Playwright: Microsoft ha sviluppato questo framework commerciale per l'automazione dei browser web. È noto per rinforzare l'affidabilità. E sebbene Playwright supporti caratteristiche web contemporanee, offre meno opzioni per gestire i linguaggi di programmazione.

• Selenium: uno degli strumenti di automazione dei test più diffusi è Selenium, un framework open source. ^{Questo strumento basato su browser consente ai tester di scrivere e valutare script di test in una varietà di linguaggi di programmazione popolari, tra cui JavaScript TM, NodeJS e Python.}