Cos'è il test di sistema?

Immagina di vedere un sistema software al microscopio, partendo dal livello più estremo di ingrandimento con l'unità. Questo è l'elemento costitutivo di base del sistema software. Poi la visuale si espande verso l'esterno per includere il livello successivo di ingrandimento, i moduli creati da quelle singole unità. Infine, allontanandosi completamente, si arriva al livello del sistema. A questo livello di ingrandimento è possibile vedere tutto ciò che è presente nel sistema e come tutti i componenti creati da quei moduli funzionano insieme.

In un certo senso, il test di sistema è un po' come quella visione microscopica, ma con una differenza fondamentale. Il test di sistema è una forma di test black box, il che significa che i tester sono meno interessati alla visualizzazione dei componenti coinvolti nel suo assemblaggio che alla funzionalità complessiva del sistema. Da questo tipo di prospettiva "superato/fallito", il comportamento del sistema è degno di nota in questo contesto solo per quanto riguarda le prestazioni del sistema. (Il test white box consente una maggiore visibilità sulla natura dei componenti all'interno di un sistema.)

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.

Consideriamo il conto alla rovescia che precede i lanci spaziali. Mentre tutti ricordano il drammatico conto alla rovescia in 10 fasi prima dell'accensione e del decollo, pochi ricordano i numerosi controlli di reparto che vengono richiesti dal capo volo e a cui si risponde affermativamente con un "via". In un tipico lancio spaziale, i capi dipartimento vengono consultati sulle operazioni pianificate, sulla sicurezza della missione, sui sistemi del veicolo e sulle condizioni meteorologiche previste, tra molte altre questioni. Ogni reparto viene interrogato e ogni capo reparto risponde a turno.

Allo stesso modo, il test di sistema può essere considerato la checklist finale che precede il lancio di un nuovo sistema software. L'ultimo turno di pulizia di eventuali bug software noti è stato completato. E proprio come nelle storiche liste di controllo ideate dai primi pionieri dello spazio, tutto si riduce a un ultimo tentativo da parte di ogni "dipartimento" incluso nei test del sistema.

Ogni query è colorata in base alla funzionalità del sistema:

• Ogni componente funziona come previsto?

• I componenti funzionano in modo coordinato tra loro?

• Il software è pronto a supportare un'interfaccia utente fluida e a fornire l'esperienza utente (UX) desiderata?

Quando si parla di test di sistema, incontreremo naturalmente l'argomento delle dipendenze, che sono relazioni che esistono all'interno dei casi di test. In tali situazioni, l'esito di un caso di prova può dipendere parzialmente o totalmente dai risultati di altri casi di test. Le dipendenze possono anche coinvolgere funzionalità, ambienti di testing o politiche di sicurezza e possono persino influenzare l'intero processo di testing che un'organizzazione mantiene in mente.

Le metodologie di test di sistema non offrono uno sguardo approfondito sul loro funzionamento interno (ricorda, si tratta di una forma di black box testing), ma ti permettono invece di capire se una determinata applicazione funziona. L'idea è che i test di sistema aiutino a individuare lacune, errori o requisiti mancanti in quanto determinano la funzionalità complessiva dell'applicazione software.

I test di sistema vengono solitamente eseguiti dopo integration testing ma prima dei test di accettazione, assicurando così che tutti i componenti funzionino correttamente insieme. Come vedremo, spesso comprende sia gli aspetti funzionali che quelli non funzionali del sistema. Poiché si basa sia sull'area strettamente funzionale che su quella ampiamente non funzionale, affronta aspetti molto diversi come usabilità, sicurezza e prestazioni.

Uno degli scopi principali del test di sistema è che consente di Verify che il linguaggio di codifica di un software possa essere tradotto in un programma utilizzabile. Tuttavia, l'obiettivo principale dei test di sistema è assicurarsi che il software oggetto di valutazione supporti in modo efficace i requisiti aziendali degli utenti che vi faranno affidamento.

Il processo di test deve rispecchiare lo stesso ambiente di produzione che verrà utilizzato, per garantire che il software funzioni come richiesto nonostante le condizioni mutevoli del mondo reale. Allo stesso modo, i dati di test vengono creati per imitare dati e situazioni reali. Una volta condotti i casi di test, i difetti nel software possono essere individuati e riparati.

I test di sistema possono essere classificati secondo uno dei tre principali gruppi. Il primo, il functional testing, riguarda le prestazioni del sistema, ma non cerca risposte più approfondite se non quella di verificare se il software funziona come promesso. Ecco alcuni dei principali tipi di functional testing:

• Test di accettazione: i test di accettazione da parte degli utenti mirano a incorporare i test di prestazioni condotti dalle persone che rappresentano il target demografico del software prodotto. Questi utenti aggiungono realismo al processo di test testando il software in condizioni reali.

• Test di integrazione: un'area di fondamentale importanza dei functional testing studia il modo in cui diversi moduli o componenti si "adattano" tra loro quando sono costretti a lavorare in stretta collaborazione. Questo è il test di integrazione di sistema. Un sistema completamente integrato offre ai tester la funzionalità di valutare le interazioni chiave.

• Smoke testing: lo smoke testing fornisce un mezzo per verificare se la funzionalità complessiva è stata mantenuta anche dopo che uno sviluppatore ha apportato una modifica al codice. La modifica è stata apportata e i test di fumo consentono di verificare rapidamente se la modifica al codice ha prodotto effetti negativi.

• Test unitari: nei test unitari, una sezione limitata di codice viene controllata in un ambiente di test isolato. Se l'unità in questione non supera il test (come si evince dal confronto tra i dati del test e gli obiettivi di funzionalità), di solito sono necessari ulteriori test dei singoli componenti o moduli a livello di sistema.

