L’introduzione di un impianto automatizzato promette efficienza, efficacia e significativo miglioramento dei processi logistici di movimentazione, stoccaggio e distribuzione della merce.
Per garantire il successo dell’implementazione di questi impianti è essenziale:
- Analizzare con il Cliente i Processi Logistici che verranno trasformati
- Raccogliere i Requisiti Funzionali e Operativi, dichiarati e nascosti, al fine di armonizzare la soluzione automatizzata con i Processi Logistici a tendere
- Formalizzare in un documento condiviso le Specifiche Operative e Funzionali dell’impianto in coerenza coi Processi attesi
- Redigere un accurato Test Plan, e più in generale definire una Test Strategy, come strumento per l’Accettazione Finale della soluzione implementata, aderente alle esigenze e aspettative
- Prevedere formazione e training specifici (talvolta in concomitanza con l’esecuzione degli UAT) ed accompagnare il Cliente nell’avvio dell’impianto
In questo articolo focalizzeremo la nostra attenzione sul punto 4, ossia sul ruolo cruciale di una buona progettazione dei test e una loro esecuzione controllata e puntuale per la riuscita del progetto.
In questa pagina:
Definizione di una Test Strategy
Tra le responsabilità del Project Manager c’è la definizione della Test Strategy che si intende adottare per la validazione della soluzione e l’esecuzione e controllo dei test da eseguire.
Nel documento di Test Strategy sono dettagliati:
- Scopo e Obiettivo dei test (indicando tutti i Sistemi coinvolti)
- Approccio alla pianificazione ed esecuzione dei test (Test Plan con Test Case e schedulazioni, ruoli e responsabilità)
- Processo di Comunicazione e Report per il controllo dell’avanzamento test (Strumenti e tool a supporto)
- Ambienti di Test
Il documento di Test Strategy può essere più o meno dettagliato, ma gli elementi chiave dovranno essere sempre ben chiariti e condivisi, per definire linee guida precise per l’efficacia della fase di validazione, in contesti più o meno complessi per numerosità di attori, ambienti utilizzati, sistemi coinvolti e grado di integrazione tra essi.
Con particolare riferimento alla definizione dell’approccio per la gestione dei test, nel documento di Test Strategy sono definite le regole per la redazione dei Test Plan di riferimento per ogni fase di test prevista dal progetto.
Vuoi conoscere il nostro approccio e come possiamo supportarti?
Redazione del Test Plan
Il Test Plan è un documento che definisce l’ambito, l’obiettivo e le modalità di esecuzione dei test.
Al suo interno troviamo elencati, divisi per Tipologia di Test:
- Tutti i Test Case che dovranno essere eseguiti
- La modalità di esecuzione e le condizioni
- Specifici criteri di input atti a valutare il risultato atteso.
I Test Case sono quindi progettati in base ai requisiti e alle procedure operative di funzionamento dell’impianto. Definiti i cataloghi dei test da eseguire, si procede alla schedulazione dei Test Case, secondo le tempistiche di Progetto, definendo ruoli e responsabilità sull’esecuzione e sul controllo.
Hai bisogno di essere supportato nella scrittura ed esecuzione del Test Plan?
Tipologie di Test
Ogni fase di certificazione dell’impianto passa per una diversa categoria di test, di seguito riassunti.
Unit Test
Lo scopo degli Unit Test è quello di verificare la corretta funzionalità della singola unità o componente dell’impianto. Hanno la limitazione di essere eseguiti su sistemi o porzioni di impianto autonomi, tagliando le complessità che possono emergere quando le parti sono messe in comunicazione e lavorano come assieme.
Tuttavia sono essenziali per risolvere a monte eventuali bug o malfunzionamenti che potrebbero poi generare anomalie durante l’esecuzione dei test integrati, rallentandone la realizzazione e rendendo anche più complessa l’individuazione delle cause.
Il fornitore stesso è il responsabile dell’esecuzione e verifica esito degli Unit Test. Il Test Manager (se figura diversa dal Project Manager) è invece responsabile del controllo e progresso dell’esecuzione.
Interface Unit Test
Come estensione degli Unit Test, gli Interface Unit Test sono invece incentrati sul validare le interfacce di interazione tra due o più sistemi o parti dell’impianto.
Hanno come limitazione la “semplificazione” del dato testato, essendo realizzati in ambienti di test (solitamente Quality o Certificazione) incentrati a validare la bontà dello scambio informativo.
Anche in questo caso sono i fornitori coinvolti, ognuno per la propria parte, ad essere responsabili dell’esecuzione degli Interface Unit Test. Il Test Manager mantiene la responsabilità sul progresso.
Integration Test
Gli Integration Test sono test end-to-end che coinvolgono più di un sistema o parti dell’impianto per volta, richiedendo interazioni tra di essi. Lo scopo dei test è confermare che le singole parti funzionino insieme correttamente, interagendo come progettato.
Estendendo il campo di applicazione non alla singola unità ma al comportamento di più parti messe in relazione, aumenta anche la complessità nell’esecuzione e nella verifica. Anche se solitamente questi Test sono realizzati su ambienti di simulazione o di produzione parzialmente disponibili, l’obiettivo è ricreare scenari che siano quanto più vicini alle condizioni operative reali, in modo da intercettare e rimediare quanto prima a problemi che potrebbero presentarsi in fasi più avanzate. Da qui l’importanza preventiva di identificare e reperire dei set di dati utili a testare gli scenari previsti, da utilizzare come input e definire gli output previsti, includendo sia gli esiti positivi che negativi.
Il Test Manager è la persona del team di progetto responsabile del coordinamento, controllo e progresso degli Integration Test, registrandone gli esiti, mentre i vari team dei fornitori restano i responsabili dell’esecuzione e di eventuali interventi correttivi.
Communication Test
I Communication Test hanno l’obiettivo di testare l’effettiva raggiungibilità e quindi garantire il dialogo tra i diversi componenti di un sistema. Tali Test possono essere pianificati come condizione preliminare all’esecuzione dei Test di integrazione o funzionali. Se gli Integration Test ed i System Test vengono eseguiti su stessi ambienti utilizzando di fatto la stessa infrastruttura, gli stessi apparati e device, è solitamente schedulata un’unica sessione di Communication Test prima degli Integration. Se invece le condizioni operative e gli ambienti utilizzati sono diversi, viene schedulata una sessione di Communication Test per certificare ciascuna condizione operativa.
L’esecuzione dei test è a carico dei team dei fornitori coinvolti, mentre il Test Manager è responsabile della corretta esecuzione e garantisce la presa in carico delle eventuali problematiche coinvolgendo nella risoluzione i team interessati (esempio Sistemi Informativi e Infrastrutture).
System Test
I System Test sono progettati per verificare il funzionamento del sistema nel suo complesso, verificando che tutti i componenti, moduli, applicativi dell’impianto e gli interfacciamenti tra essi funzionino correttamente e coerentemente con quanto atteso e descritto negli opportuni Scenari di test, che ricoprono per intero i requisiti formalizzati nelle Specifiche Funzionali ed Operative dell’impianto.
Di fatti sono l’anticamera degli UAT con l’obiettivo di far emergere e correggere eventuali anomalie prima del coinvolgimento degli Utenti, al fine di limitarne l’impiego e rendere più efficiente l’esecuzione stessa degli UAT.
Gli ambienti in cui vengono svolti i System Test dipendono dal contesto di implementazione del nuovo impianto, sia in termini di ambito (ad esempio intervento su impianto già operativo) che di perimetro (ad esempio se l’implementazione impatta o meno le integrazioni WCS – WMS).
Alcuni esempi:
- Nel caso di un’estensione di un impianto esistente, i test sull’impianto devono essere condotti evitando interferenze con le attività quotidiane, quindi laddove possibile segregare dati e flussi informativi oppure eseguire i test fuori dagli orari lavorativi. Decade invece il rischio di interferenza dei dati nei casi di realizzazione di un impianto nuovo, che è possibile isolare da sistemi esterni.
- Nel caso di integrazioni attive con sistemi già esistenti (esempio WMS), indipendentemente dal fatto che subiscano essi stessi modifiche, la gestione diviene più complessa. In questo caso, per evitare l’invio di dati non realistici ai sistemi interfacciati è necessario prevedere che l’impianto da testare (qualsiasi sia l’ambiente operativo di partenza) dialoghi con l’ambiente di test dei sistemi interfacciati.
In queste ultime condizioni operative, tra i Test Case vengono raccolti anche una classe specifica di test denominati di non-regressione (No-Regression Test), che hanno l’obiettivo di validare e verificare che le eventuali modifiche apportate ad un sistema o ad un interfaccia tra sistemi, non comportino delle compromissioni di funzionalità pre-esistenti.
Il Test Manager è responsabile della corretta esecuzione dei test, negli ambienti stabiliti, coordinando le varie parti interessate, nonché del registro dei risultati, evidenziando e indirizzando i difetti individuati per una loro pronta risoluzione. La realizzazione dei test è a carico dei fornitori, che possono essere coadiuvati da persone rappresentanti il committente.
User Acceptance Test (UAT)
Nel caso di rilascio di Impianti Automatizzati, talvolta gli UAT sono denominati come Site Acceptance Test (SAT), essendo la componente funzionale ed operativa da testare strettamente dipendente anche dalla componente impiantistica installata (esempio hardware, device operativi, elementi elettromeccanici, etc).
Almeno per la fase di esecuzione, gli UAT in sintesi possono essere considerati una ripetizione dei System Test, con il coinvolgimento questa volta degli utenti o operatori che utilizzeranno effettivamente l’impianto.
L’obiettivo è avere una conferma formale da parte del Committente che l’installazione e configurazione dell’impianto rilasciato sia in linea con quanto concordato e quindi idoneo alla messa in produzione.
Gli utenti svolgono un ruolo attivo nell’esecuzione degli scenari di test previsti; pertanto, dovranno aver ricevuto un’adeguata formazione e devono avere chiari gli obiettivi di ogni Test Case eseguito.
Il Project Manager è responsabile del corretto ingaggio, per tempo, delle figure necessarie all’esecuzione dei test, nonché alla gestione delle issue (bug, fuori specifica, cr) emerse durante l’esecuzione degli UAT.
Il Test Manager (se diverso dal PM) è responsabile invece della corretta esecuzione dei test, coordinando le parti interessate, registrandone i risultati e evidenziando eventuali issue emerse.
GoLive e HyperCare support
La validazione dei risultati degli scenari previsti agli UAT e quindi della rispondenza della soluzione alle aspettative dichiarate nelle Specifiche Funzionali ed Operative dell’impianto è in carico esclusivamente agli utenti ed al rappresentante del Committente.
Sussistono quindi le condizioni per il GoLive (passaggio in produzione) quando tutti i Test Case previsti dagli UAT sono stati eseguiti e validati, oppure quando pur rimanendo pendenti delle issue non risolte queste sono opportunamente indirizzate e non bloccanti per il normale funzionamento dell’impianto.
Nel contesto della Test Strategy, e comunque più generalmente come elemento di Project Management, può essere previsto un Piano di Rollback, ossia una lista di azioni specifiche da eseguire nel caso in cui durante il GoLive vengano riscontrati dei problemi critici o dei malfunzionamenti che richiedono il ripristino delle condizioni di partenza. Non sempre un Piano di Rollback è attuabile, soprattutto in caso di modifiche strutturali irreversibili, che rendono il Rollback di fatto impossibile, o nel caso in cui le azioni necessarie dovessero essere complesse e non sostenibile.
Non sussiste invece l’esigenza di un Piano di Rollback in caso di nuove implementazioni o comunque sistemi isolati. La valutazione della definizione di Piano di Rollback, della fattibilità e sostenibilità, è parte integrante anche della Gestione dei Rischi di un progetto.
Al completamento del GoLive dell’impianto, è avviata la fase di Monitoraggio della Produzione ed è utile attivare un periodo di HyperCare Support (Support Post-GoLive) in cui i fornitori si impegnano a fornire un supporto continuativo agli utenti ed al Committente per identificare, analizzare e risolvere rapidamente eventuali anomalie che dovessero, naturalmente, presentarsi durante la fase iniziale di ramp up.