40+ populære test-QA-analytikerspørgsmål og svar [2021 LIST]

40 popular test qa analyst interview questions

Ofte stillede spørgsmål / svar til test / kvalitetssikringsanalytiker Interviewspørgsmål og svar:

Mens du beslutter dig for den karriere, du vil være i, er den afgørende faktor ikke kun den, du tror kan nyde at arbejde med.

Men at være i den kategori kræver mange færdigheder, forståelse af ansvaret samt de nødvendige jobopgaver for den karriere, du valgte. Det samme gælder, mens du vælger en karriere som QA-analytiker. Det kræver ikke kun, at du er en god tester, hurtig lærer, ekstraordinær tænker, men det kræver også at være en kompleks problemløsning.

Selvom de ovennævnte kvaliteter ikke opnås med det samme, kræver det naturligvis også erfaring og dage med hårdt arbejde.

Denne artikel dækker alle aspekter, hvis viden er obligatorisk for at være en QA-analytiker. De hyppigst stillede spørgsmål og svar til QA Test Analyst-interview og svar, der er inkluderet her, giver dig en klar idé om dit interviewforberedelse.

Populære spørgsmål om QA-testanalytikerinterview

Q # 1) Hvad er en QA-analytikers ansvar?

Svar: QA Analyst er den, der sikrer, at der er taget alle mulige forholdsregler til at teste hver funktion af softwareløsning både funktionelt og teknisk.

QA Analysts hovedansvar kan tildeles som følger:

• Udfør og administrer alle aktiviteterne for at opfylde testplanens mål.
• Vælg processer af høj kvalitet for at udvikle produktet.
• Bør kunne analysere krav og dokumentprocedurer.
• Dokumentere og genbekræfte alle mangler. Indstil prioritet og sværhedsgrad for mangler.
• De skal være i stand til at oprette, dokumentere og vedligeholde testsager.
• Analyse af testresultater.

Spørgsmål nr. 2) Hvad er din forståelse med hensyn til en testplan?

Svar: Når du har en klar idé om, hvad, hvornår, hvordan og hvem, så bliver tingene lettere. Det samme er også tilfældet med softwaretest, hvor testplanen er et dokument, der består af testprojektets omfang, tilgang, ressourcer og oversigt samt aktiviteterne til at spore projektets fremskridt.

Testplanen er en oversigt over processer, der inkluderer:

• Testopgaver
• Testmiljø
• Designteknikker
• Indgangs- og udgangskriterier
• Eventuelle risici osv.

Q # 3) Anfør prioriteten for testopgaver, der er defineret af QA-teamet i produktudvikling.

Svar: Testopgavernes prioritet er defineret som følger:

• En testplan udarbejdes bestående af testprojektets disposition og omfang.
• Testcases er forberedt til at dække alle større og mindre funktionaliteter med de data, der kræves til testning.
• Udførelse af testcases i henhold til funktionaliteterne implementeret med de kommende builds af testprojektet i testcyklussen.
• Fejlrapportering med genbekræftelse samt sporing af dens fremskridt.
• Forberedelse af sammenfatningen af ​​testudførelsesrapporten.

Q # 4) Brug nogle af de vigtigste udfordringer, der står over for, når du udfører softwaretest.

Svar: Da vi siger, at komplet test aldrig kan opnås, er der flere udfordringer involveret i det. Det være sig en lille eller en kompliceret, der er nogle udfordringer, når du udfører softwaretest af ethvert projekt.

Nedenfor er nogle få vigtige udfordringer:

• Mangel på dygtig tester, der normalt står over for problemet med emnebevidsthed samt manglende god viden om kundens forretning.
• Tid betragtes også som faktoren, da testere normalt fokuserer primært på opgavedækning snarere end testdækning med kvalitetstest, når der er en enorm liste over opgaver, der skal udføres.
• At afgøre, hvilken testsag der skal udføres først og med prioritet. Dette opnås normalt med erfaring fra arbejde.
• En korrekt forståelse af kravene, der kan føre til, at al din testindsats er nul, hvis kravet misforstås.
• Utilgængelighed af de bedste værktøjer, der kræves for at gennemføre testen med mindre tid og mere effektivitet.
• Håndtering af forholdet mellem testere og udviklere med god kommunikations- og analysefærdigheder.

Q # 5) Definer test af brugssager.

