Leadership nel Test: Garanzia dei Processi Aziendali d’Impresa
Nota dell'editore: Benvenuti nella serie Leadership In Test a cura del guru del software testing e consulente Paul Gerrard. La serie è pensata per aiutare i tester con alcuni anni di esperienza—soprattutto quelli che lavorano in team agili—a eccellere nei loro ruoli di test lead e management.
Nell'articolo precedente abbiamo analizzato gli strumenti necessari per un testing e una collaborazione efficaci. In questo articolo parleremo della fase finale del testing e di come confermare che i vostri sistemi funzioneranno come previsto.
Iscriviti alla newsletter The QA Lead per ricevere una notifica quando verranno pubblicate le nuove parti della serie. Questi post sono estratti dal corso Leadership In Test di Paul che consigliamo vivamente per approfondire questo e altri argomenti. Se lo acquisti, usa il nostro coupon esclusivo QALEADOFFER per ottenere $60 di sconto sul prezzo del corso completo!
Siamo arrivati agli ultimi articoli della serie Leadership In Test. Fino ad ora abbiamo trattato come pianificare e gestire un progetto di test dall'inizio alla fine e molti degli strumenti e processi coinvolti.
In questo articolo vorrei parlare dell’Enterprise Business Process Assurance (EBPA): cos’è e come affrontarla. Vedremo insieme:
Want more from The CTO Club?
Create a free account to finish this piece and join a community of CTOs and engineering leaders sharing real-world frameworks, tools, and insights for designing, deploying, and scaling AI-driven technology.
Have an account? Log In
- Che cos'è l'Enterprise Business Process Assurance?
- Capire l'integrazione e il testing dei sistemi
- Testing orizzontale: l'approccio E2E
- Rischi di integrazione e testing E2E
Gli argomenti sono tanti, quindi iniziamo subito.
Che cos'è l'Enterprise Business Process Assurance?
Ogni organizzazione che implementa nuovi sistemi ha sperimentato problemi al momento del primo utilizzo. Sistemi che si adattano solo parzialmente alle infrastrutture e ai processi aziendali esistenti possono causare disastri e essere difficili da correggere.
Le pratiche iterative, agili e collaborative aiutano, ma le sfide dell'integrazione su scala enterprise possono essere affrontate solo con una fase finale di testing.
Chiamiamo questa fase finale Enterprise Business Process Assurance (EBPA). Il successo dipende da una o più fasi di test che dimostrino che i sistemi, i processi aziendali e i dati sono integrati e forniscono i servizi promessi.
Gli articoli accademici sull’argomento sono pochi, nonostante le fasi finali di ogni progetto su larga scala siano dominate da questa attività. Per definire la nostra strategia EBPA, iniziamo dando uno sguardo più approfondito ai tipi di integrazione e testing dei sistemi con cui avrai a che fare.
Nei progetti a livello enterprise, la complessità aumenta in modo esponenziale. Ecco perché scegliere un software di gestione database di livello enterprise può fare la differenza nei tuoi sforzi di qualità ingegneristica.
Capire l'integrazione e il testing dei sistemi
Integrazione verticale
Da una prospettiva tecnica, l'integrazione rappresenta la connessione tra i vari livelli dell’architettura tecnica. Il test di integrazione per gli sviluppatori consiste soprattutto nel controllare che i dati accettati tramite l’interfaccia utente in una transazione di aggiornamento vengano correttamente salvati nel database.
Nel senso opposto, si verifica che i dati memorizzati possano essere presentati accuratamente nell’interfaccia utente quando richiesto. Le connessioni e i percorsi nell’architettura tecnica possono essere visti come percorsi verticali o test di integrazione verticale.
Integrazione orizzontale
Gli utenti finali non vedono l’architettura tecnica e tutta la sua complessità. Vedono il sistema come una serie di funzionalità, utilizzate da diversi utenti in ciò che potremmo chiamare percorso utente.
Questi percorsi seguono i passaggi nei processi aziendali degli utenti e accedono a diversi sistemi e funzionalità ad ogni passo tramite l’interfaccia utente.
I team agili lavorano su storie di dimensioni ridotte e non vedono il quadro generale. Gli sviluppatori di solito non possono tracciare e testare percorsi utente più lunghi perché non hanno ambienti né dati sufficienti. Per questo, le organizzazioni si affidano di solito a test su scala maggiore e a team di tester per validarli.
I percorsi utente coprono naturalmente il processo aziendale e le funzionalità del sistema in combinazione. In questo modo, i test orizzontali mettono alla prova l’integrazione tra i sistemi e il processo aziendale.
Il collaudo d’integrazione verticale adotta una prospettiva più tecnica; il collaudo orizzontale adotta una prospettiva lato utente o di processo aziendale.
Ora utilizziamo questi concetti per costruire un modello che ci aiuterà a comprendere e pianificare l’EBPA. Faremo riferimento agli approcci di integrazione orizzontale e verticale nel modello.
Un modello per integrazione e test
L’integrazione è un concetto spesso frainteso. Il processo d’integrazione in realtà inizia quasi subito dopo l’inizio della scrittura del codice. Si può dire che l’integrazione abbia inizio quando ci sono due righe di codice: la seconda riga deve essere integrata con la prima. L’integrazione termina quando termina il testing funzionale in fase di accettazione utente.
Concentriamoci su un esempio che utilizza moduli commercial-off-the-shelf (COTS) e di enterprise resource planning (ERP).
La software house che crea moduli COTS o ERP ha già effettuato test di unità e funzionali. Quando questi componenti arrivano, di solito si può presumere che funzionino e che si integrino tecnicamente. Tuttavia, esiste sempre il rischio che componenti integrati provenienti da fornitori diversi interagiscano in modi imprevisti.
Inoltre, se i componenti vengono personalizzati, il loro comportamento cambierà e ciò potrà causare effetti collaterali sottili (e non tanto sottili) altrove. Rimane quindi la necessità di eseguire l’integrazione verticale per verificare lo scambio di controllo e dati nello stack tecnologico, e quella orizzontale tra componenti e processo aziendale.
Rappresentiamo le quattro attività di integrazione in un modello a quattro quadranti con due assi. Sull’asse X abbiamo la scala del sistema sotto test: o un singolo componente o sotto-sistema isolato, oppure i sistemi integrati nel contesto del processo aziendale.
Il lato destro del modello è evidenziato in blu e rappresenta EBPA. Testare il nostro sistema nel contesto di altri sistemi (SIT) e del processo aziendale (BIT) è ciò che definiamo Enterprise Business Process Assurance.
Vediamo ora i quattro quadranti uno alla volta.
Test di modulo, funzionalità o componente
Il modulo deve essere testato funzionalmente, sia che sia stato sviluppato su misura, sia che sia un componente COTS. L’esperienza utente è sempre importante e deve integrarsi con qualche passaggio o attività del processo aziendale.
Test di integrazione del sotto-sistema
L’integrazione è incrementale. Man mano che componenti e funzionalità di basso livello diventano disponibili, vengono integrati nel sistema sempre più grande e testati fino a quando il sistema completo, coerente, è pronto. Chiamiamo questa fase test di integrazione del sotto-sistema.
System Integration Testing (SIT)
Nessun sistema esiste isolatamente; quindi, quando il nostro sistema è completo, dobbiamo integrarlo con altri sistemi. Installiamo il nostro sistema in un ambiente che comprende i sistemi che lo interfacciano e testiamo questi sistemi come un ‘sistema di sistemi’ su queste interfacce. Il nostro obiettivo in questa fase è affrontare i rischi tecnici dell’integrazione e chiamiamo questa fase system integration testing.
Business Integration Testing (BIT)
C’è una fase finale di integrazione che mira a garantire che i sistemi realizzati si integrino con i processi aziendali e le procedure (spesso manuali) degli utenti di quei sistemi. Includendo le interfacce esterne del sistema (se non ancora testate), validiamo che i sistemi e i processi aziendali, lavorando in collaborazione, offrano percorsi utente coerenti ed efficienti e che gestiscano e trasferiscano correttamente e coerentemente i dati. Normalmente definiamo questa fase come business integration testing.
Nel resto di questo articolo, ci concentreremo molto sul lato orizzontale, EBPA, del modello.
Lettura correlata: 10 MIGLIORI STRUMENTI DI GESTIONE DEI DATI DI TEST
Test orizzontale: l’approccio E2E
L’integrazione orizzontale dipende soprattutto da ciò che comunemente viene chiamato End-to-End (E2E) testing.
L’E2E testing è una tecnica di progettazione di test che prevede una serie di transazioni collegate, tipicamente distribuite su più sistemi compreso il nostro sistema (o i nostri sistemi) sotto test. Questi test tendono a seguire i percorsi degli utenti all’interno dei loro processi aziendali.
Dato un modello di processo aziendale, si seguono percorsi all’interno del processo per creare una serie utile di transazioni che simulano il modo in cui gli utenti utilizzeranno il sistema in produzione.
Questi modelli possono essere diagrammi noti come flowchart o diagrammi swim-lane, oppure rappresentazioni più tecniche come UML sequence o collaboration diagrams. (UML è il linguaggio di modellazione unificato utilizzato da molte organizzazioni IT).
I test E2E affrontano rischi specifici che non possono essere facilmente gestiti da test precedenti su sotto-sistemi o ambienti che dipendono fortemente da interfacce simulate e dati puramente sintetici.
Nell’ambito del Test Orizzontale, l’approccio E2E è spesso completato da software specialistico. Per un elenco curato di soluzioni che possono ottimizzare questo processo, consulta queste soluzioni di test management più raccomandate
Accettazione
Il concetto di "adattamento" è appropriato per l'integrazione tra componenti, l'integrazione tra sistemi e l'integrazione tra sistemi e processi aziendali.
L'accettazione si basa normalmente sui risultati dei test E2E orizzontali perché le parti interessate aziendali possono fidarsi che questi test mostrino come il nuovo sistema si adatti e supporti i loro metodi di lavoro. I test E2E orizzontali danno loro fiducia che il servizio fornito funzionerà.
Il processo di accettazione dei sistemi di solito dipende in parte dal successo dei test E2E orizzontali. Questo perché solo i test E2E mettono alla prova il sistema in un ambiente realistico e simulano l'attività reale degli utenti.
In molte organizzazioni, è possibile dimostrare che i sistemi funzionano solo nelle fasi finali dei test e questo dà fiducia alle parti interessate che il sistema funzionerà come richiesto.
Se ti viene chiesto di pianificare un test di accettazione, ci si aspetta che la tecnica del test E2E giochi un ruolo importante nella tua pianificazione.
Rischi di integrazione e test E2E
Come già discusso, i rischi di integrazione riguardano l'integrazione tra sistemi o l'integrazione tra sistemi e processi aziendali.
Alcune organizzazioni scelgono di suddividere i test che affrontano questi due tipi di rischi in System Integration Testing (SIT) e Business Integration Testing (BIT). Ma spesso i rischi e i test vengono uniti in una singola fase di test denominata E2E, Accettazione o Test di Business.
Indipendentemente da come sono strutturati i test, si fa ampio uso dell'approccio di test E2E spiegato sopra. Nel tuo ambiente, i rischi che affronti potrebbero essere variazioni di questi temi e potresti dover adattare l'obiettivo del test e il tuo approccio di test di conseguenza.
L'elenco dei rischi presentato qui dovrebbe essere considerato solo un punto di partenza e per ricordarti dove dovresti concentrare le tue attività di test. È probabile che esistano rischi specifici per la tua organizzazione, il tuo settore o la tecnologia utilizzata che dovrai aggiungere a questo elenco iniziale.
Nella tabella sottostante, "sistemi" si riferisce all'insieme dei sistemi integrati che comprendono il nuovo sistema o i sistemi in fase di sviluppo, altri sistemi legacy o infrastrutturali e sistemi esterni, ad es. banche o organizzazioni partner.
| Rischio | Obiettivo del test | Approccio al test |
| I sistemi non sono integrati (trasferimento dati). | Dimostrare che i sistemi sono integrati ed eseguono correttamente il trasferimento dati. | System Integration Test (SIT) |
| I sistemi non sono integrati (trasferimento del controllo). | Dimostrare che i sistemi sono integrati (il trasferimento del controllo con i parametri richiesti avviene correttamente). | SIT |
| Le interfacce falliscono se utilizzate per un periodo prolungato. | Dimostrare che le interfacce possono essere utilizzate continuamente per un periodo prolungato. | SIT (Questi controlli potrebbero anche essere eseguiti come parte del Reliability e/o Failover Testing) |
| I sistemi non sono integrati (i dati non sono riconciliati tra le interfacce). | Dimostrare che i sistemi sono integrati (i dati trasferiti tramite l'interfaccia vengono utilizzati in modo coerente, ad es. valuta, lingua, metriche, tempi, precisione, tolleranze). | SIT |
| I sistemi non sono sincronizzati (i trasferimenti dati non sono attivati, sono attivati al momento sbagliato o più volte). | Dimostrare che i trasferimenti dati sono attivati correttamente. | SIT |
| Oggetti o entità che esistono in più sistemi non sono riconciliati tra i sistemi. | Dimostrare che gli stati degli oggetti di business sono rappresentati accuratamente tra i sistemi che detengono i dati sugli oggetti. | Business Integration Test (BIT) |
| I sistemi non sono integrati con il processo aziendale (supply chain). | Dimostrare che i sistemi si integrano con i processi aziendali e supportano il processo della supply chain. | BIT |
| I processi aziendali di back-end non supportano i front-end Web o mobile. | Dimostrare che i processi della supply chain sono funzionali e supportano l'obiettivo aziendale. | BIT |
| I sistemi integrati utilizzati dallo stesso personale hanno interfacce utente o comportamenti incoerenti per attività simili o correlate. | Dimostrare che gli utenti vivono un comportamento coerente tra i sistemi mentre effettuano attività simili o correlate. | BIT (Questi controlli potrebbero essere eseguiti anche durante la verifica UX) |
Note sulla tabella dei rischi
Alcuni dei rischi sopra elencati richiedono qualche spiegazione in più.
Problemi di trasferimento dati
Spesso i dati vengono trasferiti tra sistemi attraverso le reti. Se questi trasferimenti vengono eseguiti come processi batch e falliscono, oppure falliscono come trasferimento in tempo reale attivato da un utente, da un'azienda o da un altro evento di sistema, allora i dati mancheranno nel sistema di destinazione.
Trasferimento del controllo difettoso
Il trasferimento del controllo è quando un'attività dell'utente o un processo di sistema trasferisce l'utente o il processo a un'altra funzionalità del sistema.
Tipicamente esiste una scelta di funzionalità di destinazione e, a seconda dell'azione dell'utente o del contenuto dei dati di una transazione, viene scelta una differente via attraverso l'applicazione.
Dal punto di vista dell'utente, essi vengono indirizzati nella posizione sbagliata dell'applicazione oppure un processo di sistema si aspetta di operare su un processo errato e perde la sincronizzazione.
I dati non sono riconciliati
Un sistema potrebbe distribuire dati relativi, ad esempio, a denaro, posizione di asset o a una quantità fisica che deve "tornare" tra tutti i sistemi.
Ad esempio, quando vengono acquistati e movimentati 100 articoli di magazzino, venduti, utilizzati nei processi produttivi, considerati difettosi e restituiti o scartati, il numero di articoli detenuti in ciascun sottosistema deve riconciliarsi con il conteggio originale di 100.
Una variante di questo problema riguarda, ad esempio, le unità utilizzate nei sistemi che gestiscono i dati. Le dimensioni dei lotti o le aggregazioni di conteggi devono essere contabilizzate, oppure i sistemi devono far coincidere misure metriche e imperiali, e così via.
Sistemi Non Sincronizzati
Relativamente al problema di trasferimento dati sopra descritto, i processi di sistema che effettuano i trasferimenti sono programmati per essere eseguiti nella giusta sequenza, attivati da processi o persone opportunamente autorizzati, e vengono attivati tempestivamente e dall'evento appropriato o dalla confluenza di eventi appropriati.
Alcuni processi batch devono essere eseguiti ogni ora, giorno, settimana, a fine mese, trimestre o anno e necessitano di essere verificati. Molto del comportamento funzionale dipende dalla tempistica relativa delle transazioni o dall'età dei dati nei vari sistemi e ciò deve anch'esso essere verificato.
Oggetti Non Riconciliati
Piuttosto che i conteggi degli oggetti, del denaro o delle misurazioni fisiche, questi rischi riguardano lo stato degli oggetti detenuti in sistemi distribuiti. Ad esempio, lo stato del dipendente in un record del personale dovrebbe essere coerente tra tutti i sistemi che possiedono una copia di quell'oggetto. I processi che distribuiscono le variazioni di stato tra i sistemi che tengono copie dello stesso oggetto devono essere attivati e le loro azioni devono essere verificate.
Sistemi Non Integrati con il Business
Il comportamento dei sistemi deve essere sincronizzato con le intenzioni degli utenti. I problemi tipici si verificano quando il sistema presenta informazioni incomplete, obsolete o sbagliate. La causa principale di ciò risiede nel trasferimento o nella sincronizzazione dei dati che non funzionano correttamente, ma questi problemi si manifestano tramite l'interfaccia utente.
Processi Back-end Non Supportano il Front-End
Questo tipo di problema si manifesta come un'incoerenza tra i sistemi di registrazione e i sistemi di interazione. I processi batch back-end che non vengono eseguiti con sufficiente frequenza, o per nulla, non rendono disponibili i dati ai sistemi front-end d'interazione. Allo stesso modo, le transazioni degli utenti attraverso i sistemi di interazione non sono riflesse nei sistemi di registrazione.
Interfacce Utente Incoerenti
Quando un'azienda o un servizio viene offerto tramite interfacce mobile, web e da chiosco, l'interfaccia utente si comporta in modo diverso o incoerente. Potrebbero essere state tutte testate indipendentemente, ma il loro comportamento è differente. Ad esempio, vengono applicate diverse regole di validazione degli input, vengono acquisiti/visualizzati diversi campi dati oppure la sequenza degli input è differente.
Considerazioni Finali
Abbiamo presentato un modello di integrazione e test che dà rilievo all'integrazione a livello aziendale e al processo di business. L'approccio E2E è l'unico che richiede l'integrazione totale dei sistemi e basa i test su percorsi utente completi. In questo modo, gli stakeholder possono vedere prove concrete del corretto funzionamento dei sistemi in un contesto realistico.
Molte organizzazioni si affidano agli utenti per applicare una forma di test E2E nei loro test di accettazione e per eseguire tali test manualmente. Dall'esperienza, consiglio un approccio più sistematico, basato sul rischio, che facilita l'automazione di gran parte dell'esecuzione dei test laboriosi.
Man mano che le organizzazioni adottano approcci di sviluppo agile e delivery continua più dinamici, affidando ai team agile maggiori responsabilità sui test dei propri sottosistemi, è facile trascurare i test di integrazione e accettazione a livello aziendale.
L'approccio EBPA, specialmente se automatizzato, estende il regime di integrazione continua dal sottosistema alla garanzia dei processi di business aziendale.
I pacchetti COTS ed ERP consentono di implementare sistemi molto potenti ma complessi con un minore impegno di sviluppo, ma i rischi di integrazione rimangono altrettanto evidenti quanto nello sviluppo di software su misura.
Negli ambienti più grandi, gli approcci agili e di continuous delivery sono sempre più popolari, quindi al crescere della complessità e della scala aumentano anche la frequenza delle consegne e il rischio associato.
La soluzione è chiara: le organizzazioni devono prendere sul serio l'EBPA. Devono comprendere i rischi di integrazione e come strutturare i test per affrontarli. I tester devono muoversi verso l'approccio moderno basato sui modelli, astraendo i propri processi aziendali, sistemi e test ed implementando sistematicamente l'automazione dei test.
Iscriviti alla newsletter di The QA Lead per essere avvisato quando verranno pubblicate nuove parti della serie. Questi post sono estratti dal corso Leadership In Test di Paul che consigliamo vivamente per approfondire questo e altri argomenti. Se lo fai, usa il nostro codice coupon esclusivo QALEADOFFER per ottenere $60 di sconto sul prezzo totale del corso!
Lettura consigliata: 10 MIGLIORI TOOL OPEN SOURCE PER LA GESTIONE DEI TEST
