40+ Întrebări și răspunsuri la interviuri populare de testare a analistului QA (LISTA 2021)

40 popular test qa analyst interview questions

Întrebări și răspunsuri la cele mai frecvente întrebări:

În timp ce decideți cariera în care doriți să vă aflați, factorul decisiv nu este doar cel pe care credeți că se poate bucura să lucreze.

Pentru a fi în această categorie este nevoie de o mulțime de abilități, înțelegerea responsabilităților, precum și a sarcinilor necesare pentru cariera pe care ați ales-o. Același lucru este valabil în timp ce alegeți o carieră ca analist QA. Nu necesită doar să fii un tester bun, un cursant rapid, un gânditor extraordinar, ci necesită și un rezolvator de probleme complex.

Deși calitățile menționate mai sus nu sunt atinse instantaneu, evident necesită experiență și zile de muncă grea.

Acest articol va acoperi fiecare aspect ale cărui cunoștințe sunt obligatorii pentru a fi analist de control al calității. Cele mai frecvente întrebări și răspunsuri la interviu pentru QA Test Analyst incluse aici vă vor oferi o idee clară despre pregătirea interviului.

Întrebări populare despre interviul analistului de testare a calității

Q # 1) Care sunt responsabilitățile unui analist QA?

Răspuns: QA Analyst este cel care se asigură că au fost luate toate măsurile posibile pentru testarea fiecărei caracteristici a soluției software atât funcțional, cât și tehnic.

Responsabilitățile majore ale QA Analyst pot fi înrolate după cum urmează:

• Executați și gestionați toate activitățile pentru a îndeplini obiectivele planului de testare.
• Alegeți procesele de înaltă calitate pentru a dezvolta produsul.
• Ar trebui să fie capabil să analizeze cerințele și să documenteze procedurile.
• Documentați și verificați din nou toate defectele. Setați prioritatea și severitatea defectelor.
• Aceștia ar trebui să poată crea, documenta și întreține cazuri de testare.
• Analiza rezultatelor testelor.

Q # 2) Care este înțelegerea dvs. cu privire la un plan de testare?

Răspuns: Când ai o idee clară despre ce, când, cum și cine, atunci lucrurile devin mai ușoare. Același lucru este valabil și în cazul testării software, în care planul de testare este un document care constă din domeniul de aplicare, abordarea, resursele și schița proiectului de testare, precum și activitățile de urmărire a progresului proiectului.

Planul de testare este o înregistrare a proceselor care includ:

• Sarcini de testare
• Mediul de testare
• Tehnici de proiectare
• Criterii de intrare și ieșire
• Orice riscuri etc.

Q # 3) Înscrieți prioritatea sarcinilor de testare definite de echipa QA în dezvoltarea produsului.

Răspuns: Prioritatea sarcinilor de testare este definită după cum urmează:

• Se pregătește un plan de testare format din schița și sfera proiectului de testare.
• Cazurile de testare sunt pregătite pentru a acoperi toate funcționalitățile majore și minore cu datele necesare testării.
• Executarea cazurilor de testare în conformitate cu funcționalitățile implementate cu versiunile viitoare ale proiectului de testare în ciclul de testare.
• Raportarea defectelor cu re-verificare, precum și urmărirea progresului acesteia.
• Pregătirea rezumatului raportului de execuție a testului.

Q # 4) Înscrieți câteva dintre provocările cheie cu care se confruntă în timpul efectuării testării software.

Răspuns: După cum spunem că testarea completă nu poate fi realizată niciodată, există mai multe provocări implicate în aceasta. Fie că este una mică sau complicată, există unele provocări cu care se confruntă în timpul efectuării testării software a oricărui proiect.

Înscrise mai jos sunt câteva provocări cheie:

• Lipsa unui tester calificat care se confruntă, de obicei, cu problema conștientizării subiectului, precum și cu lipsa unei bune cunoștințe despre afacerea clientului.
• Timpul este, de asemenea, considerat factorul, deoarece de obicei testerii se concentrează în principal pe acoperirea sarcinilor, mai degrabă decât pe acoperirea testelor cu teste de calitate, atunci când există o listă imensă de sarcini de finalizat.
• Pentru a decide care caz de testare trebuie executat mai întâi și cu prioritate. Acest lucru se realizează de obicei prin experiența muncii.
• O înțelegere adecvată a cerințelor care pot duce la zero la toate eforturile de testare, dacă cerința este înțeleasă greșit.
• Indisponibilitatea celor mai bune instrumente necesare pentru a finaliza testarea cu mai puțin timp și mai multă eficacitate.
• Gestionarea relației dintre testeri și dezvoltatori cu abilități bune de comunicare și analiză.