Svar: Use Case-test kan defineres som den funktionelle black-box testteknik, der fanger den serie af interaktioner, der har fundet sted mellem 'aktører' og 'system'. Her er 'Skuespillere' repræsenteret af brugerne og deres interaktioner.

Karakteristika for test af brugssager er angivet nedenfor:

• Projektets funktionelle krav er organiseret.
• Registrerer stien eller scenarierne fra start til slut.
• Kan dække integrationsfejl, dvs. de defekter, der opstod som et resultat af interaktion mellem forskellige komponenter.
• Den beskriver såvel hovedstrømmene som den ekstraordinære strøm af begivenhederne.
• Eventuelle forudsætninger, der kræves for at brugssagen fungerer, bør specificeres tidligere.

Q # 6) Definer teststrategi.

Svar: Et sæt retningslinjer eller testmetoder, der normalt udføres af projektlederen for at bestemme testdesignet og den generelle testmetode, defineres som teststrategi. Det findes som en lille del af testplanen og bruges af flere projekter.

Forskellige testtilgange følges baseret på faktorer som produktets art og domæne, risikoen for produktsvigt, ekspertise i at arbejde med foreslåede værktøjer osv.

Disse tilgange er yderligere kategoriseret som følger:

• Proaktiv tilgang , hvor testdesignmetoden starter, før build oprettes. Således hjælper det med at finde og rette bugs før build.
• Reaktiv tilgang , hvor testmetoden startes efter afslutningen af ​​testdesign og kodning.

Q # 7) Forklar forskellen mellem kvalitetskontrol og kvalitetssikring.

Svar: 'Kvalitetskontrol' og 'Kvalitetssikring' er de to vigtigste udtryk, der anvendes vedrørende ethvert testprojekt eller produkt. Normalt forstår testere, der er nye inden for dette felt, ikke den faktiske forskel mellem de to.

Lad os forstå forskellen ved hjælp af nedenstående tabel.

Spørgsmål nr. 8) Hvornår er det godt at starte QA i et projekt ifølge dig?

Svar: Ifølge Software Development Life Cycle (SDLC) udføres testfasen efter afslutningen af ​​'Implementation and Coding' -fasen. Men i dagens scenarie er det nødvendigt at starte QA for projektet eller produktet for at opnå de bedste resultater ved projektets start.

At følge denne tilgang vil føre til de største fordele nedenfor:

• Tidlig procesplanlægning for at imødekomme kundens kvalitetsforventninger.
• God og sund kommunikation mellem holdene.
• Giver rigelig tid, der kræves til opsætning af testmiljøet.
• Tillader tidlig gennemgang og godkendelse af testplaner.

Q # 9) Differentier verifikations- og valideringsprocesser.

Svar: Verifikations- og valideringsprocesser bestemmes normalt af to berømte spørgsmål, dvs. Bygger vi systemet rigtigt? ” og 'Bygger vi det rigtige system?' .

Lad os se den anden forskel mellem disse to processer i nedenstående tabel:

Q # 10) Forklar fordelene ved destruktiv test.

Svar: Destruktiv test defineres som den testform, der udføres af testteamet for at bestemme produktets svigtpunkt under forskellige belastninger, dvs. evaluere applikationens strukturelle ydeevne for at bestemme dets styrke, sejhed, hårdhed eller sige robusthed.

Nedenfor er fordelene ved destruktiv test:

• Svagheden ved applikationsdesignet bestemmes.
• Bestem applikationens levetid.
• Det hjælper med at reducere omkostninger og fiasko.

Spørgsmål nr. 11) Hvordan adskiller gentest fra regressionstest?

Svar: Der er flere forskelle mellem gentestning og regressionstest.

Dette kan let forstås fra nedenstående tabel:

Spørgsmål nr. 12) Hvad ved du om datadrevet test?

Svar: Det er meget klart for enhver automatiseringstest, at automatiseringstestscripts kun dækker det område af applikationen, der skal testes, med en registreret række af brugerhandlinger. Normalt giver disse handlinger ingen fejl, da kun inputdata tages under forhold, som vi har indtastet under optagelse.

Datadrevet test kommer ind i billedet her, hvor vi ønsker, at applikationen skal fungere som forventet for enhver type inputværdier. Til dette formål er de data, der kræves til datadrevet test, ikke hårdkodet, men testscripts tager deres data fra datakilder som CSV-filer, ODBC-kilder osv.

