how effectively prepare test bed
Banco di prova / Configurazione dell'ambiente di prova Sfide e best practice:
In diverse occasioni, i tester scoprono che i loro difetti vengono rifiutati per questioni ambientali o si trovano a replicare costantemente i difetti per ragioni simili. Mentre aprire il maggior numero di difetti deve certamente essere uno dei parametri di riferimento personali per ogni tester, la maggior parte dei tester deve anche sottolineare di avere il maggior numero di difetti validi.
Come si ottiene questo?
Oltre ad altri aspetti come la pianificazione di una varietà di scenari di test e la comprensione completa dell'elemento pubblicitario, a è necessario investire una buona quantità di tempo nella configurazione del banco di prova o dell'ambiente di prova . In secondo luogo, nonostante abbiano un importo stimato per la pianificazione del caso di test, anche i tester devono concentrare le proprie energie creazione di dati di test efficaci .
Personalmente, essendo parte del processo di audit, ho osservato che il maggior numero di difetti validi si riscontra quando è stato investito un buon impegno nella creazione del banco di prova o dell'ambiente di prova in modo corretto e quando il tester ha una comprensione del tipo di ambiente necessario.
Inoltre, il tipo di dati di test forniti all'ambiente di test può esporre alcuni difetti molto gravi nel codice / funzionalità sotto test che possono influire gravemente sulla qualità del prodotto.
Questo articolo parla di cosa comporta esattamente il Test Bed: è un processo in due fasi di configurazione dell'ambiente di test e configurazione dei dati di test:
Parte 1) La prima parte dell'articolo discuterà di processo generale di configurazione dell'ambiente di test , problemi di configurazione più comunemente affrontati da test e suggerimenti da tenere a mente durante la creazione di un banco di prova al posto di queste sfide.
Parte 2) Avendo detto così tanto in merito al Test Bed collettivamente in questo articolo, valeva la pena di gettare un po 'di luce sul Manutenzione dell'ambiente di prova anche aspetti. L'ultima parte dell'articolo discute la seconda parte della configurazione del banco di prova che coinvolge i dati del test, l'approccio per configurarlo e alcuni efficaci Testare le tecniche di gestione dei dati .
Con un 'big bang' costante nello sviluppo e nel test del software, c'è una crescente attenzione all'adozione di varie metodologie per rendere il processo complessivo di garanzia della qualità trasparente, efficiente e adeguato.
Vari audit di qualità vengono condotti tra le organizzazioni per garantire che le prestazioni del team di test possano essere adeguatamente valutate e abbiano risultati misurabili con le metriche identificate durante l'inizializzazione del ciclo di test. Questi risultati consentono di identificare la posizione di un determinato team in termini di garanzia di qualità ottimale per il software che testano.
Questi rapporti aiutano anche il team a comprendere le opportunità di miglioramento sulla base delle osservazioni fatte durante l'audit.
Inutile menzionare, una metrica molto ovvia per qualsiasi team di test sarebbe rispetto al numero totale di difetti aperti rispetto al numero di difetti validi . Quindi una delle domande che ovviamente si apre è: qual è la base per cercare di scoprire un difetto? Detto in altro modo, qual è il fondamento su cui si può riscontrare un difetto?
La risposta è unanime: Test Bed e / o Test Environment setup. Ci sono parametri di qualità impostati all'interno dei team per ridurre i difetti che vengono rifiutati come errore di configurazione del test / errore dell'utente, configurazioni non valide o in alcuni casi i difetti che si presentano come fughe da un particolare team a causa di configurazioni non disponibili, configurazioni non testate.
Cominciamo dando uno sguardo più da vicino alla definizione di cosa sia un banco di prova o un ambiente di prova.
Cosa imparerai:
Che cos'è un banco di prova e un ambiente di prova?
In un senso molto generico, un Test Bed potrebbe essere definito come una sorta di ambiente di sviluppo in cui gli implementatori di codice o moduli hanno la libertà di testare i propri moduli senza alcun disturbo da parte del team di test, in isolamento assoluto.
Tuttavia, un banco di prova non è solo specifico per un team di sviluppo. Dal punto di vista di un team di test o di un tester, poiché il Test Bed non è altro che una piattaforma identificata per il test di software / prodotto, è anche chiamato in modo intercambiabile Ambiente di test.
Qualsiasi banco di prova o ambiente di prova dovrebbe essere configurato in conformità per soddisfare l'obiettivo di test identificato per l'applicazione / prodotto / software in prova. In alcune situazioni, un banco di prova sarebbe la raccolta dell'ambiente di test e dei dati di test con cui opera.
Componenti di un ambiente di test
Qualsiasi test avrebbe i suoi requisiti specifici per l'ambiente di test, ma in un senso molto ampio, qualsiasi Test Bed / Ambiente di test comprenderà l'hardware, il software e le parti di rete per supportare la configurazione richiesta al minimo per guidare ed eseguire il test particolare .
È risaputo che una quantità ragionevole di tempo di un tester viene consumata da problemi ambientali, che a loro volta influiscono sulla produttività e sui programmi dei test. Sebbene il tipo di sfide varia per ogni team di test, alcune di esse potrebbero essere comuni.
Alcune sfide chiave che vengono comunemente affrontate sono:
# 1) Ambiente remoto
Gli asset o gli ambienti di test sono per lo più collocati geograficamente in siti remoti per i team. Questa è una delle sfide più comunemente affrontate dai team di test, come nel caso di eventuali problemi che possono sorgere relativi a hardware, firmware, software, rete, ecc.
I team che consumano le risorse dovrebbero fare molto affidamento sui team di supporto nel luogo in cui sono presenti le risorse.
Allo stesso modo, se qualche risorsa necessita di un aggiornamento del firmware o di un aggiornamento della build, ancora una volta il team di test potrebbe aver bisogno del supporto dei team di supporto proprietari dell'ambiente aprendo i ticket di supporto. Ciò può anche ritardare considerevoli tempi di test e ritardi, soprattutto in caso di differenze di fuso orario.
# 2) Utilizzo combinato tra i team
Molto spesso, i team di sviluppo e test utilizzano le stesse risorse ambientali. Sebbene la norma generale definisca che gli ambienti di sviluppo, test e produzione devono essere separati, in realtà questo scenario ideale viene raggiunto molto raramente. Diventa estremamente ostico per le organizzazioni procurarsi risorse separate per ogni team.
Quindi la maggior parte delle organizzazioni impone l'uso comune dell'ambiente tra sviluppo e test. In aggiunta a questo, se le risorse di sviluppo e test si contendono l'utilizzo delle stesse risorse contemporaneamente, si crea caos e disaccordi all'interno dei membri.
# 3) Pianificazione inefficace per l'utilizzo delle risorse per l'integrazione
In alcuni casi, per scenari che richiedono un file test end to end per cui vi è un'integrazione di due o più componenti per funzionare insieme, anche in questo caso potrebbe essere necessario disporre dell'utilizzo comune delle risorse tra i team di test. Una pianificazione inefficace rispetto all'uso contribuisce in larga misura al fatto che l'ambiente diventa instabile, oltre al conflitto tra i team.
L'effetto più evidente di ciò è che un problema rilevato per una o due volte particolare può produrre un comportamento completamente diverso nelle seguenti esecuzioni per lo stesso scenario. Se un difetto è già aperto per questo, ci sono alte probabilità che non venga accettato dallo sviluppo come candidato valido per una correzione.
# 4) Configurazione di test complessa
La configurazione del banco di prova o dell'ambiente di prova a volte è troppo complessa. Ciò comporterà diverse sfide poiché il team di test avrà bisogno delle competenze richieste per comprendere le configurazioni necessarie. A volte c'è una mancanza di base di conoscenza disponibile per il tester per essere in grado di elaborare la configurazione richiesta.
In tali casi, i tester stessi possono indurre un errore nel banco di prova configurandolo in modo errato. Ciò avrebbe un impatto notevole sul caso di test e sui risultati che produce.
# 5) Tempo di preparazione elaborato
In alcuni altri casi, per ogni caso di test, l'impostazione del test potrebbe essere troppo elaborata su ogni caso di test identificato. Ciò potrebbe essere dovuto a un'ampia varietà di tecnologie coesistenti che devono essere accoppiate o più componenti per lavorare insieme in casi di test di integrazione.
In questi casi, ciascuno dei componenti deve funzionare perfettamente per garantire risultati coerenti, poiché un componente può costituire un input per il successivo.
Migliori pratiche per la configurazione di un ambiente di test
Abbiamo esaminato l'ampio profilo delle sfide che un tester deve affrontare prima o durante l'inizio dell'esecuzione del test. La maggior parte di noi ha affrontato uno o più di questi problemi ad un certo punto durante le tappe fondamentali del nostro progetto. Queste sfide sono esistite e probabilmente continueranno a esistere in misura diversa perché non esiste una situazione idealistica.
Dato che le sfide di configurazione sono parte integrante del lavoro di un tester e sono inevitabili, ecco alcuni suggerimenti su come preparare in modo efficace la configurazione per i test. Ciò potrebbe aiutare a ridurre al minimo i difetti che possono derivare da problemi di installazione.
Suggerimento n. 1) Capire il Verificare accuratamente i requisiti e istruirti
elenca tutti i sistemi operativi con cui hai familiarità
Inizia sempre con le basi e con le più ovvie! Quando un documento di specifiche o un documento di caso d'uso viene distribuito dal team di sviluppo, il passaggio invariabile per il team di test consiste nel comprendere i requisiti dell'elemento pubblicitario e quindi preparare un documento del caso di test che dettaglia i casi di test.
Mentre la pianificazione del test viene eseguita, lo è il migliore pratica per includere anche le informazioni dettagliate sull'ambiente di test nel documento del caso di test. Non si suppone che il tester impiegherà del tempo ad analizzare quale ambiente di test potrebbe essere richiesto e di conseguenza le configurazioni necessarie.
Ciò può essere ottenuto parlando con il team di sviluppo / gli architetti al fine di costruire una buona base di conoscenza. Ciò non solo risparmierebbe un po 'di tempo nel ciclo di esecuzione, ma aiuterà anche un tester ad allocare efficacemente il suo tempo di esecuzione tra test semplici e complessi.
Personalmente, un buon risultato di questo è che molti di noi hanno scoperto problemi di configurazione (che impedirebbero intrinsecamente l'esecuzione di test coerente) all'inizio del ciclo, il che ci ha dato il tempo di canalizzare e acquisire l'aiuto necessario per risolvere quei problemi, quindi non prolungare il ciclo di prova oltre periodi inaccettabili.
Un altro impatto positivo che ciò avrebbe è che ciò migliorerebbe notevolmente la conoscenza del team di test e impedirebbe difetti inutili. Sebbene questa pratica riassuma quasi tutte le pratiche che sono intrinsecamente necessarie per far fronte alle sfide di configurazione del test sopra menzionate, vale comunque la pena menzionare gli altri suggerimenti.
Suggerimento n. 2) Verifica della connettività
Un altro punto di controllo più importante è assicurarsi che le risorse o gli asset che si intende utilizzare per i test siano raggiungibili. Nel caso in cui il sistema debba essere eseguito integrato con altre macchine, controllare la loro connettività tra loro utilizzando ping o telnet.
Inoltre, se i sistemi devono interagire tra loro e si trovano dietro i firewall, assicurati che possano autenticarsi attraverso questi firewall utilizzando le opzioni di sicurezza di base (BSO) e controlla anche eventuali proxy. Nel caso in cui noti che alcune macchine non sono raggiungibili o necessitano dell'autenticazione BSO, è possibile inviare richieste di servizio appropriate per soddisfare i requisiti al team di supporto.
Ciò è particolarmente utile quando l'ambiente è in posizioni remote ed eviterà anche escalation rispetto alle macchine e ai sistemi. Nel caso in cui il team di test richieda l'accesso a qualsiasi risorsa o repository, ciò aiuterebbe a determinarlo in modo proattivo.
Suggerimento n. 3)Verifica della rete e / o dell'archiviazione
Questa è quasi un'estensione del suggerimento precedente e avrebbe bisogno di un certo altro controllo in più con maggiore profondità tecnica. Assicurati che il test richiesto abbia la larghezza di banda necessaria e se il test richiede una connessione Internet. Inoltre, assicurati di trovare un modo per verificare che la topologia di rete tra sistemi e risorse sia corretta.
In secondo luogo, se il tuo obiettivo di test implica la necessità di qualsiasi spazio di archiviazione, assicurati che ci sia spazio di archiviazione e connettività di rete. Per lo più è responsabilità di un amministratore averlo in atto, tuttavia, è anche un grande valore aggiunto avere una certa conoscenza lavorativa e funzionale dello stesso.
Suggerimento n. 4) Verificare la presenza di hardware, software e licenze necessari
Molte volte accade che i tester inizino l'esecuzione sui sistemi senza controllare l'hardware e il software necessari che potrebbero essere richiesti. Di conseguenza, molte volte un tester si rende conto quasi durante il ciclo di test che alcune funzionalità sono disponibili solo su un livello superiore di hardware o software / firmware.
A quel punto il tester segnalerà un bloccante nel suo sforzo di test che consuma un considerevole tempo di test. Quindi è una pratica inestimabile avere un punto di controllo per prendere nota dell'hardware e del software che è necessario in precedenza.
Molte volte ci possono essere tempi di inattività coinvolti nell'aggiornamento dell'hardware / software, che si riduce tutto a Suggerimento 1 dove un tester deve coinvolgere nella pianificazione proattiva per quanto riguarda l'hardware. Alcuni software potrebbero richiedere licenze che potrebbero richiedere approvazioni e azioni da parte del team legale. Trattandosi di un'azione guidata dal processo, potrebbe essere necessario di nuovo richiedere alcuni giorni per essere completata, che deve essere pianificata.
Suggerimento n. 5)Browser e versioni
Il test che fai deve rispecchiare cosa eseguirà un utente finale . Potrebbe testare su un browser particolare sulle ultime versioni di tutti i browser. Quindi è obbligatorio identificare i diversi tipi di browser che verrebbero utilizzati per il test e installarli nella propria configurazione di test locale.
In secondo luogo, identifica anche quali versioni dei browser devono essere utilizzate per i test. Una buona pratica sarebbe quella di iniziare con un browser della versione inferiore, assicurando così la compatibilità con le versioni precedenti e quindi aggiornare alla versione più recente.
Suggerimento n. 6)Pianificazione dell'uso dell'ambiente di test.
Dato che il team di test non avrà mai la possibilità di avere risorse, sistemi e asset di test propri, è una delle pietre miliari principali nella pianificazione del test avere un utilizzo efficace delle risorse di test.
che cos'è un buon firewall gratuito per Windows 7 a 64 bit?
Ciò è particolarmente richiesto quando più di un team deve accedere allo stesso set di risorse a causa di uno scenario end-to-end che comprende due o più componenti che lavorano insieme o di una situazione in cui l'impostazione del test è troppo elaborata o complessa per essere replicata molto facilmente e potrebbero esserci più membri all'interno della stessa squadra che hanno i propri obiettivi di prova con la stessa configurazione.
Una buona pratica sarebbe quella di elaborare un approccio di condivisione del tempo in base al quale un determinato team o persona lo utilizza per la prima metà e le persone rimanenti per la seconda metà. Ci può essere un momento intermedio che sarà comune in cui ognuno di loro può eseguire test indipendenti che non ostacoleranno l'altro.
Ciò non solo ridurrà il caos e i conflitti all'interno dei membri, ma garantirà anche la stabilità comportamentale dell'ambiente per una durata più lunga.
Suggerimento n. 7)Strumenti di automazione e loro configurazioni
Come sappiamo, ogni elemento pubblicitario in fase di test avrà alcuni test ripetitivi che faranno parte del ciclo di regressione che dovrà essere automatizzato. Il team di test deve identificare il tipo di automazione che vorrebbe fare e gli strumenti necessari per farlo.
Sebbene questa necessità non debba far parte della preparazione dell'ambiente, la elencherei comunque come una best practice per identificare e configurare di conseguenza gli strumenti di automazione. Ciò dipenderebbe completamente dalla discrezione del tester quando desidera eseguire questa attività poiché questo non è un fattore obbligatorio per garantire la disponibilità del test.
Conclusione
Questi suggerimenti e trucchi possono costituire un buon parametro e un'impronta per garantire la disponibilità dell'ambiente di test per i test. Senza dubbio, ogni squadra deve affrontare la propria serie unica di sfide e i suggerimenti di cui sopra possono essere adattati e personalizzati per soddisfare le rispettive esigenze.
In effetti, la fonte per annotare questo intero scheletro di suggerimenti proviene da uno dei miei incarichi in cui ho affrontato problemi di installazione molto complessi e mi ci è voluto quasi un anno per iniziare i test!
Sebbene le limitazioni nell'ambiente di test fossero fuori dal mio controllo, ho ritenuto che molti di questi problemi avrebbero potuto essere segnalati in precedenza se avessi applicato questi suggerimenti. L'ho applicato per ogni incarico che mi è capitato da allora e questo scheletro mi ha aiutato molto nella ricerca proattiva dei problemi di installazione e canalizzare i miei sforzi per risolverli.
Circa l'autore: Questo articolo è stato scritto da Sneha Nadig. Lavora come Test lead con oltre 7 anni di esperienza in progetti di test manuali e di automazione.
Nella parte 2 di questo articolo, vedremo il processo di configurazione e manutenzione dell'ambiente di test e la preparazione dei dati di test e suggerimenti per la gestione. Nel frattempo, sentiti libero di pubblicare le tue domande sulla preparazione del banco di prova nei commenti.
Lettura consigliata
- Come eseguire i test post-rilascio in modo efficace e ridurre al minimo l'impatto del rilascio sui client attivi
- Come decidi quali difetti sono accettabili per il go-live del software?
- Come preparare e fornire al team una presentazione eccezionale per il test di qualità
- Processo di gestione dei difetti: come gestire un difetto in modo efficace
- 9 migliori idee per i tester per utilizzare in modo efficace il loro tempo al banco
- Leadership nei test - Responsabilità dei test lead e come gestire efficacemente il team di test
- Come pianificare e gestire i progetti di test in modo efficace (suggerimenti)
- Processo di valutazione dei difetti e modi per gestire la riunione di valutazione dei difetti