Q # 5) Definiți testarea cazului de utilizare.

Răspuns: Testarea cazurilor de utilizare poate fi definită ca tehnica funcțională de testare a cutiei negre care surprinde seria de interacțiuni care au avut loc între „actori” și „sistem”. Aici, „Actorii” sunt reprezentați de utilizatori și de interacțiunile acestora.

Caracteristicile testării cazului de utilizare sunt prezentate mai jos:

• Cerințele funcționale ale proiectului sunt organizate.
• Înregistrează calea sau scenariile de la început până la sfârșit.
• Poate acoperi defecte de integrare, adică defectele care au apărut ca urmare a interacțiunii dintre diferite componente.
• Descrie fluxurile principale, precum și fluxul excepțional al evenimentelor.
• Orice condiții prealabile necesare pentru ca cazul de utilizare să funcționeze ar trebui specificate mai devreme.

Q # 6) Definiți strategia de testare.

Răspuns: Un set de linii directoare sau abordări de testare care sunt de obicei realizate de managerul de proiect pentru a determina proiectarea testului și abordarea generală de testare este definit ca Strategie de testare. Acesta se găsește ca o mică secțiune a planului de testare și este utilizat de mai multe proiecte.

Se urmăresc diferite abordări de testare pe baza factorilor precum natura și domeniul produsului, riscul de eșec al produsului, expertiza în lucrul cu instrumentele propuse etc.

Aceste abordări sunt clasificate în continuare după cum urmează:

• Abordare proactivă , în cazul în care abordarea proiectelor de testare începe înainte de crearea construcției. Astfel, ajută la găsirea și remedierea erorilor înainte de construire.
• Abordare reactivă , unde abordarea de testare este începută după finalizarea proiectării și codificării testelor.

Q # 7) Explicați diferența dintre controlul calității și asigurarea calității.

Răspuns: 'Control de calitate' și 'Asigurarea calității' sunt cei doi termeni principali utilizați pentru orice proiect sau produs de testare. De obicei, testerii, care sunt noi în acest domeniu, nu înțeleg diferența reală dintre cele două.

Să înțelegem diferența cu ajutorul tabelului de mai jos.

Q # 8) Potrivit dvs., când este momentul potrivit pentru a începe QA într-un proiect?

Răspuns: Conform Ciclului de viață al dezvoltării software-ului (SDLC), faza de testare se execută după finalizarea fazei „Implementare și codificare”. Dar, în scenariul de astăzi, pentru a obține cele mai bune rezultate, este necesar să începeți QA-ul proiectului sau al produsului la începutul proiectului.

Urmarea acestei abordări va duce la avantajele majore date mai jos:

• Planificarea timpurie a proceselor pentru a satisface așteptările de calitate ale clienților.
• Comunicare bună și sănătoasă între echipe.
• Oferă o cantitate suficientă de timp necesară pentru configurarea mediului de testare.
• Permite revizuirea timpurie și aprobarea planurilor de testare.

Q # 9) Diferențiați procesele de verificare și validare.

Răspuns: Procesele de verificare și validare sunt de obicei determinate de două întrebări celebre, adică „ Construim sistemul nu? ” și „Construim sistemul potrivit?” .

Să vedem cealaltă diferență dintre aceste două procese în tabelul de mai jos:

Q # 10) Explicați beneficiile testării distructive.

Răspuns: Testarea distructivă este definită ca forma de testare care este efectuată de echipa de testare pentru a determina punctul de eșec al produsului sub diferite sarcini, adică pentru a evalua performanța structurală a aplicației pentru a determina rezistența, rezistența, duritatea sau, prin urmare, robustețea.

Mai jos sunt prezentate avantajele testării distructive:

• Punctul slab al designului aplicației este determinat.
• Determinați durata de viață a aplicației.
• Ajută la reducerea costurilor și a eșecului.

Q # 11) În ce este diferit Retestarea de testarea de regresie?

Răspuns: Există mai multe diferențe între retestare și testarea de regresie.

Acest lucru poate fi ușor de înțeles din tabelul de mai jos:

Q # 12) Ce știți despre testarea bazată pe date?

Răspuns: Este foarte clar pentru fiecare tester de automatizare că scripturile de testare a automatizării acoperă numai zona aplicației care urmează să fie testată cu o secvență înregistrată de acțiuni ale utilizatorului. În mod normal, aceste acțiuni nu produc nicio eroare deoarece doar datele de intrare sunt luate în condițiile pe care le-am introdus în timpul înregistrării.

Testarea bazată pe date apare aici, unde vrem ca aplicația să funcționeze conform așteptărilor pentru orice tip de valori de intrare. În acest scop, datele necesare pentru testarea bazată pe date nu sunt codificate, dar scripturile de testare își preluează datele din surse de date, cum ar fi fișiere CSV, surse ODBC etc.