For at opsummere udfører datadrevet test følgende handlinger i sløjfen:

software-test spørgsmål og svar om adfærdssamtaler

• Henter input testdata fra lageret.
• Data, der er indtastet i applikationen for at udføre handlinger.
• Kontroller de faktiske resultater med de forventede.
• Gentag igen de samme trin med nye input-testdata.

Spørgsmål nr. 13) Hvad er sporbarhedsmatrixen? Er det nødvendigt for hvert projekt?

Svar: Sporbarhedsmatrix i ethvert projekt er et middel til at spore projektets fremskridt med hensyn til implementering af nye funktioner, forbedring af eksisterende funktioner osv. Gennem en sporbarhedsmatrix kan du altid holde øje med projektets fremskridt med ethvert aspekt, der opretholdes iht. datoen.

Krav Sporbarhedsmatrix består af nedenstående parametre, der faktisk er i henhold til kravspecifikationsdokumentet.

Parametre for kravsporbarhedsmatrix inkluderer:

• Hvert afsnit i kravdokumentet er et punkt, der skal dækkes i RTM (kravsporbarhedsmatrix).
• Overskriften på hvert punkt er overskriften på hvert afsnit i kravspecifikationen.
• Svarende til hvert punkt nævnes test case id'er, der er skrevet til det pågældende afsnit.
• BUG / New Feature ID er også nævnt i hvert afsnit.
• Det vigtigste punkt er, at sporing af funktionen opretholdes, hvor projektets opbygning og dets funktion er blevet implementeret.
• En anden parameter inkluderer, om sektionen er fuldt testet eller stadig er under teststatus.

Q # 14) Beskriv fordelene ved Agile Testing.

Svar: At være en tester, fokus bliver at levere kvalitetsproduktet på kortere tid ved at forstå slutbrugerkravet og vigtigst af alt, ingen mangler fra slutbrugerens side. Her kommer Agile-test på billedet, der følger princippet om agil softwareudvikling og hurtigt validerer kundens krav.

Nedenfor er fordelene ved Agile test:

• Et tværfunktionelt agilt team er inkluderet i testningen, som igen leverer resultaterne med hyppige intervaller.
• Sparer meget tid og penge.
• Inkluderer mindre dokumentation og tid til anden feedback fra slutbrugeren.
• Ikke kun testeren, men hele teamet inklusive manager, kunde og udvikler er involveret i ansigt til ansigt kommunikation.
• Som et resultat af daglige møder kan spørgsmål fastlægges på forhånd.
• Forøgelse af teamets produktivitet og en bedre forståelse af de tekniske aspekter af projektet.

Spørgsmål nr. 15) Hvad er negativ testning?

Svar: Negativ testning er metoden til at sikre, at et produkts eller applikations stabilitet opretholdes eller siger ikke mislykkes, når uventet input gives. Hovedformålet med denne form for test validerer applikationen mod eventuelle ugyldige inputdata.

Denne form for test er også kendt som 'Fejltest' eller 'fejlsti-test' og dets hovedformål er at kontrollere pålideligheden af ​​applikationsfunktionen under negative scenarier. Det udsætter også softwaresvaghed, opdager fejlene og giver en klar idé om datakorruption.

Q # 16) Differentier ad-hoc-test og sonderende test?

Svar: Der er flere forskelle mellem ad-hoc-test og sonderende test.

Lad os se forskellene i nedenstående tabel:

Spørgsmål nr. 17) Hvorfor foretrækkes automatiseringstest frem for manuel testning?

Svar: Nå, både automatiseringstest og manuel testning har deres betydning og eksistens i testverdenen.

Nedenfor er nogle vigtige aspekter, som automatiseringstest foretrækkes frem for manuel testning:

• Det samme test script kan bruges hver gang til at køre testen, og derfor betragtes automatiseringstest som den mest pålidelige og effektive.
• Mest foretrukket i tilfælde af regressionstest og gentagen udførelse.
• Automatiseringstest anses for at være en omkostningseffektiv i tilfælde af langvarig udførelse og sikrer således en bedre kvalitet af software.
• Testskripter kan genbruges, hurtige, og alle kan se resultaterne.
• Værktøjer, der bruges til automatiseringstest, er hurtigere og mere pålidelige sammenlignet med den manuelle tilgang.

