Approfondire il test shift-left
Il test nella gestione del ciclo di vita delle applicazioni è essenziale per ottimizzare la qualità del codice e ridurre al minimo il rischio operativo associato alla distribuzione e all'aggiornamento del software. Il termine shift-left in questo contesto trasmette l’idea di spostare le attività di test il prima possibile nella fase di sviluppo. L'organizzazione nello scenario di esempio deve prendere in considerazione l'incorporamento di questo approccio nella strategia DevOps per ridurre al minimo i problemi di sicurezza e stabilità correnti. In questa unità esaminare i diversi tipi di test che potrebbero essere implementati in questo modo e quindi esaminare i relativi metodi di implementazione.
Quali test che dovrebbero far parte dei test shift-left?
Lo sviluppo software incorpora un'ampia gamma di tipi di test, ma quelli di particolare interesse per noi includono:
unit test: questi test si concentrano sulle parti testabili più piccole di un codice dell'applicazione, ad esempio singole funzioni o metodi. L'obiettivo è stabilire se ogni unità di codice può eseguire correttamente l'operazione prevista in isolamento dal resto della codebase e dalle dipendenze esterne. Tali test devono essere completamente automatizzati, rapidi (completati entro 30 secondi) e fornire code coverage completo (il che significa fondamentalmente che tutti gli unit test devono testare collettivamente l'intera codebase). Gli unit test sono adatti all’approccio shift-left. È consigliabile applicarlo a tutto il codice il prima possibile nel ciclo di sviluppo, preferibilmente all'inizio della fase di programmazione.
Test di fumo: questi test sono destinati a valutare le funzionalità di base di un'applicazione in un ambiente di test. Anche se testano l'applicazione effettiva (anziché i singoli componenti isolati, come fanno gli unit test), lo scopo è determinare se la compilazione o la distribuzione dell'applicazione è sufficientemente stabile per garantire test più approfonditi. Tuttavia, non verificano l'interoperabilità tra le app. Come per gli unit test, devono essere completamente automatizzati e relativamente rapidi (l'interazione dell'utente può essere simulata usando gli strumenti di automazione del browser e i framework di automazione dell'interfaccia utente). Il termine test di fumo ha lo scopo di trasmettere l'idea che il fumo denota un problema grave (incendio) che dovrebbe essere risolto il prima possibile. I test di fumo devono essere implementati anche all'inizio del ciclo di sviluppo, preferibilmente non appena è disponibile una versione del software che fornisce le sue funzionalità di base. Questo vale sia per le fasi di compilazione che di distribuzione dell'applicazione.
Test di integrazione: questi test convalidano l'interazione tra componenti dell'applicazione diversi. A differenza degli unit test, il completamento può richiedere una notevole quantità di tempo. La durata estesa di questi test viene comunemente usata come argomento per eseguirli all'inizio del ciclo di vita dello sviluppo software. In generale, è consigliabile prendere in considerazione i test di integrazione negli scenari per i quali gli unit test o gli smoke test non sono adatti. Tuttavia, è consigliabile pianificarli per l'esecuzione in intervalli regolari. Questo approccio offre un compromesso ragionevole tra un potenziale ritardo nel rilevamento dei problemi di integrazione e un tempo di attesa aggiuntivo necessario per completarli.
test di accettazione: questi test determinano se un prodotto software soddisfa i requisiti aziendali ed è pronto per la consegna ai propri consumer. I test di accettazione non sono adatti per la strategia di spostamento a sinistra, ma potrebbe essere possibile incorporare alcuni dei relativi elementi all'inizio del ciclo di vita dello sviluppo software. Ad esempio, i criteri di accettazione e le storie utente, che sono componenti essenziali dei test di accettazione, devono essere introdotti all'inizio del processo di sviluppo. Ciò facilita la collaborazione tra team di sviluppo, proprietari di prodotti e stakeholder del progetto. Inoltre, i consumer di software e gli stakeholder del progetto devono essere coinvolti nelle fasi di test precedenti per condividere il loro feedback. Questo potrebbe comportare l'uso di metodi come test alfa o beta, test di usabilità o versioni precedenti, prima del test di accettazione formale.