Pentru a rezuma, testarea bazată pe date efectuează următoarele acțiuni în buclă:

returnând o matrice de șiruri în java

• Preia datele de testare de intrare din stocare.
• Date introduse în aplicație pentru a efectua acțiuni.
• Verificați rezultatele reale cu cele așteptate.
• Repetați din nou aceiași pași cu noile date de test de intrare.

Q # 13) Ce este matricea de trasabilitate? Este necesar pentru fiecare proiect?

Răspuns: Matricea de trasabilitate în orice proiect este mijlocul de urmărire a progresului proiectului în ceea ce privește implementarea de noi funcționalități, îmbunătățirea funcționalităților existente etc. Prin intermediul unei matrice de trasabilitate, puteți urmări întotdeauna progresul proiectului cu fiecare aspect menținut conform data.

Matricea de trasabilitate a cerințelor constă din parametrii menționați mai jos, care sunt de fapt conform documentului cu specificațiile cerințelor.

Parametrii matricei de trasabilitate a cerințelor includ:

• Fiecare secțiune a documentului de cerință este un punct care trebuie acoperit în RTM (Matricea de trasabilitate a cerințelor).
• Titlul fiecărui punct este titlul fiecărei secțiuni din specificația cerințelor.
• Corespunzător fiecărui punct, sunt menționate ID-urile cazului de testare care sunt scrise pentru acea secțiune specială.
• BUG / ID funcție nouă este, de asemenea, menționat în fiecare secțiune.
• Cel mai important punct este că se menține și urmărirea caracteristicii în care a fost implementată construcția proiectului și caracteristica sa.
• Un alt parametru include dacă secțiunea este complet testată sau este încă în stare de testare.

Q # 14) Descrieți beneficiile testării agile.

Răspuns: Fiind un tester, accentul devine livrarea produsului de calitate în mai puțin timp prin înțelegerea cerinței utilizatorului final și, cel mai important, fără defecte din partea utilizatorului final. Aici, testarea Agile apare în imagine, care urmează principiul dezvoltării software-ului agil și validează rapid cerințele clientului.

Mai jos sunt menționate beneficiile testării Agile:

• O echipă agilă multifuncțională este inclusă în testare, care la rândul său oferă rezultatele la intervale frecvente.
• Economisește mult timp și bani.
• Include mai puțină documentație și feedback din când în când de la utilizatorul final.
• Nu numai testerul, ci întreaga echipă, inclusiv managerul, clientul și dezvoltatorul, sunt implicați în comunicarea față în față.
• Ca urmare a întâlnirilor zilnice, problemele pot fi bine stabilite în avans.
• Creșterea productivității echipei și o mai bună înțelegere a aspectelor tehnice ale proiectului.

Q # 15) Ce este testarea negativă?

Răspuns: Testarea negativă este metoda de a asigura menținerea stabilității unui produs sau a unei aplicații sau a spune că nu eșuează atunci când se oferă date neașteptate. Scopul principal al acestei forme de testare validează aplicația împotriva oricăror date de intrare nevalide.

Această formă de testare este, de asemenea, cunoscută sub numele de „Testarea eșecului” sau „testarea căii de eroare” și scopul său principal este de a verifica fiabilitatea funcției aplicației în scenarii negative. De asemenea, expune slăbiciunea software-ului, identifică defectele și oferă o idee clară despre corupția datelor.

Q # 16) Diferențiați testarea ad-hoc și testarea exploratorie?

Răspuns: Există mai multe diferențe între testarea ad-hoc și testarea exploratorie.

Să vedem diferențele din tabelul de mai jos:

Î. # 17) De ce este preferată testarea automatizării decât testarea manuală?

Răspuns: Ei bine, atât testarea automatizării, cât și testarea manuală își au importanța și existența în lumea testării.

Prezentate mai jos sunt câteva aspecte importante datorită cărora testarea automatizării este preferată față de testarea manuală:

• Același script de testare poate fi utilizat de fiecare dată pentru a rula testul, astfel testarea automatizării este considerată cea mai fiabilă și mai eficientă.
• Cel mai preferat în caz de testare de regresie și execuție repetată.
• Testarea automatizării este considerată a fi una rentabilă în cazul execuției pe termen lung și asigură astfel o calitate mai bună a software-ului.
• Scripturile de testare sunt reutilizabile, rapide și toată lumea poate vedea rezultatele.
• Instrumentele utilizate pentru testarea automatizării sunt mai rapide și mai fiabile în comparație cu abordarea manuală.

Deși, alți factori determină faptul că testarea automatizării este preferată față de testarea manuală. Cele menționate mai sus sunt factorii majori.

