Più di 40 domande e risposte per l'intervista agli analisti di test più popolari (2021 LIST)

40 popular test qa analyst interview questions

Domande e risposte per l'intervista agli analisti di test / controllo qualità più frequenti:

Mentre decidi la carriera in cui vuoi essere, il fattore decisivo non è solo quello su cui pensi possa divertirti a lavorare.

Ma essere in quella categoria richiede molte abilità, comprensione delle responsabilità e delle mansioni lavorative necessarie per la carriera che hai scelto. Lo stesso vale per la scelta di una carriera come analista QA. Non richiede solo che tu sia un buon tester, uno studente veloce, un pensatore straordinario, ma richiede anche di essere anche un risolutore di problemi complessi.

Sebbene le suddette qualità non vengano raggiunte all'istante, ovviamente richiede anche esperienza e giorni di duro lavoro.

Questo articolo tratterà ogni aspetto la cui conoscenza è obbligatoria per essere un analista del controllo qualità. Le domande e le risposte del colloquio con l'analista del test di QA più frequenti incluse qui ti daranno un'idea chiara della preparazione del colloquio.

Domande frequenti per l'intervista agli analisti del test di controllo qualità

D # 1) Quali sono le responsabilità di un analista QA?

Risposta: QA Analyst è colui che garantisce che ogni possibile misura sia stata presa per testare ogni caratteristica della soluzione software sia dal punto di vista funzionale che tecnico.

Le principali responsabilità di QA Analyst possono essere elencate come segue:

• Eseguire e gestire tutte le attività per raggiungere gli obiettivi del piano di test.
• Scegli i processi di alta qualità per sviluppare il prodotto.
• Dovrebbe essere in grado di analizzare i requisiti e documentare le procedure.
• Documentare e verificare nuovamente tutti i difetti. Imposta la priorità e la gravità dei difetti.
• Dovrebbero essere in grado di creare, documentare e mantenere i casi di test.
• Analisi dei risultati dei test.

D # 2) Qual è la tua comprensione riguardo a un piano di test?

Risposta: Quando hai un'idea chiara di cosa, quando, come e chi, allora le cose diventano più facili. Lo stesso vale anche per il test del software, dove il piano di test è un documento che consiste in ambito, approccio, risorse e struttura del progetto di test, nonché le attività per monitorare l'avanzamento del progetto.

Il piano di test è un record di processi che includono:

• Attività di test
• Ambiente di prova
• Tecniche di progettazione
• Criteri di ingresso e di uscita
• Eventuali rischi, ecc.

D # 3) Elenca la priorità delle attività di test definite dal team QA nello sviluppo del prodotto.

Risposta: La priorità delle attività di test è definita come segue:

• Viene preparato un piano di test costituito dallo schema e dall'ambito del progetto di test.
• I casi di test sono preparati per coprire tutte le funzionalità principali e secondarie con i dati richiesti per il test.
• Esecuzione dei test case secondo le funzionalità implementate con le prossime build del progetto di testing nel ciclo di testing.
• Segnalazione dei difetti con nuova verifica e monitoraggio dei suoi progressi.
• Preparazione del riepilogo del report di esecuzione del test.

D # 4) Elenca alcune delle sfide chiave che devono essere affrontate durante l'esecuzione del test del software.

Risposta: Poiché diciamo che il test completo non può mai essere raggiunto, ci sono diverse sfide in esso coinvolte. Che sia piccolo o complicato, ci sono alcune sfide da affrontare durante l'esecuzione di test del software di qualsiasi progetto.

Di seguito sono elencate alcune sfide chiave:

• Mancanza di tester qualificati che di solito affrontano il problema della consapevolezza del soggetto così come la mancanza di una buona conoscenza dell'attività del cliente.
• Anche il tempo è considerato un fattore, poiché di solito i tester si concentrano principalmente sulla copertura delle attività piuttosto che sulla copertura dei test con test di qualità quando c'è un enorme elenco di attività da completare.
• Per decidere quale test case deve essere eseguito per primo e con priorità. Questo di solito si ottiene con l'esperienza di lavoro.
• Una corretta comprensione dei requisiti che può portare a zero tutti i tuoi sforzi di test, se il requisito viene frainteso.
• Indisponibilità dei migliori strumenti necessari per completare il test con minor tempo e maggiore efficacia.
• Gestire la relazione tra tester e sviluppatori con buone capacità di comunicazione e analisi.

D # 5) Definire il test dei casi d'uso.