Selvom nogle flere faktorer bestemmer, at automatiseringstest foretrækkes frem for manuel test. Ovenstående er de vigtigste faktorer.

Spørgsmål nr. 18) Hvad forstår du ved 'Test effektivitet' og 'Test effektivitet'?

Svar: Testeffektivitet kan defineres som beregning af antallet af ressourcer og testkode, der er forbrugt til at udføre eller sige udføre en bestemt funktion. Det bestemmer også antallet af ressourcer, der bruges til oprettelse af softwareprodukter.

Dette kan bestemmes af formlen:

Testeffektivitet = (Antal mangler, der er løst / samlet antal leverede mangler) * 100

Test effektivitet kan defineres som et mål for evaluering af testmiljøet og dets virkning på softwareapplikationen. Her evalueres kunders respons, når ansøgningskravet er opfyldt.

Dette kan bestemmes af formlen:

Testeffektivitet = (Antal fundne mangler / antal udførte testsager)

Q # 19) Forklar processen med skræddersyet projekt.

Svar: Projekttilpasning er en konsekvent og løbende proces, der sikrer, at projektets ydeevne er korrekt og er i overensstemmelse med forretningskravene. Hele processen inkluderer gennemgang og ændring af projektdataene i henhold til organisationens aktuelle operationelle behov.

Gennemgangsprocessen udføres på organisatorisk niveau, men implementeringen af ​​skræddersyningsplanerne udføres på projektniveau. Organisationens hovedmål og krav såvel som kunde- og brugerforhold er de to vigtigste faktorer, der skal overvejes i processen.

Få aspekter i henhold til de organisatoriske mål under skræddersyningsprocessen er:

• Projekt tilgang
• Strategier
• Kontroller og processer involveret
• Roller og ansvar

Spørgsmål nr. 20) Hvordan skelner du mellem prioriteten og sværhedsgraden af ​​manglen inden for projektet?

Svar: Både 'Prioritet' og 'Alvorlighed' er tildelt fejlen til at kategorisere problemerne / fejlene i den rækkefølge, de skal tages til reparation. Disse er baseret på forskellige faktorer.

Lad os forstå mere sammen med deres forskelle i nedenstående tabel:

Spørgsmål nr. 21) Hvorfor er det nødvendigt at udføre ydelsestest for enhver applikation?

Svar: På et enkelt sprog udføres præstationsafprøvning for at bestemme en applikations opførsel og respons under forskellige situationer. Dette hjælper med at samle information om applikationsstabilitet, skalerbarhed, hastighed osv.

Årsagerne til at udføre præstationstest kan forstås fra nedenstående punkter:

• Det bestemmer svartiden og ydeevnen for en applikationskomponent under arbejdsbelastningen.
• Svartiden for brugerens aktivitet beregnes.
• Kræver erfarne programmører med omfattende teknisk sprog.
• Bestemmer applikationens opførsel under belastning, dvs. når antallet af brugere stiger med det samme.

Q # 22) Hvad er specifikationsdrevet test?

Svar: Som navnet definerer, udføres specifikationsdrevet test baseret på kravspecifikation af applikationen, hvor funktionelle specifikationer tjener som grundlag for de udførte tests.

Denne form for test er den samme som 'Black box testing', hvor brugeren indtaster flere data, og derefter output observeres. Det er passende på alle testniveauer med specifikation og testplan.

Q # 23) Forklar CMMI.

Svar: CMMI står for Capability Maturity Model Integration. Denne model blev udviklet af Software Engineering Institute (SEI). Det er baseret på princippet om, at de processer, der er involveret i styring og udvikling af et produkt eller system, bestemmer kvaliteten.

Det giver også retningslinjer for procesforbedring af produktet eller endda hele organisationen.

CMMI er opdelt i 5 niveauer som anført nedenfor:

• Niveau 1: Initial
• Niveau 2: Lykkedes
• Niveau 3: Defineret
• Niveau 4: Kvantitativt styret
• Niveau 5: Optimeret

Q # 24) Forklar fordelene ved at implementere CMMI.

Svar: Der er flere fordele ved at implementere CMMI.

De er anført som følger:

• Det giver detaljeret dækning og rapportering af produktets livscyklus og hjælper således med procesforbedringer.
• Organisationens eksisterende standarder, deres processer og procedurer forbedres som en del af CMMI-implementeringen.
• Som et resultat af CMMI-implementering er der en stigning i levering til tiden såvel som kundetilfredshed.
• Det fører også til effektiv styring og øgede omkostningsbesparelser, da der tidligt opdages fejl.

Q # 25) Få nogle automatiseringsprøvningsværktøjer til rådighed.

Svar: Nogle af automatiseringsprøvningsværktøjerne er anført nedenfor:

• Selen
• vand
• Vindmølle
• SÆBE
• Tellurium

Spørgsmål nr. 26) Kan vi lave regressionstest i Unit Testing?

Svar: Helt bestemt. Regressionstest er at teste den uønskede defekt, der muligvis er blevet indført i koden som en bivirkning ved afhjælpning af andre defekter. Enhedstest er testudførelsen af ​​at køre en lille uafhængig og individuel del af koden.

Regressionstest kan udføres på ethvert niveau lige fra enhedstest til integrationstest til endelig accepttest. Regressionstestning er testning baseret på perspektiv, mens enhedstestning er tilgangen på niveau (Bottom Up, Top-down).

Q # 27) Hvad er forskellen mellem røgtest og sundhedstest?

Svar:

• Røgtestning er testning af de gamle fremtrædende funktioner eller eksisterende funktioner i bygningen, mens Sanity-testning er validering af nyligt tilføjede moduler, faste fejl i bygningen.
• Røgtest sker først og derefter efterfølges af Sanity-test.
• Røgtestning dækker testning af kritiske funktioner, der leveres af softwaren, så den strækker sig gennem hele softwaren. Sanity-test er på den anden side indsnævret netop til de nyligt tilføjede moduler og testes i dybden.

Q # 28) Hvad er dine daglige aktiviteter som manuel tester på dit kontor?

Håndbog: Den første ting, jeg tjekker i mit system, er at opdatere dashboardet til status for krav / forbedringer eller fejl i den aktuelle iteration. Det efterfølges af daglige scrumopkald og rapportering, diskussion og brainstorming for at definere med testscenarier og testcases.

Disse sager udføres derefter efter omformulering i henhold til gennemgangen. Forbindelser med kunder for ikke-funktionelle krav er også en af ​​de største aktiviteter på min plade.

Q # 29) Hvad er dine daglige aktiviteter som medlem af automatiseringstesteren på dit kontor?

Automatisering: Min dag begynder med en daglig statusmøde, der diskuterer gårsdagens automatiseringsresultater, hvis jeg har fyret en række testsager på den nye version.

Udførelsescyklussen kan kaldes en Health Check for at se, hvor sund bygningen er.

Det efterfølges af rapportering af fejl baseret på scriptfejl, designændringer i funktionaliteten; vedligeholde scripts / biblioteker eller funktioner, automatisere og tjekke ind i et nyt script til de nye krav og om nødvendigt en ny funktion i funktionsbiblioteket.

Nogle gange skal testskripterne genudføres individuelt for at finde regressionsfejl via automatisering og tilføje dem også til testpakken.

Spørgsmål nr. 30) Hvordan skelner du mellem et krav og en mangel og en forbedring?

Svar : TIL krav er en brugerhistorie, der er vigtig for at blive implementeret, testet og leveret.
En forbedring er en tilføjet eller improviseret funktion til den eksisterende.
TIL defekt er snarere en fuldstændig afvigelse fra de forventede brugerhistorier.

Også, hvis en mangel afdækker et bestemt område af et krav, som ikke er angivet, medmindre andet er angivet i specifikationen, kan det også kaldes som et krav eller en del af det.

Q # 31) Hvad gør du, når din udvikler benægter at have rettet en fejl, du har arkiveret?

Svar : En vigtig faktor, der bestemmer afhjælpningen af ​​en defekt, er den 'Prioritet', der er tildelt den. Hvis defekten er højt prioriteret, er et show-stop, der blokerer en vigtig funktionalitet og gengives konsekvent, så det er nødvendigt at blive rettet i bygningen.

Det samme skal formidles effektivt til udviklere, da testere og udviklere sammen bidrager til kvaliteten af ​​det produkt, der skal sendes.

Andre aspekter, der kan hjælpe med at overbevise udvikleren om at rette en fejl inden for en kort periode, er kvalitetsrapportering af fejlen og få udviklerne til at forstå det faktum, at reparation af fejl er af største betydning i frigivelsen.

Q # 32) Hvad gør du, når din udvikler benægter, at det, du arkiverede, ER EN BUG?

Svar : En vigtig fase af defektens livscyklus er 'Afvist', hvilket betyder, at den loggede hændelsesrapport ikke er gyldig. Virksomhedskravdokumentet, der angiver krav, kan hjælpe med at forstå softwaren og dermed arten af ​​den rapporterede hændelse.

Analyser fejlen og udsæt dine fund om fejlen for udvikleren og teamet. Hvis det er en fejl, skal du aldrig logge på det. Undertiden er testere nødt til at give en Gap-analyse og præsentere det samme for udviklere. Hvis det ikke løser konflikterne, skal seniorfolk i holdet slå op.

Q # 33) Hvad kommer først med Gentest eller Regressionstest?

Svar : Gentest kommer først, da det kører koden igen, i enklere termer er det en gentagen udførelse af foruddefinerede trin. Det behøver ikke være nødvendigt efter at have rettet en kode. Men en regressionstest er at vurdere bivirkningerne af en løst defekt.

Det er bestemt ikke formålet med testprocessen at løse en fejl og tilføje en anden til koden. De bedste fund og bedste fangster af testere er normalt regressionsfejl. En build bør aldrig frigives uden regressionstest.

Q # 34) Hvad er et alternativ til betatestning?

Svar : Betatestning afholdes på klientens websted med mindst involvering af udviklere og registrerer fejlene i det virkelige produktionsmiljø. Hvis en sådan praksis ikke udføres af et firma, kan en sikrere idé være at sende produktet først til kunderne dem, der ikke er i køen for at få den nyeste version.

I et par dage kan visse servicekonsulenter hos kunderne bruge softwaren, registrere og overvåge de aktiviteter, der sikrer stabiliteten af ​​frigivelsen i deres miljø, så selvom en større fejl udelades for at blive rettet, kan den testes før levere det til den målrettede klient. En anden tilgang er byttet test af kravene i et team til upartisk test.

Q # 35) Hvad er ulemperne ved den Agile implementering / metode, du stod over for?

Svar : Ulemperne er som følger:

1. Sprints er normalt meget begrænsede.
2. Dokumentation er ikke prioriteten
3. Skift mellem PBI'er (Product Backlog Items) kan være hyppig.

Q # 36) Hvorfor er konsekvensanalyse vigtig?

Svar : For at øve risikobaseret skal konsekvensanalyse udføres. Ved at gøre dette kan testcases designes på en måde, så alle de alvorlige bugs, der er kritiske set fra kundens synspunkt, kan løses inden tiden. En god undersøgelse af virksomheden, kundens behov og deres brug af softwaren skal tages hånd om.

For eksempel, den vigtigste risiko forbundet med software på bankområdet er sikkerhed. Enhver ny form, der føjes til den allerede eksisterende software, kan være sårbar. En god mængde sikkerhedstest tilrådes ved at tilføje korrekte links, omdirigering og navigering til den rigtige side og eventuelt installere proxy.

Q # 37) Ved hjælp af et eksempel hver præstationstest, stresstest og belastningstest?

Svar : Det bedste tilfælde her, der kan tages, er et live-websted.

Test af ydeevne gøres for at verificere fejl i systemet, når de gennemgår en tilstand, der ligner et realtidsscenarie. Det er ikke nødvendigt at udføres under stressede forhold. Resultaterne af performance test hjælper med at fastslå, om systemet er klar til produktion.

For et simpelt billetbookingsflow kan et præstationsproblem have forårsaget langsommelighed. For eksempel er nogle forespørgsler ved hjælp af sammenføjninger lidt langsommere, der har implementeret unødvendig klausul eller lagring af data uhensigtsmæssigt i databasen.

Stresstest er en type Performance-test, der udføres ved at sætte softwaren under ekstreme forhold (tunge og ikke-fordelte belastninger, begrænsede beregningsressourcer, høj samtidighed).

Hvis et system udviser en bestemt opførsel som f.eks. Mistede eller ødelagte data, ressource, der bruges, selv efter at stress er fjernet, uansvarlighed eller undtagelser, der ikke håndteres, betyder det, at det mislykkes i stresstest. Nogle gange kan diskfejl, en unødvendig stigning i GDI-tællinger også være resultatet.

For eksempel, Hvis webstedet hostes på en maskine, der allerede bruger enorm hukommelse eller bombarderer det med gentagne anmodninger, ikke skal hænge eller logge dig af.

Belastningstest observerer systemadfærden, mens den konstant øger belastningen på systemet, indtil en tærskel er nået. Arbejdsbelastningsmodeller, metrics og belastningsniveauer er normalt input til belastningstesten.

For eksempel, tiden til at hente pladstilgængelighed til et tog øges gradvist, når tidspunktet for reservationen af ​​Tatkal-kvoten nærmer sig, da antallet af brugere, der derefter er logget ind i systemet, stiger med Tatkal-bookingtiden nærmer sig 10:00 eller 11:00.

Q # 38) Hvad har været en af ​​dine største udfordringer, mens du lavede regressionstest?

Svar : Der kan være forskellige udfordringer under udførelse af regressionstest.

• Genudførelse af test gentagne gange bliver måske ikke så spændende for testere.
• Tidskrævende, da nogle gange sådan testning er nødt til at tænke ud af boksen.
• Kompromitteret forretningsværdi.
• Forkert valg af regressionstest tilfælde kan springe over en større regressionsfejl, der kan findes.
• Reproduktion af manglen ved produktion bliver derfor inkonsekvent.
• Stor suite at udføre.

Q # 39) Hvis du bliver bedt om at dokumentere testscenarier, testcases, testplaner, teststrategi, hvad vil du begynde med, og i hvilken rækkefølge vil resten følge?

Svar : Sekvensen vil være teststrategi, testplan, testscenarier og endelig testsager.

Q # 40) Hvad hvis jeg savner at dokumentere et af ovenstående? Sig, jeg savner at dokumentere testplanen, hvad får konsekvenserne?

Svar : Hvis vi går glip af at dokumentere testplanen, er der et tomrum for omfanget af at teste dens objektive tilgang og vægt på testning. Det vil så være svært at bestemme de funktioner, der skal testes, teknikker til at teste, bestå eller mislykkes kriterier og i sidste ende en væsentlig risiko forbundet med testen.

Q # 41) Hvordan ville du begynde at teste det build, du for nylig fik: Er der nogen tilgang, du følger f.eks. først begynde røgtest, derefter sanitetstest?

Svar : Røgtest> Sanity testing> Exploratory Testing> Functionality Testing> Regression testing and Final Product Validation.

Q # 42) Forklar formatet på den fejlrapport, du fulgte?

Svar :

En fejlrapport skal indeholde følgende oplysninger:

• Fejl-id
• Kortlægning til krav / forbedring / eksisterende fejl
• Fejloversigt / titel
• En version af produktet
• Prioritet
• Konfiguration (systemspecifikationer)
• Forudsætninger
• Trin
• Forventet resultat
• Faktisk resultat
• Logfiler. Snapshots, videoklip
• Status
• Andre bemærkninger

Q # 43) Hvordan vælger du tilfælde af regressionstest eller danner regressionstestpakken?

Svar : Ja. Dette er et resultat af konsekvensanalyse. Det er en simpel kortlægning af de funktioner, der bruges eller fås adgang til i forskellige områder, som du tester, dets integration med andre funktioner og hele vejen igennem som et systems ende til slut eller flow test.

Du kan også afhente mangler, der tidligere er arkiveret for den samme funktionalitet i tidligere builds. Ideelt set bør en defekt regressionstestes ved hjælp af mindst fem forskellige testtilfælde, der bruger funktionaliteten.

Q # 44) Kan du komme med et eksempel på følgende fejl

• Lav prioritet Høj alvorlighedsfejl
• Høj prioritet og lav sværhedsgrad defekt

Svar : En defekt, der går ned på applikationen, når den kun gengives med et givet tidsstempel på et bestemt operativsystem, kan være en høj alvorlighedsgrad og en lav prioritetsfejl.

En defekt, der arkiveres mod en visning, der ikke åbnes fra dobbeltklik, men åbnes med et højreklik, kan være en høj prioritet og lav sværhedsfejl.

Q # 45) Skriv en effektiv test case for at teste, om et givet papir er et hvidt papir?

Svar: Hvis farven på kildeblæk, som du skriver på hvidt papir, forbliver den samme, er papiret hvidt. For eksempel, hvis du skriver på et hvidt papir med rødt blæk, forbliver farven på blækket rød i pennen og vises også rødt på papiret.

Bemærk: Der er mange andre svar på dette spørgsmål. Du kan komme til at tænke på et sådant gyldigt svar med underliggende logik.

Q # 46) Hvad er Charter-test?

Svar: En sessionstest udført på baggrund af de mål og dagsordener, der er anført under et charter, før testen påbegyndes, kaldes Chartertest.

Testen her udføres i et fast tidsinterval med mindre fokus på dokumentation og mere fokus på bare test. Det er en anden variant af sonderende test, hvor testingeniørerne verificerer softwaren i en tidsramme ( For eksempel, kun 2 timer) baseret på nogle udviklede heuristikker.

Q # 47) Hvad er din tilgang, når du har en høj prioritets frigivelse, der skal leveres på meget kort tid?

Svar: I sådanne tilfælde kan en velgennemtænkt plan være en fordel.

Følgende kan gøres for at hjælpe testning i et tidsmangel-scenarie: -

• Brug af eksisterende opdaterede automatiseringsskripter til udførelse af regressionstest.
• Test af flowbaserede scenarier fra ende til anden.
• Udførelse af testsager med høj prioritet, og skift til tilfælde med lavere prioritet, hvis tiden tillader det.
• Test igen de højt prioriterede fejl, der er arkiveret i tidligere versioner.
• Hurtig softwaretest
• Udviklere kan blive bedt om at køre enhedstest for at få mere dækning i test.

Q # 48) Skriv testcases på en hvilken som helst enhed / genstand, der er til stede (eksempel: en stol)?

Svar: Et råd her ville være: Begynd altid med at indsamle krav. Det viser din modenhed over for softwareudviklingens livscyklus. Du er velkommen til at stille spørgsmål, når du har valgt objektet.

I dette tilfælde:-

• Hvilken type stol er det? Kontorstol, studiebordstol, sofastol, spisebordstol, komfortstol?
• Hvilket materiale bruges til at fremstille stolen - træ, stål, plast, polstring?
• Spørg efter målene (højde, vægt baseret på stolstypen).
• Bed om tilgængelighed. Og baseret på det begynder du at udarbejde dine sager.

Testcases vil variere for hver stolstype, hvilket er bedre til din tænkningskapacitet ( For eksempel, formålet med stolen, dimensioner i henhold til stolstypen, bærbar-ikke-drikke, letvægts, købsmuligheder).

For hver stol, a præstationstest kan være: at udlede trækstyrken eller den maksimale vægtbærende kapacitet.

Q # 49) Kan alt automatiseres?

Svar: - Til en vis grad ja. Men automatiseringsværktøjer har ligesom anden software sine begrænsninger. Også software under test eller Applikation under test bliver ved med at blive opgraderet.

Så der er ingen garanti for, at softwaretest kan køre uden manuel indgriben. Når alt kommer til alt er et værktøj så smart som testeren er. Det er bare softwaretest af endnu en software. Det er koden / scripts / biblioteker, der skal være intelligente nok til at teste og finde mangler.

Konklusion

Håber, at denne øvelse hjælper dig med at varme op med nogle spørgsmål og giver dig en god start på dine interviews og finjusterer din selvtillid, mens du besvarer spørgsmålene. Der kan også være andre scenariebaserede spørgsmål, som kan komme ud af dit CV / din profil.

Derfor er det altid tilrådeligt at øve et mock-interview med selvforhånd, så interviewet viser sig at være en win-win-situation for både intervieweren og kandidaten. Husk, at en kvalitetsanalytiker er mere end en testingeniør, hvis feedback er vigtig for ikke kun produktets kvalitet, men også den proces, der følges til test af softwaren.

Tak og held og lykke med interviews!

Anbefalet læsning

• Interviewspørgsmål og svar
• 25+ mest populære ADO.NET interviewspørgsmål og svar
• 25 bedste spørgsmål om svar på Agile Testing Interview og svar
• Spock Interview-spørgsmål med svar (mest populære)
• ETL Testing Interview Spørgsmål og svar
• 20 mest populære TestNG Interview Spørgsmål og svar
• Top 30+ populære agurkspørgsmål og svar
• Top 50 mest populære CCNA Interviewspørgsmål og svar