Î # 18) Ce înțelegeți prin „Eficiența testului” și „Eficiența testului”?

Răspuns: Eficiența testului poate fi definit ca calculând numărul de resurse și codul de test consumat pentru a efectua sau a spune că executați o anumită funcție. De asemenea, determină numărul de resurse utilizate în crearea produselor software.

Acest lucru poate fi determinat de formula:

Eficiența testului = (Numărul de defecte rezolvate / numărul total de defecte depuse) * 100

Eficacitatea testului poate fi definit ca măsura de evaluare a mediului de testare și a efectului acestuia asupra aplicației software. Aici răspunsul clienților este evaluat atunci când cerința cererii este îndeplinită.

Acest lucru poate fi determinat de formula:

Eficacitatea testului = (Numărul de defecte găsite / Numărul de cazuri de testare executate)

Q # 19) Explicați procesul de adaptare a proiectelor.

Răspuns: Adaptarea proiectului este un proces consecvent și continuu, care asigură că performanța proiectului este corectă și este în conformitate cu cerințele afacerii. Întregul proces include revizuirea și modificarea datelor proiectului conform nevoilor operaționale actuale ale organizației.

Procesul de revizuire se face la nivel organizațional, dar implementarea planurilor de adaptare se face la nivelul proiectului. Scopul principal și cerințele organizației, precum și relațiile cu clienții și utilizatorii, sunt cei doi factori majori care ar trebui luați în considerare în proces.

Câteva aspecte conform obiectivelor organizaționale în cadrul procesului de adaptare sunt:

• Abordarea proiectului
• Strategii
• Controale și procese implicate
• Roluri si responsabilitati

Q # 20) Cum diferențiați între Prioritatea și Severitatea defectului în cadrul proiectului?

Răspuns: Atât „Prioritate”, cât și „Severitate” sunt atribuite bug-ului pentru clasificarea problemelor / bug-urilor pentru ordinea în care trebuie luate pentru remedierea acestora. Acestea se bazează pe diverși factori.

Să înțelegem mai multe împreună cu diferențele lor în tabelul de mai jos:

Q # 21) De ce este necesar să se facă testarea performanței pentru orice aplicație?

Răspuns: Într-un limbaj simplu, testarea performanței se face pentru a determina comportamentul și răspunsul unei aplicații în diferite situații. Acest lucru ajută la colectarea de informații cu privire la stabilitatea aplicației, scalabilitatea, viteza etc.

Motivele pentru efectuarea testării performanței pot fi înțelese din punctele de mai jos:

• Determină timpul de răspuns și performanța unei componente a aplicației sub sarcina de lucru.
• Se calculează timpul de răspuns al activității utilizatorului.
• Necesită programatori experimentați cu un limbaj tehnic extins.
• Determină comportamentul aplicației sub sarcină, adică atunci când numărul utilizatorului crește instantaneu.

Q # 22) Ce este testarea bazată pe specificații?

Răspuns: După cum definește și numele, testarea bazată pe specificații se face pe baza specificațiilor cerințelor aplicației, unde specificațiile funcționale servesc ca bază a testelor efectuate.

Această formă de testare este aceeași cu „Testarea cutiei negre” în care utilizatorul introduce mai multe date și apoi se observă ieșirea. Este adecvat la toate nivelurile de testare cu specificații și plan de testare.

Q # 23) Explicați CMMI.

Răspuns: CMMI înseamnă Integrarea modelului de maturitate a capacității. Acest model a fost dezvoltat de Institutul de Inginerie Software (SEI). Se bazează pe principiul conform căruia procesele implicate în gestionarea și dezvoltarea unui produs sau sistem determină calitatea.

De asemenea, oferă orientări pentru îmbunătățirea procesului pentru produs sau chiar întreaga organizație.

CMMI este împărțit în 5 niveluri, după cum se enumeră mai jos:

• Nivelul 1: Iniţială
• Nivelul 2: Gestionate
• Nivelul 3: Definit
• Nivelul 4: Gestionat cantitativ
• Nivelul 5: Optimizat

Q # 24) Explicați avantajele implementării CMMI.

Răspuns: Există mai multe avantaje în implementarea CMMI.

Acestea sunt enumerate după cum urmează:

• Oferă acoperire detaliată și raportare a ciclului de viață al produsului și, astfel, ajută la îmbunătățirea procesului.
• Standardele existente ale organizației, procesele și procedurile acestora sunt îmbunătățite ca parte a implementării CMMI.
• Ca urmare a implementării CMMI, există o creștere a livrării la timp, precum și a satisfacției clienților.
• De asemenea, conduce la o gestionare eficientă și la economii sporite de costuri, deoarece există detectarea timpurie a erorilor.