Risposta: Il test del caso d'uso può essere definito come la tecnica di test della scatola nera funzionale che cattura la serie di interazioni che si sono verificate tra 'attori' e 'sistema'. Qui, gli 'attori' sono rappresentati dagli utenti e dalle loro interazioni.

Le caratteristiche del test del caso d'uso sono elencate di seguito:

• Vengono organizzati i requisiti funzionali del progetto.
• Registra il percorso o gli scenari dall'inizio alla fine.
• Può coprire i difetti di integrazione, ovvero i difetti che si sono verificati a seguito dell'interazione tra diversi componenti.
• Descrive i flussi principali così come il flusso eccezionale degli eventi.
• Eventuali pre-condizioni necessarie per il funzionamento del caso d'uso devono essere specificate in precedenza.

D # 6) Definire la strategia di test.

Risposta: Una serie di linee guida o approcci di test che vengono solitamente eseguiti dal project manager per determinare la progettazione del test e l'approccio di test generale è definito come Strategia di test. Si trova come una piccola sezione del piano di test e viene utilizzato da più progetti.

Vengono seguiti approcci di test diversi in base a fattori come la natura e il dominio del prodotto, il rischio di guasto del prodotto, l'esperienza nel lavorare con gli strumenti proposti, ecc.

Questi approcci sono ulteriormente classificati come segue:

• Approccio proattivo , dove l'approccio ai progetti di test inizia prima della creazione della build. Quindi aiuta a trovare e correggere i bug prima della compilazione.
• Approccio reattivo , dove l'approccio di test viene avviato dopo il completamento della progettazione e della codifica del test.

Q # 7) Spiegare la differenza tra controllo di qualità e garanzia di qualità.

Risposta: 'Controllo di qualità' e 'Garanzia di qualità' sono i due termini principali utilizzati per qualsiasi progetto o prodotto di test. Di solito, i tester, che sono nuovi in ​​questo campo, non comprendono l'effettiva differenza tra i due.

Comprendiamo la differenza con l'aiuto della tabella seguente.

Q # 8) Secondo te, qual è il momento giusto per iniziare il controllo qualità in un progetto?

Risposta: Secondo il ciclo di vita dello sviluppo software (SDLC), la fase di test viene eseguita dopo il completamento della fase di 'implementazione e codifica'. Ma nello scenario odierno, per ottenere i migliori risultati, è necessario avviare il QA del progetto o del prodotto all'inizio del progetto.

Seguendo questo approccio si otterranno i principali vantaggi indicati di seguito:

• Pianificazione anticipata del processo per soddisfare le aspettative di qualità del cliente.
• Comunicazione buona e sana tra le squadre.
• Fornisce un'ampia quantità di tempo necessaria per configurare l'ambiente di test.
• Consente la revisione e l'approvazione anticipate dei piani di test.

D # 9) Differenziare i processi di verifica e convalida.

Risposta: I processi di verifica e convalida sono generalmente determinati da due famose domande, ovvero ' Stiamo costruendo il sistema giusto? ' e 'Stiamo costruendo il sistema giusto?' .

Vediamo l'altra differenza tra questi due processi nella tabella seguente:

D # 10) Spiega i vantaggi dei test distruttivi.

Risposta: Il test distruttivo è definito come la forma di test che viene eseguita dal team di test per determinare il punto di guasto del prodotto sotto carichi diversi, ovvero per valutare le prestazioni strutturali dell'applicazione per determinarne la resistenza, la tenacità, la durezza o, per dire, la robustezza.

Di seguito sono elencati i vantaggi dei test distruttivi:

• Viene determinata la debolezza del design dell'applicazione.
• Determina la durata dell'applicazione.
• Aiuta a ridurre i costi e i guasti.

D # 11) In che modo il nuovo test è diverso dal test di regressione?

Risposta: Esistono molte differenze tra la ripetizione del test e il test di regressione.

Questo può essere facilmente compreso dalla tabella seguente:

D # 12) Cosa sai dei test basati sui dati?

Risposta: È molto chiaro per ogni tester di automazione che gli script di test di automazione coprono solo l'area dell'applicazione da testare con una sequenza registrata di azioni dell'utente. Normalmente, queste azioni non producono alcun errore poiché solo i dati di input vengono presi in condizioni che abbiamo inserito durante la registrazione.

I test basati sui dati entrano in scena qui, dove vogliamo che l'applicazione funzioni come previsto per qualsiasi tipo di valori di input. A tal fine, i dati richiesti per i test basati sui dati non sono codificati, ma gli script di test prendono i dati da fonti di dati come file CSV, fonti ODBC, ecc.

