Differenza tra la fase di creazione delle build, test, UAT e deploy del software

Build

Nelle fase di build vengono eseguite le attività di sviluppo del codice da parte degli sviluppatori sulla base di quanto appreso all’interno delle specifiche funzionali e l’esecuzione dei system test. Dall’altro lato, Il team funzionale, in tale fase è impegnato delle attività di stesura del teskbook, infatti, per ogni requisito, vengono previsti diversi scenari di test al fine di verificarne la corretta funzionalità. Dopo avere definito tutti i possibili scenari di test, dal team funzionale viene eseguita l’attività di pianificazione dei test secondo i seguenti step: calcolo del numero di test totali, divisione del numero di test totali sulle giornate uomo disponibili per le attività, assegnazione degli scenari di test al team. Il carico di lavoro dello svolgimento dei test deve essere distribuito in modo tale da risultare maggiore all’inizio della fase di test in modo da avere la possibilità di effettuare nuovi cicli di test a causa della presenza di anomalie riscontrate durante l’esecuzione. Infine, prima dell’inizio delle attività di testing, il testbook deve essere inviato al cliente per poter essere approvato.

Test

In talefase vengono svolti gli Integration Test. L’esecuzione dei test spetta al team funzionale. Nella casistica in cui siano presenti problematiche (bug) per i requisiti, queste vengono tracciate mediante l’utilizzo di una piattaforma di Bug Tracker in modo da mantenere tracciabilità degli errori riscontrati. Inoltre, tale applicativo permette di fornire i dettagli dei bug individuati e consente agli sviluppatori di replicarli e di poterli risolvere. Solo dopo aver riverificato il corretto funzionamento del sistema, l’esito del test sarà considerato positivo.

UAT

Terminata la fase di test, l’attività successiva è quella degli UAT (User Acceptance Test), ovvero i test che vengono svolti insieme agli utenti per verificare il corretto funzionamento dei nuovi requisiti all’interno del sistema. Tale fase prevede solo un numero limitato di test, precedentemente definito. Per tale ragione è opportuno svolgere i test che mettono in evidenza le funzionalità primarie dei requisiti. È possibile che, durante lo svolgimento degli UAT, gli utenti possano richiedere una CR (change request) qualora il comportamento non sia in linea con quanto atteso. Le CR vengono valutate dagli sviluppatori solo una volta terminata l’attività di UAT. Qualora la CR fosse recepibile, verranno apportate le opportune modifiche ai sistemi coinvolti e successivamente testate per verificarne il corretto funzionamento. Qualora, invece, la CR non fosse recepibile o per motivi tecnici o a causa delle tempistiche stringenti per poter rieseguire tutte le attività, questa verrà censita all’interno di un documento per mantenerne la tracciabilità.

Deploy

Prima di procedere con le attività di deployment, è necessario che venga preparato un piano detto Piano di Rolloout che ha il compito di scandire le attività durante il rilascio. Tale piano deve essere approvato dal cliente. Ricevuta l’approvazione, viene effettuato, in ambiente di produzione, il deploy implementazioni sviluppate. L’attività, solitamente, si svolge in una finestra temporale al di fuori del normale orario lavorativo, in modo da avere il minor impatto possibile sui sistemi. Una volta effettuato il deploy, un membro del team funzionale esegue i sanitycheck, ovvero dei test volti a verificare che le funzionalità principali dei requisiti in ambiente di produzione siano state correttamente implementate. Qualora i sanitycheck avessero esito negativo, allora si dovrà procedere con il rollback, gli sviluppatori dovranno ripristinare in ambiente di produzione lo stato precedente e dovrà essere riprogrammata una nuova data di rilascio. Ciò comporterà, una volta individuato e risolto il problema, una nuova sessione di test al fine di verificare la corretta esecuzione delle operazioni e la pianificazione di una nuova data per poter effettuare le implementazioni richieste. Indipendente dall’esito, tutte le parti interessate dovranno essere tempestivamente informate sull’esito della fase.

Infine, terminate le attività di deploy, le successive attività di manutenzione vengono assegnate al team di application maintenace.