Q # 25) Înscrieți câteva instrumente de testare a automatizării.

Răspuns: Unele dintre instrumentele de testare a automatizării sunt prezentate mai jos:

• Seleniu
• apă
• Moara de vant
• SoapUI
• Telurul

Q # 26) Putem face teste de regresie în testarea unitară?

Răspuns: Categoric. Testarea de regresie este de a testa defectul nedorit care ar fi putut fi introdus în cod ca efect secundar al remedierii altor defecte. Testarea unitară este execuția de test a executării unei mici părți de cod independente și individuale.

Testarea de regresie poate fi făcută la orice nivel, de la testarea unității până la testarea integrării până la testarea finală a acceptării. Testarea de regresie este testarea bazată pe perspectivă, în timp ce testarea unității este abordarea nivelului (de jos în sus, de sus în jos).

Q # 27) Care este diferența dintre testarea fumului și testarea sănătății?

Răspuns:

• Testarea fumului este testarea vechilor caracteristici proeminente sau a caracteristicilor existente ale construcției, în timp ce testarea Sanity este validarea modulelor nou adăugate, defecte remediate în construcție.
• Testarea fumului are loc mai întâi și apoi este urmată de testarea Sanity.
• Testarea fumului acoperă testarea funcționalităților critice oferite de software, astfel încât să se extindă pe întregul software. Testarea sănătății, pe de altă parte, este restrânsă doar la modulele adăugate recent și este testată în profunzime.

Q # 28) Care sunt activitățile dvs. zilnice ca tester manual în biroul dvs.?

Manual: Primul lucru pe care îl verific în sistemul meu este să reîmprospătez tabloul de bord pentru starea cerințelor / îmbunătățirilor sau erorilor din iterația curentă. Este urmat de apeluri scrum zilnice și sesiuni de raportare, discuții și brainstorming pentru definirea cu scenarii de testare și cazuri de testare.

Aceste cazuri sunt apoi executate după refacerea acestuia conform revizuirii. Legătura cu clienții pentru cerințe nefuncționale este, de asemenea, una dintre activitățile majore pe placa mea.

Q # 29) Care sunt activitățile dvs. zilnice ca membru al testerului de automatizare din biroul dvs.?

Automatizare: Ziua mea începe cu o întâlnire de stare zilnică care discută rezultatele automatizării de ieri, în cazul în care am tras un lot de cazuri de testare pe noua versiune.

Ciclul de execuție poate fi numit Health Check, pentru a vedea cât de sănătoasă este construcția.

Este urmat de raportarea defectelor bazate pe eșecurile scriptului, modificări ale designului în funcționalitate; mențineți scripturile / bibliotecile sau funcțiile, automatizați și faceți check-in într-un nou script pentru noile cerințe și, dacă este necesar, o nouă funcție în biblioteca de funcții.

Uneori, scripturile de testare trebuie să fie reexecutate individual pentru a găsi defecte de regresie prin automatizare și să le adăugați și la suita de testare.

Q # 30) Cum diferențiați între o cerință și un defect și o îmbunătățire?

Răspuns : LA cerinţă este o poveste a utilizatorului care este esențială pentru a fi implementată, testată și livrată.
Un sporire este o caracteristică adăugată sau improvizată la cea existentă.
LA defect este mai degrabă o abatere completă de la poveștile așteptate ale utilizatorilor.

De asemenea, dacă un defect descoperă o anumită zonă a unei cerințe care nu este menționată, cu excepția cazului în care se specifică altfel în caietul de sarcini, poate fi numită și ca o cerință sau ca parte a acesteia.

Q # 31) Ce faci atunci când dezvoltatorul tău neagă remedierea unei erori pe care ai depus-o?

Răspuns : Un factor important care decide remedierea unui defect este „Prioritatea” atribuită acestuia. Dacă defectul este de mare prioritate, un opritor de spectacol, care blochează o funcționalitate majoră și este reprodus în mod constant, atunci este necesar să fie reparat în construcție.

Același lucru trebuie transmis în mod eficient dezvoltatorilor, întrucât împreună testerii și dezvoltatorii contribuie la calitatea produsului care urmează să fie livrat.

Alte aspecte care pot ajuta la convingerea dezvoltatorului să remedieze un bug într-o perioadă scurtă de timp sunt raportarea de calitate a bug-ului și îi face pe dezvoltatori să înțeleagă faptul că remedierea bug-ului este de primă importanță în versiune.

Q # 32) Ce faci atunci când dezvoltatorul tău neagă că ceea ce ai depus este un bug?

Răspuns : O fază importantă a ciclului de viață al defectului este „Respins”, ceea ce înseamnă că raportul incidentului înregistrat nu este unul valid. Documentul privind cerințele comerciale care prevede cerințele poate ajuta la înțelegerea software-ului și, prin urmare, la natura incidentului raportat.

Analizați eroarea și expuneți descoperirile dvs. asupra dezvoltatorului și echipei. Dacă este un defect, nu reușiți niciodată să-l înregistrați. Uneori testerii trebuie să furnizeze o analiză Gap și să le prezinte dezvoltatorilor. Dacă acest lucru nu rezolvă conflictele, atunci ar trebui să participe persoanele în vârstă din echipă.

Q # 33) Ce vine mai întâi Re-testarea sau testarea de regresie?

Răspuns : Re-testarea este pe primul loc, deoarece reexecută codul, în termeni mai simpli, este o execuție repetată a pașilor predefiniți. Nu trebuie să fie necesar după remedierea unui cod. Dar un test de regresie este de a evalua efectele secundare ale unui defect rezolvat.

Desigur, rezolvarea unui defect și adăugarea unui altul în cod nu este scopul procesului de testare. Cele mai bune descoperiri și cele mai bune capturi ale testerilor sunt de obicei defecte de regresie. O construcție nu ar trebui să fie lansată niciodată fără a fi testată regresia.

Q # 34) Care este o alternativă la testarea beta?

Răspuns : Testarea beta se desfășoară la site-ul clientului cu cea mai mică implicare a dezvoltatorilor, înregistrând eșecurile în mediul real de producție. Dacă o astfel de practică nu este realizată de o firmă, atunci o idee mai sigură poate fi aceea de a expedia produsul mai întâi către clienți, cei care nu sunt în coadă pentru a obține cea mai recentă versiune.

Timp de câteva zile, anumiți consultanți de service de la sediul clienților pot utiliza software-ul, pot înregistra și monitoriza activitățile care asigură stabilitatea lansării în mediul lor, astfel încât, chiar dacă un bug major este lăsat de rezolvat, poate fi testat înainte livrarea acestuia către clientul vizat. O altă abordare este testarea schimbată a cerințelor în cadrul unei echipe pentru testarea imparțială.

Q # 35) Care sunt dezavantajele implementării / metodologiei Agile cu care v-ați confruntat?

Răspuns : Dezavantajele sunt următoarele:

1. Sprinturile sunt de obicei foarte limitate.
2. Documentarea nu este prioritatea
3. Comutarea între PBI-uri (articole din restante de produse) poate fi frecventă.

Q # 36) De ce este importantă analiza impactului?

Răspuns : Pentru a practica bazat pe risc, trebuie făcută analiza impactului. Procedând astfel, cazurile de testare pot fi proiectate astfel încât toate erorile severe, critice din punctul de vedere al clientului, să poată fi rezolvate înainte de timp. Un bun studiu al afacerii, al nevoilor clientului și al utilizării de către acesta a software-ului trebuie să fie îngrijit.

De exemplu, cel mai important risc asociat software-ului din domeniul bancar este Securitatea. Orice formular nou adăugat la software-ul deja existent poate fi vulnerabil. Se recomandă o cantitate bună de testare a securității prin adăugarea de link-uri adecvate, redirecționare și navigare către pagina corespunzătoare, instalarea proxy-ului, dacă este necesar.

Q # 37) Cu ajutorul unui exemplu, fiecare test de performanță, test de stres și test de sarcină?

Răspuns : Cel mai bun caz aici care poate fi luat este un site web live.

Test de performanta se face pentru a verifica erorile din sistem atunci când sunt supuse unei condiții similare unui scenariu în timp real. Nu este necesar să se efectueze în condiții de stres. Rezultatele testării performanței ajută la stabilirea dacă sistemul este gata să intre în producție.

Pentru un flux simplu de rezervare a biletelor, o problemă de performanță poate fi cauzată de încetineală. De exemplu, unele interogări care utilizează îmbinări sunt puțin mai lente, care au implementat clauză sau stocare inutile de date în mod necorespunzător în baza de date.

Testare stresanta este un tip de testare a performanței care se realizează prin punerea software-ului în condiții extreme (sarcini grele și nedistribuite, resurse de calcul limitate, concurență ridicată).

Dacă un sistem prezintă un anumit comportament, cum ar fi datele pierdute sau corupte, resurse utilizate chiar și după eliminarea stresului, iresponsabilitate sau excepții necorespunzătoare, înseamnă că eșuează în testarea stresului. Uneori eșecul discului, o creștere inutilă a numărului GDI poate fi, de asemenea, rezultatul.

De exemplu, Dacă site-ul găzduit pe o mașină care consumă deja o memorie uriașă sau îl bombardează cu cereri repetate nu ar trebui să vă blocheze sau să vă deconecteze.

Testarea sarcinii observă comportamentul sistemului în timp ce crește constant sarcina pe sistem până la atingerea unui prag. Modelele de sarcină de lucru, valorile și nivelurile de încărcare sunt de obicei elementele de intrare pentru testarea sarcinii.

De exemplu, timpul de preluare a disponibilității locurilor pentru un tren crește treptat când timpul de rezervare a cotei Tatkal se apropie, deoarece numărul de utilizatori conectați atunci la sistem crește cu timpul de rezervare Tatkal aproape de 10 dimineața sau 11 dimineața.

Q # 38) Care a fost una dintre cele mai mari provocări ale dvs. în timp ce efectuați testarea de regresie?

Răspuns : Pot exista diverse provocări în timpul efectuării testelor de regresie.

• Reexecutarea testelor în mod repetat s-ar putea să nu devină atât de interesantă pentru testeri.
• Consumatoare de timp, deoarece uneori astfel de testări necesită gândire.
• Valoare comercială compromisă.
• Selectarea necorespunzătoare a cazurilor de test de regresie ar putea sări peste un defect major de regresie care să fie găsit.
• Reproducerea defectului la producție devine, prin urmare, inconsecventă.
• Suită mare de executat.

Q # 39) Dacă vi se cere să documentați scenarii de testare, cazuri de testare, planuri de testare, strategie de testare, cu ce veți începe și în ce ordine vor urma restul?

Răspuns : Secvența va fi Strategia de testare, Planul de testare, Scenariile de testare și, în final, Testarea cazurilor.

Q # 40) Ce se întâmplă dacă îmi lipsește documentarea oricăruia dintre cele de mai sus? Să spunem că îmi lipsește documentarea planului de testare care vor fi consecințele?

Răspuns : Dacă pierdem documentarea planului de testare, va exista un gol pentru scopul testării abordării sale obiective și a accentului pe testare. Atunci va fi dificil să se determine caracteristicile care urmează să fie testate, tehnicile de testare, promovarea sau eșecul criteriilor și, în cele din urmă, un risc major asociat testării.

Q # 41) Cum ați începe să testați versiunea pe care ați obținut-o recent: există vreo abordare pe care o urmați de ex. mai întâi începeți testarea fumului, apoi testarea sănătății?

Răspuns : Testarea fumului> Testarea sănătății> Testarea exploratorie> Testarea funcționalității> Testarea regresiei și validarea produsului final.

Q # 42) Explicați formatul Raportului de erori pe care l-ați urmat?

Răspuns :

Un raport de erori ar trebui să conțină următoarele informații:

• Id bug
• Asocierea la cerință / îmbunătățire / eroare existentă
• Rezumat bug / titlu
• O versiune a produsului
• Prioritate
• Configurare (specificații de sistem)
• Cerințe prealabile
• Pași
• Rezultat așteptat
• Rezultatul real
• Jurnale. Instantanee, clipuri video
• stare
• Alte observații

Q # 43) Cum selectați cazurile de test de regresie sau formați suita de test de regresie?

Răspuns : Da. Acesta este un rezultat al analizei de impact. Este o cartografiere simplă a caracteristicilor utilizate sau accesate în diferite domenii pe care le testați, integrarea acesteia cu alte caracteristici și ca test de capăt la capăt sau de flux al unui sistem.

De asemenea, puteți prelua defecte înregistrate anterior pentru aceeași funcționalitate în versiunile anterioare. În mod ideal, un defect ar trebui testat prin regresie utilizând cel puțin cinci cazuri de testare diferite care utilizează funcționalitatea.

Q # 44) Puteți veni cu un exemplu al următoarelor defecte

• Defect de severitate ridicată cu prioritate redusă
• Prioritate ridicată și defect de severitate scăzută

Răspuns : Un defect care blochează aplicația atunci când este reprodus doar la un anumit timbru de timp pe un anumit sistem de operare poate fi un defect de severitate ridicată și un defect cu prioritate redusă.

Un defect care este depus împotriva unei vizualizări care nu se deschide cu dublu clic, dar se deschide cu un clic dreapta poate fi un defect cu prioritate ridicată și severitate scăzută.

Q # 45) Scrieți un caz de testare eficient pentru a testa dacă o anumită hârtie este o hârtie albă?

Răspuns: Dacă culoarea sursei de cerneală cu care scrieți pe hârtie albă rămâne aceeași, atunci hârtia este albă. De exemplu, dacă scrieți pe o hârtie albă cu cerneală roșie, culoarea cernelii rămâne roșie în stilou și apare și roșie pe hârtie.

Notă: Există multe alte răspunsuri la această întrebare. Puteți ajunge să vă gândiți la orice astfel de răspuns valid cu logică de bază.

Q # 46) Ce este testarea Charter?

Răspuns: Un test de sesiune efectuat pe baza obiectivelor și agendelor enumerate într-o carte înainte de începerea testării este cunoscut sub numele de testare Charter.

Testarea aici se face într-un interval de timp fix, cu un accent mai mic pe documentare și mai mult accent pe doar testarea. Este o variantă diferită de testare exploratorie în care inginerii de testare verifică software-ul într-un interval de timp ( De exemplu, doar 2 ore) pe baza unor euristici dezvoltate.

Q # 47) Care este abordarea dvs. atunci când aveți o versiune cu prioritate ridicată care trebuie livrată într-un timp foarte scurt?

Răspuns: În astfel de cazuri, un plan bine gândit poate fi benefic.

Următoarele se pot face pentru a ajuta testarea într-un scenariu de lipsă de timp: -

• Utilizarea scripturilor de automatizare actualizate existente pentru executarea testării de regresie.
• Testarea scenariilor bazate pe flux cap la cap.
• Executarea cazurilor de testare cu prioritate ridicată și dacă timpul permite, treceți la cazurile cu prioritate inferioară.
• Re-testarea erorilor cu prioritate ridicată depuse pe versiunile anterioare.
• Testarea rapidă a software-ului
• Dezvoltatorii pot fi rugați să efectueze teste unitare pentru a obține o acoperire mai mare în testare.

Q # 48) Scrieți cazuri de testare pe orice dispozitiv / obiect prezent în jur (Exemplu: un scaun)?

Răspuns: Un sfat aici ar fi: Începeți întotdeauna cu colectarea cerințelor. Vă arată maturitatea față de ciclul de viață al dezvoltării software-ului. Nu ezitați să puneți întrebări după ce ați selectat obiectul.

În acest caz:-

• Ce tip de scaun este? Scaun de birou, scaun de masă de studiu, scaun de canapea, scaun de masă, scaun confortabil?
• Ce material este folosit pentru realizarea scaunului - lemn, oțel, plastic, tapițerie?
• Cereți dimensiunile (înălțimea, greutatea în funcție de tipul de scaun).
• Solicitați disponibilitate. Și pe baza asta începeți să vă redactați cazurile.

Cazurile de testare ar diferi pentru fiecare tip de scaun, ceea ce este mai bine lăsat pentru capacitatea dvs. de gândire ( De exemplu, scopul scaunului, dimensiuni în funcție de tipul de scaun, portabil-nepotabil, ușor, opțiuni de cumpărare).

Pentru fiecare scaun, a cazul testului de performanță poate fi: pentru a obține rezistența la tracțiune sau capacitatea maximă de rezistență.

Q # 49) Se poate automatiza totul?

Răspuns: - Într-o anumită măsură da. Dar instrumentele de automatizare, ca și alte programe software, au limitele sale. De asemenea, software-ul testat sau Aplicația testată va continua să fie actualizată.

Deci, nu există nicio garanție că testarea software-ului poate rula fără intervenție manuală. La urma urmei, un instrument este la fel de inteligent ca testerul. Este doar testarea software-ului încă un alt software. Codul / scripturile / bibliotecile trebuie să fie suficient de inteligent pentru a testa și găsi defecte.

Concluzie

Sper că acest exercițiu vă va ajuta să vă încălziți cu câteva întrebări și să vă ofere un început excelent pentru interviuri și să vă rafinați încrederea în timp ce răspundeți la întrebări. De asemenea, pot exista și alte întrebări bazate pe scenarii, care pot ieși din CV / profil.

Prin urmare, este întotdeauna recomandabil să practicați un interviu simulat cu auto-pre-hand, astfel încât interviul să se dovedească a fi o situație câștig-câștig atât pentru intervievator, cât și pentru candidat. Amintiți-vă că un analist de calitate este mai mult decât un inginer de testare, al cărui feedback este important nu doar pentru calitatea produsului, ci și pentru procesul urmat pentru testarea software-ului.

Mulțumesc și mult succes la interviuri!

Lectură recomandată

• Întrebări și răspunsuri la interviu
• 25+ Cele mai populare întrebări și răspunsuri la interviurile ADO.NET
• Cele mai bune 25 de întrebări și răspunsuri de interviu pentru testarea agilă
• Întrebări de interviu cu răspunsuri Spock (Cele mai populare)
• Întrebări și răspunsuri la interviuri de testare ETL
• 20 Cele mai populare întrebări și răspunsuri la interviu TestNG
• Top 30+ Întrebări și răspunsuri populare la interviu cu Castravete
• Top 50 Cele mai populare întrebări și răspunsuri ale interviului CCNA