Per riassumere, il test basato sui dati esegue le seguenti azioni nel ciclo:

metodo che accetta un array

• Prende i dati di test di input dalla memoria.
• Dati inseriti nell'applicazione per eseguire azioni.
• Verificare i risultati effettivi con quelli attesi.
• Ripetere nuovamente gli stessi passaggi con i nuovi dati di test di input.

D # 13) Cos'è la matrice di tracciabilità? È richiesto per ogni progetto?

Risposta: La matrice di tracciabilità in qualsiasi progetto è il mezzo per tracciare lo stato di avanzamento del progetto riguardante l'implementazione di nuove funzionalità, il potenziamento di funzionalità esistenti, ecc. Attraverso una matrice di tracciabilità, è possibile tenere sempre d'occhio lo stato di avanzamento del progetto con ogni aspetto mantenuto come da l'appuntamento.

La matrice di tracciabilità dei requisiti è costituita dai parametri indicati di seguito che sono effettivamente conformi al documento di specifica dei requisiti.

I parametri della matrice di tracciabilità dei requisiti includono:

• Ogni sezione del documento del requisito è un punto da trattare nella RTM (Requirement Traceability Matrix).
• Il titolo di ogni punto è il titolo di ogni sezione nella specifica dei requisiti.
• In corrispondenza di ogni punto, vengono menzionati gli ID del test case scritti per quella particolare sezione.
• BUG / New Feature ID è menzionato anche in ogni sezione.
• Il punto più importante è che viene mantenuto il monitoraggio della funzionalità in cui è stata implementata la build del progetto e la sua funzionalità.
• Un altro parametro include se la sezione è completamente testata o è ancora in stato di test.

D # 14) Descrivi i vantaggi dell'Agile Testing.

Risposta: Essendo un tester, l'obiettivo diventa fornire il prodotto di qualità in meno tempo, comprendendo le esigenze dell'utente finale e, soprattutto, nessun difetto dal lato dell'utente finale. Qui, il test Agile entra in scena che segue il principio dello sviluppo software agile e convalida rapidamente i requisiti del cliente.

Di seguito sono indicati i vantaggi dei test Agile:

• Un team agile interfunzionale è incluso nei test, che a sua volta fornisce i risultati a intervalli frequenti.
• Risparmia molto tempo e denaro.
• Include meno documentazione e feedback periodici da parte dell'utente finale.
• Non solo il tester, ma l'intero team, compreso il manager, il cliente e lo sviluppatore, sono coinvolti nella comunicazione faccia a faccia.
• Come risultato delle riunioni quotidiane, i problemi possono essere determinati in anticipo.
• Aumento della produttività del team e una migliore comprensione degli aspetti tecnici del progetto.

Q # 15) Che cos'è il test negativo?

Risposta: Il test negativo è il metodo per garantire che la stabilità di un prodotto o di un'applicazione sia mantenuta o dire di non fallire quando viene fornito un input imprevisto. Lo scopo principale di questa forma di test convalida l'applicazione rispetto a eventuali dati di input non validi.

Questa forma di test è anche nota come 'Test di errore' o 'test del percorso di errore' e il suo scopo principale è verificare l'affidabilità della funzione dell'applicazione in scenari negativi. Inoltre, espone la debolezza del software, individua i difetti e fornisce un'idea chiara del danneggiamento dei dati.

D # 16) Differenziare test ad hoc e test esplorativi?

Risposta: Esistono molte differenze tra test ad hoc e test esplorativi.

Vediamo le differenze nella tabella sottostante:

D # 17) Perché il test di automazione è preferito al test manuale?

Risposta: Bene, sia i test di automazione che i test manuali hanno la loro importanza ed esistenza nel mondo dei test.

Di seguito sono riportati alcuni aspetti importanti per i quali il test di automazione è preferito rispetto al test manuale:

• Lo stesso script di test può essere utilizzato ogni volta per eseguire il test, quindi il test di automazione è considerato il più affidabile ed efficiente.
• Preferibilmente in caso di test di regressione ed esecuzione ripetuta.
• I test di automazione sono considerati convenienti in caso di esecuzione a lungo termine e quindi garantiscono una migliore qualità del software.
• Gli script di test sono riutilizzabili, veloci e tutti possono vedere i risultati.
• Gli strumenti utilizzati per i test di automazione sono più veloci e affidabili rispetto all'approccio manuale.

Tuttavia, alcuni altri fattori determinano che i test di automazione sono preferiti rispetto ai test manuali. Quanto sopra sono i fattori principali.

D # 18) Cosa intendi per 'Test efficacia' e 'Test efficienza'?

Risposta: testare l'efficienza può essere definito come il calcolo del numero di risorse e del codice di test consumato per eseguire o dire eseguire una particolare funzione. Determina inoltre il numero di risorse utilizzate nella creazione del prodotto software.

Questo può essere determinato dalla formula:

Efficienza del test = (Numero di difetti risolti / numero totale di difetti presentati) * 100

Efficacia del test può essere definito come la misura di valutazione dell'ambiente di test e dei suoi effetti sull'applicazione software. Qui la risposta del cliente viene valutata quando il requisito dell'applicazione è soddisfatto.

Questo può essere determinato dalla formula:

Efficacia del test = (Numero di difetti trovati / Numero di casi di test eseguiti)

D # 19) Spiega il processo di Project Tailoring.

Risposta: La personalizzazione del progetto è un processo coerente e continuo che garantisce che le prestazioni del progetto siano corrette e conformi ai requisiti aziendali. L'intero processo include la revisione e la modifica dei dati del progetto secondo le attuali necessità operative dell'organizzazione.

Il processo di revisione viene eseguito a livello organizzativo, ma l'implementazione dei piani di adattamento viene eseguita a livello di progetto. L'obiettivo principale e i requisiti dell'organizzazione, nonché le relazioni con i clienti e gli utenti, sono i due fattori principali che dovrebbero essere considerati nel processo.

Alcuni aspetti secondo gli obiettivi organizzativi nell'ambito del processo di sartoria sono:

• Approccio al progetto
• Strategie
• Controlli e processi coinvolti
• Ruoli e responsabilità

D # 20) Come distingui tra priorità e gravità del difetto all'interno del progetto?

Risposta: Sia 'Priorità' che 'Gravità' vengono assegnate al bug per la classificazione dei problemi / bug per l'ordine in cui devono essere presi per la correzione. Questi si basano su vari fattori.

Cerchiamo di capire di più insieme alle loro differenze nella tabella seguente:

D # 21) Perché è necessario eseguire il test delle prestazioni per qualsiasi applicazione?

Risposta: In un linguaggio semplice, il test delle prestazioni viene eseguito per determinare il comportamento e la risposta di un'applicazione in varie situazioni. Questo aiuta a raccogliere informazioni riguardanti la stabilità dell'applicazione, la scalabilità, la velocità, ecc.

Le ragioni per eseguire il test delle prestazioni possono essere comprese dai seguenti punti:

• Determina il tempo di risposta e le prestazioni di un componente dell'applicazione sotto il carico di lavoro.
• Viene calcolato il tempo di risposta dell'attività dell'utente.
• Richiede programmatori esperti con un ampio linguaggio tecnico.
• Determina il comportamento dell'applicazione sotto carico, ovvero quando il numero di utenti aumenta istantaneamente.

D # 22) Che cosa sono i test guidati dalle specifiche?

Risposta: Come definisce il nome stesso, i test guidati dalle specifiche vengono eseguiti in base alla specifica dei requisiti dell'applicazione in cui le specifiche funzionali fungono da base per i test eseguiti.

Questa forma di test è la stessa del 'test della scatola nera' in cui l'utente inserisce più dati e quindi l'output viene osservato. È appropriato a tutti i livelli di test con specifiche e piano di test.

D # 23) Spiega CMMI.

Risposta: CMMI è l'acronimo di Capability Maturity Model Integration. Questo modello è stato sviluppato dal Software Engineering Institute (SEI). Si basa sul principio che i processi coinvolti nella gestione e nello sviluppo di un prodotto o sistema determinano la qualità.

Fornisce inoltre linee guida per il miglioramento del processo per il prodotto o anche per l'intera organizzazione.

CMMI è diviso in 5 livelli come elencato di seguito:

• Livello 1: Iniziale
• Livello 2: Gestito
• Livello 3: Definito
• Livello 4: Gestito quantitativamente
• Livello 5: Ottimizzato

D # 24) Spiegare i vantaggi dell'implementazione di CMMI.

Risposta: Ci sono diversi vantaggi nell'implementazione di CMMI.

Sono elencati come segue:

• Fornisce una copertura e un rapporto dettagliati del ciclo di vita del prodotto e quindi aiuta a migliorare i processi.
• Gli standard esistenti dell'organizzazione, i loro processi e le procedure vengono migliorati come parte dell'implementazione del CMMI.
• Come risultato dell'implementazione di CMMI, si verifica un aumento della puntualità nelle consegne e della soddisfazione del cliente.
• Inoltre porta a una gestione efficace e a maggiori risparmi sui costi grazie al rilevamento precoce degli errori.

D # 25) Utilizza alcuni strumenti di test di automazione.

Risposta: Alcuni degli strumenti di test dell'automazione sono elencati di seguito:

• Selenio
• acqua
• Mulino a vento
• SAPONE
• Tellurio

D # 26) Possiamo eseguire test di regressione in Unit Testing?

Risposta: Decisamente. Il test di regressione serve a testare il difetto indesiderato che potrebbe essere stato introdotto nel codice come effetto collaterale della correzione di altri difetti. Il test unitario è l'esecuzione di test dell'esecuzione di una piccola parte di codice indipendente e individuale.

I test di regressione possono essere eseguiti a qualsiasi livello, dal test unitario al test di integrazione fino al test di accettazione. Il test di regressione è un test basato sulla prospettiva, mentre il test unitario è l'approccio di livello (dal basso verso l'alto, dall'alto verso il basso).

Q # 27) Qual è la differenza tra il test del fumo e il test di sanità mentale?

Risposta:

• Il test di fumo è il test delle vecchie caratteristiche importanti o delle caratteristiche esistenti della build, mentre il test di sanità mentale è la convalida dei moduli appena aggiunti, difetti corretti nella build.
• Il test del fumo viene eseguito prima e poi è seguito dal test di sanità mentale.
• Il test del fumo copre il test delle funzionalità critiche fornite dal software in modo che si estenda a tutto il software. Il test di sanità mentale, d'altra parte, è ristretto solo ai moduli aggiunti di recente e viene testato in profondità.

Q # 28) Quali sono le tue attività quotidiane come tester manuale nel tuo ufficio?

Manuale: La prima cosa che controllo nel mio sistema è aggiornare la dashboard per lo stato di requisiti / miglioramenti o bug nell'iterazione corrente. È seguito da chiamate giornaliere di scrum e sessioni di reporting, discussione e brainstorming per la definizione di scenari di test e casi di test.

Questi casi vengono quindi eseguiti dopo essere stati riformulati come da revisione. Anche la collaborazione con i clienti per esigenze non funzionali è una delle attività principali che ho a disposizione.

Q # 29) Quali sono le tue attività quotidiane come membro del tester di automazione nel tuo ufficio?

Automazione: La mia giornata inizia con un incontro quotidiano sullo stato che discute i risultati dell'automazione di ieri, nel caso in cui avessi attivato una serie di casi di test sulla nuova build.

Il ciclo di esecuzione può essere chiamato Health Check, per vedere quanto è sana la build.

È seguito dalla segnalazione di difetti in base agli errori di script, modifiche di progettazione nella funzionalità; mantenere gli script / librerie o funzioni, automatizzare e archiviare un nuovo script per i nuovi requisiti e, se necessario, una nuova funzione nella libreria delle funzioni.

A volte gli script di test devono essere rieseguiti individualmente per trovare i difetti di regressione tramite l'automazione e aggiungerli anche alla suite di test.

Q # 30) Come distingui tra un requisito e un difetto e un miglioramento?

Risposta : PER Requisiti è una user story essenziale per essere implementata, testata e distribuita.
Un aumento è una caratteristica aggiunta o improvvisata a quella esistente.
PER difetto è piuttosto una deviazione completa dalle storie utente previste.

Inoltre, se un difetto scopre una certa area di un requisito che non è indicato se non diversamente nella specifica, può anche essere chiamato come requisito o parte di esso.

Q # 31) Cosa fai quando il tuo sviluppatore nega di aver risolto un bug che hai segnalato?

Risposta : Un fattore importante che decide la riparazione di un difetto è la “Priorità” assegnatagli. Se il difetto è di alta priorità, uno show stopper, che blocca una funzionalità principale e viene riprodotto in modo coerente, è necessario ripararlo nella build.

Lo stesso deve essere trasmesso agli sviluppatori in modo efficace poiché insieme tester e sviluppatori contribuiscono alla qualità del prodotto da spedire.

Altri aspetti che possono aiutare a convincere lo sviluppatore a correggere un bug in un breve periodo sono la segnalazione di qualità del bug e far capire agli sviluppatori il fatto che la correzione del bug è di primaria importanza nel rilascio.

Q # 32) Cosa fai quando il tuo sviluppatore nega che ciò che hai presentato È UN ERRORE?

Risposta : Una fase più importante del ciclo di vita del difetto è 'Rifiutato', il che significa che il rapporto sull'incidente registrato non è valido. Il documento sui requisiti aziendali che stabilisce i requisiti può aiutare a comprendere il software e quindi la natura dell'incidente segnalato.

Analizza il bug ed esponi le tue scoperte sul bug allo sviluppatore e al team. Se è un difetto, non mancare mai di registrarlo. A volte i tester devono fornire un'analisi del gap e presentare la stessa agli sviluppatori. Se ciò non risolve i conflitti, dovrebbero intervenire i senior del team.

Q # 33) Cosa viene prima Test di ripetizione o test di regressione?

Risposta : Il nuovo test viene prima poiché sta rieseguendo il codice, in termini più semplici, è un'esecuzione ripetuta di passaggi predefiniti. Non deve essere necessario dopo aver corretto un codice. Ma un test di regressione serve a valutare gli effetti collaterali di un difetto risolto.

Certamente risolvere un difetto e aggiungerne un altro nel codice non è lo scopo del processo di test. Le migliori scoperte e le migliori catture dei tester sono solitamente difetti di regressione. Una build non dovrebbe mai essere rilasciata senza essere stata sottoposta a test di regressione.

Q # 34) Qual è un'alternativa al beta test?

Risposta : Il beta test si svolge presso il sito del cliente con il minimo coinvolgimento degli sviluppatori, registrando i guasti nell'ambiente di produzione reale. Se tale pratica non viene eseguita da un'azienda, un'idea più sicura può essere quella di spedire il prodotto prima ai clienti che non sono in coda per ottenere l'ultima build.

Per un paio di giorni, alcuni consulenti del servizio presso la sede del cliente possono utilizzare il software, registrare e monitorare le attività che assicurano la stabilità del rilascio nel loro ambiente, in modo che anche se un bug importante viene lasciato da risolvere può essere testato prima consegnandolo al cliente mirato. Un altro approccio è lo scambio di test dei requisiti all'interno di un team per test imparziali.

Q # 35) Quali sono gli svantaggi dell'implementazione / metodologia Agile che hai dovuto affrontare?

Risposta : Gli svantaggi sono i seguenti:

1. Gli sprint sono solitamente molto vincolati dalle scadenze.
2. La documentazione non è la priorità
3. Il passaggio tra PBI (elementi del backlog di prodotto) può essere frequente.

Q # 36) Perché è importante l'analisi dell'impatto?

Risposta : Per fare pratica basata sul rischio, è necessario eseguire un'analisi dell'impatto. In questo modo i casi di test possono essere progettati in modo che tutti i bug gravi, critici dal punto di vista del cliente, possano essere risolti in anticipo. Ci si deve occupare di un buon studio del business, delle necessità del cliente e del suo utilizzo del software.

Per esempio, il rischio più importante associato al software nel settore bancario è la sicurezza. Qualsiasi nuovo modulo aggiunto al software già esistente può essere vulnerabile. Si consiglia una buona quantità di test di sicurezza aggiungendo collegamenti appropriati, reindirizzamento e navigazione alla pagina corretta, installando il proxy se necessario.

Q # 37) Con l'aiuto di un esempio ogni test delle prestazioni, stress test e test di carico?

Risposta : Il caso migliore qui che può essere preso è un sito web live.

Test delle prestazioni viene fatto per verificare i glitch nel sistema quando sottoposti a una condizione simile a uno scenario in tempo reale. Non è necessario eseguirlo in condizioni di stress. I risultati del test delle prestazioni aiutano a stabilire se il sistema è pronto per entrare in produzione.

Per un semplice flusso di prenotazione dei biglietti, un problema di prestazioni potrebbe aver causato la lentezza. Ad esempio, alcune query che utilizzano i join sono un po 'più lente che hanno implementato clausole non necessarie o l'archiviazione dei dati in modo inappropriato nel database.

Test di stress è un tipo di test delle prestazioni che viene eseguito mettendo il software in condizioni estreme (carichi pesanti e non distribuiti, risorse di calcolo limitate, concorrenza elevata).

Se un sistema mostra determinati comportamenti come la perdita o il danneggiamento dei dati, l'utilizzo di risorse anche dopo la rimozione dello stress, l'irresponsabilità o le eccezioni non gestite, significa che non è riuscito nello stress test. A volte il risultato può essere un guasto del disco, un aumento non necessario dei conteggi GDI.

Per esempio, Se il sito Web ospitato su una macchina che sta già consumando un'enorme memoria o lo sta bombardando con richieste ripetute non deve bloccarsi o disconnettersi.

Test di carico sta osservando il comportamento del sistema aumentando costantemente il carico sul sistema fino al raggiungimento di una soglia. I modelli di carico di lavoro, le metriche e i livelli di carico sono solitamente l'input per il test di carico.

Per esempio, il tempo per recuperare la disponibilità di posti per un treno aumenta gradualmente con l'avvicinarsi del momento della prenotazione della quota Tatkal poiché il numero di utenti che hanno effettuato l'accesso al sistema aumenta con il tempo di prenotazione Tatkal che si avvicina alle 10:00 o alle 11:00.

Q # 38) Qual è stata una delle tue maggiori sfide durante i test di regressione?

Risposta : Ci possono essere varie sfide durante l'esecuzione dei test di regressione.

• Rieseguire ripetutamente i test potrebbe non essere così entusiasmante per i tester.
• Richiede tempo, poiché a volte tali test richiedono un pensiero fuori dagli schemi.
• Valore aziendale compromesso.
• Una selezione impropria dei casi di test di regressione potrebbe saltare un importante difetto di regressione da trovare.
• La riproduzione del difetto in produzione diventa quindi incoerente.
• Ampia suite da eseguire.

Q # 39) Se ti viene chiesto di documentare scenari di test, casi di test, piani di test, strategia di test, con cosa inizierai e in quale sequenza seguirà il resto?

Risposta : La sequenza sarà Test Strategy, Test Plan, Test Scenarios e infine Test case.

Q # 40) Cosa succede se manco di documentare uno qualsiasi dei precedenti? Supponiamo che mi manchi la documentazione del piano di test, quali saranno le conseguenze?

Risposta : Se perdiamo la documentazione del piano di test, ci sarà un vuoto per lo scopo di testare il suo approccio obiettivo e l'enfasi sul test. Sarà quindi difficile determinare le caratteristiche da testare, le tecniche per testare, superare o fallire i criteri e, in ultima analisi, un grave rischio associato al test.

Q # 41) Come inizieresti a testare la build che hai ottenuto di recente: c'è qualche approccio che segui, ad es. iniziare prima il test del fumo, quindi il test di sanità mentale?

Risposta : Test del fumo> Test di integrità> Test esplorativi> Test di funzionalità> Test di regressione e convalida del prodotto finale.

Q # 42) Spiega il formato della segnalazione di bug che hai seguito?

Risposta :

Una segnalazione di bug dovrebbe contenere le seguenti informazioni:

• Bug Id
• Mappatura su requisito / miglioramento / bug esistente
• Riepilogo / titolo dei bug
• Una versione del prodotto
• Priorità
• Configurazione (specifiche di sistema)
• Prerequisiti
• Passi
• Risultato previsto
• Risultato effettivo
• Registri. Istantanee, clip video
• Stato
• Altre osservazioni

Q # 43) Come si selezionano i casi di test di regressione o si forma la suite di test di regressione?

Risposta : Sì. Questo è un risultato dell'analisi dell'impatto. Si tratta di una semplice mappatura delle funzionalità utilizzate o a cui si accede nelle diverse aree che si stanno testando, della sua integrazione con altre funzionalità e in tutto il sistema end-to-end o test di flusso.

È inoltre possibile rilevare i difetti precedentemente archiviati per la stessa funzionalità nelle build precedenti. Idealmente, un difetto dovrebbe essere testato di regressione utilizzando almeno cinque diversi casi di test che utilizzano la funzionalità.

Q # 44) Puoi venire con un esempio dei seguenti difetti

• Difetto di gravità alta a bassa priorità
• Difetto ad alta priorità e bassa gravità

Risposta : Un difetto che causa l'arresto anomalo dell'applicazione quando viene riprodotto solo a un determinato timestamp su un particolare sistema operativo può essere un difetto di alta gravità e di bassa priorità.

Un difetto presentato contro una vista che non si apre con un doppio clic ma si apre con un clic destro può essere un difetto di alta priorità e di bassa gravità.

Q # 45) Scrivere un test case efficace per verificare se un determinato articolo è un white paper?

Risposta: Se il colore dell'inchiostro di origine con cui si scrive su carta bianca rimane lo stesso, la carta è bianca. Ad esempio, se scrivi su una carta bianca con inchiostro rosso, il colore dell'inchiostro rimane rosso nella penna e appare rosso anche sulla carta.

Nota: Ci sono molte altre risposte a questa domanda. Puoi arrivare a pensare a una risposta così valida con la logica sottostante.

Q # 46) Cos'è il test Charter?

Risposta: Un test di sessione eseguito in base agli obiettivi e agli ordini del giorno elencati in una carta prima di iniziare il test è noto come test della carta.

Il test qui viene eseguito in un intervallo di tempo fisso con un focus minore sulla documentazione e più focus sul solo test. È una variante diversa del test esplorativo in cui gli ingegneri di test verificano il software in un lasso di tempo ( Per esempio, solo 2 ore) sulla base di alcune euristiche sviluppate.

Q # 47) Qual è il tuo approccio quando hai una release ad alta priorità da consegnare in un tempo molto breve?

Risposta: In questi casi, un piano ben ponderato può essere utile.

È possibile eseguire quanto segue per assistere i test in uno scenario di carenza di tempo: -

• Utilizzo degli script di automazione aggiornati esistenti per eseguire i test di regressione.
• Testare scenari basati sul flusso end to end.
• Esecuzione di casi di test ad alta priorità e se il tempo lo consente, passare ai casi di priorità inferiore.
• Ri-testare i bug ad alta priorità archiviati nelle versioni precedenti.
• Test rapidi del software
• Agli sviluppatori può essere chiesto di eseguire test unitari per ottenere una maggiore copertura nei test.

Q # 48) Scrivere casi di test su qualsiasi dispositivo / oggetto presente intorno (Esempio: una sedia)?

Risposta: Un consiglio qui sarebbe: Inizia sempre con la raccolta dei requisiti. Mostra la tua maturità verso il ciclo di vita dello sviluppo del software. Sentiti libero di fare domande dopo aver selezionato l'oggetto.

In questo caso:-

• Che tipo di sedia è? Sedia da ufficio, tavolo da studio, poltrona da divano, tavolo da pranzo, sedia comfort?
• Che materiale viene utilizzato per realizzare la sedia: legno, acciaio, plastica, tappezzeria?
• Richiedi le dimensioni (altezza, peso in base al tipo di sedia).
• Richiedi disponibilità. E in base a ciò inizia a redigere i tuoi casi.

I casi di test sarebbero diversi per ogni tipo di sedia, che è meglio lasciare per la tua capacità di pensare ( Per esempio, scopo della sedia, dimensioni in base al tipo di sedia, portatile-non potabile, leggera, opzioni di acquisto).

Per ogni sedia, a Il caso di test delle prestazioni può essere: per ricavare la resistenza alla trazione o la massima capacità di carico.

Q # 49) Tutto può essere automatizzato?

Risposta: - In una certa misura sì. Ma gli strumenti di automazione, come altri software, hanno i suoi limiti. Inoltre, il software in test o l'applicazione in test continueranno a essere aggiornati.

Quindi non vi è alcuna garanzia che il test del software possa essere eseguito senza intervento manuale. Dopotutto, uno strumento è intelligente quanto il tester. È solo un software che sta testando un altro software. È il codice / gli script / le librerie che devono essere sufficientemente intelligenti per testare e trovare i difetti.

Conclusione

Spero che questo esercizio ti aiuti a riscaldarti con alcune domande e ti dia un ottimo spunto per le tue interviste e raffini la tua fiducia mentre rispondi alle domande. Inoltre, ci possono essere altre domande basate su scenari, quelle che possono emergere dal tuo curriculum / profilo.

Quindi, è sempre consigliabile praticare una finta intervista con auto pre-mano, in modo che l'intervista risulti essere una situazione vantaggiosa per entrambi sia per l'intervistatore che per il candidato. Ricorda che un analista della qualità è più di un ingegnere di test, il cui feedback è importante non solo per la qualità del prodotto, ma anche per il processo seguito per testare il software.

Grazie e in bocca al lupo per le interviste!

Lettura consigliata

• Domande e risposte dell'intervista
• Oltre 25 domande e risposte per i colloqui di ADO.NET più popolari
• 25 migliori domande e risposte per l'intervista al test agile
• Domande dell'intervista a Spock con risposte (le più popolari)
• Domande e risposte al colloquio di prova ETL
• 20 domande e risposte per l'intervista TestNG più popolari
• Top 30+ domande e risposte popolari per l'intervista al cetriolo
• Le 50 domande e risposte dell'intervista CCNA più popolari