Sebbene il functional testing fornisca informazioni estremamente importanti, questi dati si limitano fondamentalmente a un voto positivo o negativo, basato esclusivamente sul fatto che il sistema funzioni come dovrebbe. Ciò omette un numero enorme di variabili pertinenti, come la sicurezza del sistema, la UX e le prestazioni.

I test di sistema non funzionali forniscono un mezzo per valutare il funzionamento del sistema. La differenza essenziale tra test funzionali e test non funzionali può essere ridotta al seguente semplice confronto:

• Functional testing: il sistema funziona?

• Test non funzionali: il sistema funziona bene?

Tenendo questo in mente, ecco alcune delle principali forme di test di sistema non funzionali:

• Test di accessibilità: il contenuto digitale presentato è accessibile a tutti, comprese le persone con diverse disabilità? I test di accessibilità indagano su questa questione e lavorano per garantire che i contenuti vengano comunicati a tutti i possibili utenti, in modi che superino le difficoltà fisiche e mentali e garantiscano la coerenza con gli standard di inclusione stabiliti dall'Americans with Disabilities Act (ADA).

• Test di compatibilità: quando si considera quanto ampiamente le applicazioni siano distribuite e quanti viaggi cross-platform le app devono compiere, diventa facile capire la necessità di test di compatibilità, che valutano quanto bene queste app funzionino, indipendentemente da quante reti, browser, sistemi operativi e configurazioni hardware devono attraversare.

• Test di carico: in una disciplina secondaria che affronta la fisica unica presentata dalla nozione di carico e come essa influenzi la capacità di un sistema di elaborare richieste di sistema, il test di carico si concentra su cosa accade quando la scalabilità avviene su larga scala. Supponiamo che il sistema non avrà problemi a elaborare una singola richiesta di sistema, ma cosa succede quando tale carico viene moltiplicato per migliaia di richieste, o anche di più?

• Test di localizzazione: si tratta di un'economia globale alla quale partecipano più Paesi e culture che mai. Il test di localizzazione riguarda l'assicurarsi che i contenuti software esportati in varie località nel mondo siano appropriati per quell'area specifica, secondo le regole generali riguardanti l'UX.

• Test delle prestazioni: questo tipo di non-functional testing presta particolare attenzione ai problemi di prestazioni. Ad esempio, è essenziale per buone prestazioni che un sistema risponda alle richieste in modo rapido e fluido. Il piano di test nei test delle prestazioni valuta il tempo che gli utenti devono attendere per l'elaborazione delle richieste.

• Test di sicurezza: non è un segreto che oggigiorno la sicurezza dei dati sia di primaria importanza. Quindi, ha senso che una forma di test sia specificamente orientata alla sicurezza. I metodi di test di sicurezza vengono selezionati in base al tipo di minacce potenziali ricevute dall'azienda.

• Test di stress: così come un test di stress medico cerca di capire quanto bene funzioni il cuore di una persona sotto pressione di attività, il test di stress del software verifica quanto bene un sistema possa rimanere operativamente resiliente quando supera la sua normale capacità di rilevare i colli di bottiglia e vulnerabilità.

• Test di usabilità: questo tipo di non-functional testing riguarda interamente la qualità dell'esperienza utente (UX). Il test di usabilità è un processo di test manuale, utilizzato soprattutto su piccola scala. Ciononostante, probabilmente dovrebbe essere applicato spesso, soprattutto quando si eseguono spostamenti complicati come la localizzazione di applicazioni.

Altri tipi di test di sistema sono utili anche se non rientrano nelle categories di test funzionanti o non funzionanti. Ecco alcune delle metodologie più degne di nota:

• Test API: application programming interfaces (API) sono estremamente importanti, poiché consentono lo sviluppo software aiutando diverse app o sistemi a connettersi. Il testing API garantisce che i punti di connessione API funzionino come previsto. Fornisce inoltre una supervisione sui permessi degli utenti e sul modo in cui i dati vengono gestiti tramite API.

• Test automatizzati: come suggerisce il nome, il test automatizzato (chiamato anche automazione dei test) mette la potenza dell'automazione al lavoro per testare le applicazioni software. Lo fa creando e utilizzando script di test progettati per eseguire casi di test su app software, cosa che fa su larga scala, senza intervento umano. Gli insiemi strutturati di linee guida, strumenti e pratiche che aiutano ad automatizzare il processo di test sono chiamati framework.

• Test manuale: in diretta opposizione ai test automatizzati, il testing manuale si basa su test umani per sperimentare con il software valutato, guidati da vari scenari di test e script di test. I tester sono incoraggiati a mettere davvero il software alla prova per individuare i problemi che necessitano di correzione.

• Test di migrazione: i test di migrazione sono necessari alle organizzazioni impegnate nell'aggiornamento o nella trasformazione della cultura digitale aziendale. Quando le aziende sono impegnate in tali sforzi di trasformazione, hanno bisogno di convalidare che i dati e il software chiave vengano trasferiti correttamente da un sistema in uscita a un sistema in entrata.

• Test di regressione: mentre le modifiche al codice sono pensate per migliorare il software o aumentare le sue funzionalità, possono involontariamente introdurre difficoltà se in qualche modo si aggiunge un errore umano. I test di regressione permettono ai tester di confermare il funzionamento stabile e corretto eseguendo nuovamente i test secondo necessità.

Sebbene il processo di test del sistema fornisca il test delle prestazioni black-box più completo che esista, l'esecuzione del test del sistema non è priva di potenziali problemi: