40+ populära test QA-analytikerintervjuer och svar (2021 LIST)

40 popular test qa analyst interview questions

Vanliga frågor och svar om intervjuer med test / kvalitetssäkringsanalytiker:

Medan du bestämmer vilken karriär du vill vara i, är den avgörande faktorn inte bara den du tror kan njuta av att arbeta med.

Men att vara i den kategorin kräver mycket kompetens, att förstå ansvaret och de nödvändiga arbetsuppgifterna för den karriär du valt. Detsamma gäller när du väljer en karriär som QA-analytiker. Det kräver inte bara att du är en bra testare, snabb inlärare, extraordinär tänkare utan också kräver att du också är en komplex problemlösare.

Även om de ovannämnda egenskaperna inte uppnås direkt, kräver det uppenbarligen också erfarenhet och dagar av hårt arbete.

Den här artikeln kommer att täcka alla aspekter vars kunskap är obligatorisk för att vara QA-analytiker. De vanligaste frågorna och svaren på QA-testanalytiker som intervjuas här kommer att ge dig en tydlig bild av din intervjuförberedelse.

Populära frågor om intervjuer med QA-testanalytiker

F # 1) Vilka ansvar har en QA-analytiker?

Svar: QA Analyst är den som ser till att alla möjliga åtgärder har vidtagits för att testa varje funktion av programvarulösning både funktionellt och tekniskt.

De viktigaste ansvarsområdena för QA Analyst kan rekryteras enligt följande:

• Utför och hantera alla aktiviteter för att uppfylla målen för testplanen.
• Välj processer av hög kvalitet för att utveckla produkten.
• Bör kunna analysera krav och dokumentförfaranden.
• Dokumentera och verifiera alla fel. Ställ in prioritet och svårighetsgrad för defekter.
• De ska kunna skapa, dokumentera och underhålla testfall.
• Analys av testresultat.

F # 2) Vad är din uppfattning om en testplan?

Svar: När du har en tydlig uppfattning om vad, när, hur och vem, blir saker lättare. Detsamma är fallet även med programvarutestning, där testplanen är ett dokument som består av testprojektets omfattning, tillvägagångssätt, resurser och konturer samt aktiviteter för att spåra projektets framsteg.

Testplanen är ett register över processer som inkluderar:

• Testa uppgifter
• Testmiljö
• Designtekniker
• In- och utgångskriterier
• Eventuella risker etc.

Q # 3) Ange prioritet för testuppgifter som definierats av QA-teamet i produktutveckling.

Svar: Testuppgifternas prioritet definieras enligt följande:

• En testplan upprättas bestående av testprojektets översikt och omfattning.
• Testfall är förberedda för att täcka alla större och mindre funktioner med de uppgifter som krävs för testning.
• Utförande av testfall enligt funktionerna implementerade med de kommande byggnaderna av testprojektet i testcykeln.
• Felrapportering med omverifiering samt spårning av dess framsteg.
• Förbereder sammanfattningen av testutföranderapporten.

F # 4) Anmäl några av de viktigaste utmaningarna som står inför när du utför programvarutestning.

Svar: Som vi säger att fullständig testning aldrig kan uppnås finns det flera utmaningar involverade i det. Oavsett om det är ett litet eller ett komplicerat finns det några utmaningar som står inför när du utför programvarutestning av något projekt.

Nedan finns några viktiga utmaningar:

• Brist på skicklig testare som vanligtvis möter problemet med ämnesmedvetenhet samt brist på god kunskap om kundens verksamhet.
• Tiden betraktas också som faktorn, eftersom testare vanligtvis fokuserar huvudsakligen på uppdragstäckning snarare än testtäckning med kvalitetstestning när det finns en enorm lista över uppgifter som ska slutföras.
• Att avgöra vilket testfall som ska utföras först och med prioritet. Detta uppnås vanligtvis genom erfarenhet av arbete.
• En korrekt förståelse av kraven som kan leda till att alla dina testansträngningar är noll om kravet missförstås.
• Otillgänglighet av de bästa verktygen som krävs för att slutföra testet med mindre tid och mer effektivitet.
• Hantera relationen mellan testare och utvecklare med god kommunikations- och analysförmåga.

F # 5) Definiera test av användningsfall.

Svar: Användning Falltestning kan definieras som den funktionella svarta rutan testtekniken som fångar den serie interaktioner som har inträffat mellan 'aktörer' och 'system'. Här representeras ”skådespelare” av användarna och deras interaktioner.

Kännetecken för testet för användningsfall listas nedan:

• Projektets funktionella krav är organiserade.
• Registrerar sökvägen eller scenarierna från början till slut.
• Kan täcka integrationsfel, dvs defekter som uppstod till följd av interaktion mellan olika komponenter.
• Den beskriver huvudflödena och det exceptionella flödet av händelserna.
• Eventuella förutsättningar som krävs för att användningsfallet ska fungera bör specificeras tidigare.

F # 6) Definiera teststrategi.

Svar: En uppsättning riktlinjer eller testmetoder som vanligtvis utförs av projektledaren för att bestämma testdesignen och den allmänna testmetoden definieras som teststrategi. Den finns som en liten del av testplanen och används av flera projekt.

Olika testmetoder följs baserat på faktorer som produktens natur och domän, risken för produktsvikt, expertis i arbetet med föreslagna verktyg etc.

Dessa tillvägagångssätt kategoriseras vidare enligt följande:

• Proaktiv strategi , där testdesignmetoden börjar innan build skapas. Således hjälper det att hitta och fixa buggarna före byggandet.
• Reaktivt tillvägagångssätt , där testmetoden startas efter avslutad testdesign och kodning.

F # 7) Förklara skillnaden mellan kvalitetskontroll och kvalitetssäkring.

Svar: 'Kvalitetskontroll' och 'Kvalitetssäkring' är de två huvudsakliga termerna som används för alla testprojekt eller produkter. Vanligtvis förstår testare, som är nya inom detta område, inte den faktiska skillnaden mellan de två.

Låt oss förstå skillnaden med hjälp av nedanstående tabell.

F # 8) Enligt dig, när är det bra att starta QA i ett projekt?

Svar: Enligt Software Development Life Cycle (SDLC) utförs testfasen efter att 'Implementation and Coding' -fasen har slutförts. Men i dagens scenario, för att uppnå bästa resultat, krävs det att man startar projektets eller produktens kvalitetsbedömning i början av projektet.

Att följa detta tillvägagångssätt kommer att leda till de stora fördelarna nedan:

• Tidig processplanering för att möta kundens kvalitetsförväntningar.
• Bra och sund kommunikation mellan lagen.
• Ger tillräckligt med tid som krävs för att ställa in testmiljön.
• Tillåter tidig granskning och godkännande av testplaner.

F # 9) Differentiera verifierings- och valideringsprocesser.

Svar: Verifierings- och valideringsprocesser bestäms vanligtvis av två kända frågor, dvs. Bygger vi systemet rätt? ” och 'Bygger vi rätt system?' .

Låt oss se den andra skillnaden mellan dessa två processer i nedanstående tabell:

F # 10) Förklara fördelarna med destruktiv testning.

Svar: Destruktiv testning definieras som testformen som utförs av testteamet för att bestämma punkten för fel på produkten under olika belastningar, dvs för att utvärdera applikationens strukturella prestanda för att bestämma dess styrka, seghet, hårdhet eller säg robusthet.

Nedan listas fördelarna med Destruktiv testning:

• Svagheten i applikationsdesignen bestäms.
• Bestäm applikationens livslängd.
• Det hjälper till att minska kostnader och misslyckande.

F # 11) Hur skiljer sig omprov från regressionstest?

Svar: Det finns flera skillnader mellan omprövning och regressionstest.

Detta kan lätt förstås från nedanstående tabell:

F # 12) Vad vet du om datadriven testning?

Svar: Det är mycket tydligt för varje automatiseringstestare att automatiseringstestskript endast täcker det område av applikationen som ska testas med en inspelad sekvens av användaråtgärder. Normalt ger dessa åtgärder inte något fel eftersom bara att indata tas under förhållanden som vi har angett under inspelningen.

Datadriven testning kommer in i bilden här, där vi vill att applikationen ska fungera som förväntat för alla typer av ingångsvärden. För detta ändamål är de data som krävs för datadriven testning inte hårdkodade, men testskript tar deras data från datakällor som CSV-filer, ODBC-källor etc.

Sammanfattningsvis utför datadriven testning följande åtgärder i slingan:

huvudskillnaderna mellan c och c ++

• Tar inmatade testdata från lagringen.
• Data som anges i applikationen för att utföra åtgärder.
• Verifiera de faktiska resultaten med de förväntade.
• Upprepa igen samma steg med nya ingångstestdata.

F # 13) Vad är spårbarhetsmatrisen? Krävs det för varje projekt?

Svar: Spårbarhetsmatris i vilket projekt som helst är sättet att spåra projektets framsteg avseende implementering av nya funktioner, förbättring av befintliga funktioner etc. Genom en spårbarhetsmatris kan du alltid hålla ett öga på projektets framsteg med varje aspekt som upprätthålls enligt datumet.

Krav Spårbarhetsmatris består av nedanstående parametrar som faktiskt är enligt kravspecifikationsdokumentet.

Parametrar för kravspårbarhetsmatris inkluderar:

• Varje avsnitt i kravdokumentet är en punkt som ska täckas i RTM (kravspårbarhetsmatris).
• Rubriken för varje punkt är rubriken för varje avsnitt i kravspecifikationen.
• Motsvarar varje punkt nämns testfall-id som är skrivna för just det avsnittet.
• BUG / New Feature ID nämns också i varje avsnitt.
• Den viktigaste punkten är att spårning av funktionen bibehålls där projektets uppbyggnad och dess funktion har implementerats.
• En annan parameter inkluderar om avsnittet är fullständigt testat eller fortfarande är under teststatus.

F # 14) Beskriv fördelarna med Agile Testing.

Svar: Att vara testare blir fokus att leverera kvalitetsprodukten på kortare tid genom att förstå slutanvändarens krav och viktigast av allt, inga defekter från slutanvändarsidan. Här kommer Agile-tester på bilden som följer principen om smidig mjukvaruutveckling och snabbt validerar kundens krav.

Nedan nämns fördelarna med Agile-test:

• Ett tvärfunktionellt agilt team ingår i testet, vilket i sin tur levererar resultaten med frekventa intervaller.
• Sparar mycket tid och pengar.
• Innehåller mindre dokumentation och återkoppling från slutanvändaren.
• Inte bara testaren, utan hela teamet inklusive chefen, kunden och utvecklaren är inblandade i ansikte mot ansikte kommunikation.
• Som ett resultat av dagliga möten kan frågor väl bestämmas i förväg.
• Ökad teamproduktivitet och en bättre förståelse för projektets tekniska aspekter.

F # 15) Vad är negativ testning?

Svar: Negativ testning är metoden för att säkerställa att stabiliteten hos en produkt eller applikation bibehålls eller säger att inte misslyckas när oväntat input ges. Huvudsyftet med denna testform bekräftar ansökan mot eventuella ogiltiga indata.

Denna form av testning är också känd som ”Feltestning” eller ”felsökstestning” och dess huvudsyfte är att kontrollera tillförlitligheten för applikationsfunktionen under negativa scenarier. Det avslöjar också mjukvarusvaghet, upptäcker felen och ger en tydlig uppfattning om datakorruption.

F # 16) Differentiera Ad-hoc-testning och Exploratory Testing?

Svar: Det finns flera skillnader mellan Ad-hoc-test och Exploratory testing.

Låt oss se skillnaderna i nedanstående tabell:

F # 17) Varför föredras automatiseringstest framför manuell testning?

Svar: Tja, både automatiseringstestning och manuell testning har sin betydelse och existens i testvärlden.

Nedan följer några viktiga aspekter på grund av vilka automatiseringstest föredras framför manuell testning:

• Samma testskript kan användas varje gång för att köra testet, så automatiseringstestning anses vara den mest pålitliga och effektiva.
• Mest föredragen vid regressionstest och upprepad körning.
• Automationstestning anses vara kostnadseffektivt vid långvarig körning och säkerställer därmed en bättre kvalitet på programvaran.
• Testskript är återanvändbara, snabba och alla kan se resultaten.
• Verktyg som används för automatiseringstestning är snabbare och mer tillförlitliga jämfört med den manuella metoden.

Även om några fler faktorer avgör att automatiseringstest föredras framför manuell testning. Ovan nämnda är de viktigaste faktorerna.

F # 18) Vad förstår du med 'Testeffektivitet' och 'Testeffektivitet'?

Svar: Testeffektivitet kan definieras som att beräkna antalet resurser och testkod som förbrukas för att utföra eller säga utföra en viss funktion. Det avgör också antalet resurser som används vid skapandet av programvaruprodukter.

Detta kan bestämmas med formeln:

Testeffektivitet = (Antal brister som lösts / totalt antal brister som skickats) * 100

Testa effektiviteten kan definieras som ett mått på att utvärdera testmiljön och dess effekt på programvaran. Här utvärderas kundernas svar när ansökningskravet uppfylls.

Detta kan bestämmas med formeln:

Testeffektivitet = (Antal brister som hittats / Antal utförda testfall)

F # 19) Förklara processen för skräddarsydd projekt.

Svar: Projektanpassning är en konsekvent och fortlöpande process som ser till att projektets prestanda är korrekt och är i enlighet med företagets krav. Hela processen inkluderar granskning och modifiering av projektdata enligt organisationens nuvarande operativa behov.

Granskningsprocessen görs på organisationsnivå men implementeringen av skräddarsydda planer görs på projektnivå. Organisationens huvudsakliga mål och krav, såväl som kund- och användarrelationer, är de två viktigaste faktorerna som bör beaktas i processen.

Få aspekter enligt de organisatoriska målen under skräddarsydningsprocessen är:

• Projektinriktning
• Strategier
• Kontroller och processer involverade
• Roller och ansvar

F # 20) Hur skiljer du mellan prioriteten och svårighetsgraden i projektet?

Svar: Både 'Prioritet' och 'Allvarlighet' tilldelas felet för att kategorisera problemen / felen för den ordning de ska tas för att åtgärda. Dessa är baserade på olika faktorer.

Låt oss förstå mer tillsammans med deras skillnader i nedanstående tabell:

F # 21) Varför måste prestandatestning göras för alla applikationer?

Svar: På ett enkelt språk görs testning av prestanda för att bestämma beteendet och svaret för en applikation under olika situationer. Detta hjälper till att samla in information om applikationsstabilitet, skalbarhet, hastighet etc.

Anledningarna till att göra prestandatestning kan förstås från nedanstående punkter:

• Det avgör svarstiden och prestandan för en applikationskomponent under arbetsbelastningen.
• Svarstiden för användarens aktivitet beräknas.
• Kräver erfarna programmerare med omfattande tekniskt språk.
• Bestämmer beteendet för applikationen under belastning, dvs. när antalet användare ökar direkt.

F # 22) Vad är specifikationsstyrd testning?

Svar: Som själva namnet definierar görs specifikationsdriven testning baserat på kravspecifikationen för applikationen där funktionella specifikationer ligger till grund för de utförda testerna.

Denna form av testning är densamma som ”Black box testing” där användaren matar in flera data och sedan observeras utdata. Det är lämpligt på alla testnivåer med specifikation och testplan.

F # 23) Förklara CMMI.

Svar: CMMI står för Capability Maturity Model Integration. Denna modell har utvecklats av Software Engineering Institute (SEI). Det bygger på principen att de processer som är involverade i att hantera och utveckla en produkt eller ett system bestämmer kvaliteten.

Det ger också riktlinjer för processförbättring för produkten eller till och med hela organisationen.

CMMI är uppdelad i 5 nivåer enligt listan nedan:

• Nivå 1: Första
• Nivå 2: Hanteras
• Nivå 3: Definierat
• Nivå 4: Kvantitativt hanterad
• Nivå 5: Optimerad

F # 24) Förklara fördelarna med att implementera CMMI.

Svar: Det finns flera fördelar med att implementera CMMI.

De listas enligt följande:

• Det ger detaljerad täckning och rapportering av produktens livscykel och hjälper därmed till processförbättringar.
• De befintliga standarderna i organisationen, deras processer och procedurer förbättras som en del av CMMI-implementeringen.
• Som ett resultat av CMMI-implementeringen ökar leveransen i tid såväl som kundnöjdheten.
• Det leder också till effektiv hantering och ökade kostnadsbesparingar eftersom det finns tidig upptäckt av fel.

F # 25) Anskaffa några verktyg för automatiseringstest.

Svar: Några av verktygen för automatiseringstest är listade nedan:

• Selen
• vatten
• Väderkvarn
• TVÅL
• Tellur

F # 26) Kan vi göra regressionstester i Unit Testing?

Svar: Definitivt. Regressionstestning är att testa den oönskade defekten som kan ha införts i koden som en bieffekt av att åtgärda andra defekter. Enhetstestning är testutförandet av att köra en liten oberoende och individuell del av koden.

Regressionstestning kan göras på vilken nivå som helst, från enhetstestning till integrationstestning till slutlig acceptantestning. Regressionstestning är testning utifrån perspektiv, medan enhetstestning är nivån (Bottom Up, Top-down).

F # 27) Vad är skillnaden mellan rökprovning och sanitetsprovning?

Svar:

• Rökprovning är testning av gamla framträdande funktioner eller befintliga funktioner i byggnaden, medan Sanity-testning är validering av nyligen tillagda moduler, fixade defekter i byggnaden.
• Rökprovning sker först och följs sedan av Sanity-test.
• Rökprovning täcker testning av kritiska funktioner som programvaran tillgodoser så att den sträcker sig genom hela programvaran. Sanity-test, å andra sidan, begränsas bara till de nyligen tillagda modulerna och testas på djupet.

F # 28) Vilka är dina dagliga aktiviteter som manuell testare på ditt kontor?

Handbok: Det första jag kontrollerar i mitt system är att uppdatera instrumentpanelen för status för krav / förbättringar eller buggar i den aktuella iterationen. Det följs av dagliga scrumsamtal och rapportering, diskussion och brainstorming för att definiera med testscenarier och testfall.

Dessa ärenden utförs sedan efter omformulering enligt granskningen. Att ha kontakt med kunder för icke-funktionella krav är också en av de viktigaste aktiviteterna på min platta.

F # 29) Vilka är dina dagliga aktiviteter som medlem i automatiseringstestaren på ditt kontor?

Automatisering: Min dag börjar med ett dagligt statusmöte som diskuterar gårdagens automatiseringsresultat, om jag har avfyrat ett antal testfall på nybyggnaden.

Utförandecykeln kan kallas en hälsokontroll för att se hur hälsosam byggnaden är.

Det följs av rapporteringsfel baserat på skriptfel, designändringar i funktionaliteten; underhålla skript / bibliotek eller funktioner, automatisera och checka in i ett nytt skript för de nya kraven och vid behov en ny funktion i funktionsbiblioteket.

Ibland måste testskripten köras om individuellt för att hitta regressionsfel via automatisering och lägga till dem också i testsviten.

F # 30) Hur skiljer du mellan ett krav och en defekt och en förbättring?

Svar : TILL krav är en användarberättelse som är nödvändig för att implementeras, testas och levereras.
Ett förbättring är en tillagd eller improviserad funktion till den befintliga.
TILL defekt är snarare en fullständig avvikelse från de förväntade användarberättelserna.

Om en defekt avslöjar ett visst område i ett krav som inte anges om inte annat anges i specifikationen, kan det också kallas som ett krav eller en del av det.

F # 31) Vad gör du när din utvecklare förnekar att du har åtgärdat ett fel som du skickade in?

Svar : En viktig faktor som avgör fixering av en defekt är den 'Prioritet' som tilldelats den. Om defekten har hög prioritet, en showpropp, som blockerar en stor funktionalitet och reproduceras konsekvent, är det nödvändigt att fixa det i byggnaden.

Detsamma måste förmedlas till utvecklare effektivt eftersom testare och utvecklare tillsammans bidrar till kvaliteten på den produkt som ska skickas.

Andra aspekter som kan hjälpa till att övertyga utvecklaren att åtgärda en bugg inom en kort period är kvalitetsrapportering av felet och att få utvecklarna att förstå det faktum att felsökningen är av största vikt i utgåvan.

F # 32) Vad gör du när din utvecklare förnekar att det du lämnade in är ett BUG?

Svar : En viktigaste fas av defektens livscykel är ”Avvisad”, vilket innebär att den loggade incidentrapporten inte är giltig. Affärskravdokumentet som anger krav kan hjälpa till att förstå programvaran och därmed arten av den rapporterade incidenten.

Analysera felet och exponera dina resultat om felet för utvecklaren och teamet. Om det är en defekt, misslyckas aldrig med att logga den. Ibland måste testare tillhandahålla en Gap-analys och presentera samma för utvecklare. Om det inte löser konflikterna bör äldre personer i laget slå in.

F # 33) Vad kommer först omprövning eller regressionstest?

Svar : Omprövning kommer först eftersom det körs om koden, i enklare termer är det ett upprepat utförande av fördefinierade steg. Det behöver inte vara nödvändigt efter att en kod har fixats. Men ett regressionstest är att bedöma biverkningarna av en löst defekt.

Att lösa en defekt och lägga till ytterligare en i koden är inte syftet med testprocessen. De bästa fynden och de bästa fångsterna av testare är vanligtvis regressionsfel. En byggnad bör aldrig släppas utan regressionstest.

F # 34) Vad är ett alternativ till betatestning?

Svar : Betatestning hålls på klientens webbplats med minst involvering av utvecklare och registrerar fel i den verkliga produktionsmiljön. Om en sådan praxis inte utförs av ett företag kan en säkrare idé vara att skicka produkten först till kunderna som inte står i kö för att få den senaste versionen.

Under ett par dagar kan vissa servicekonsulter på klientens lokaler använda programvaran, spela in och övervaka de aktiviteter som säkerställer stabiliteten i utgivningen i deras miljö, så att även om ett större fel utelämnas för att åtgärda kan testas innan leverera den till den riktade klienten. Ett annat tillvägagångssätt är bytt test av kraven i ett team för opartisk testning.

F # 35) Vilka är nackdelarna med Agile-implementeringen / -metoden som du mötte?

Svar : Nackdelarna är som följer:

1. Sprints är vanligtvis mycket tidsbegränsade.
2. Dokumentation är inte prioriteten
3. Växling mellan PBI: er (Product Backlog Items) kan vara frekvent.

F # 36) Varför är konsekvensanalys viktigt?

Svar : För att öva riskbaserad måste konsekvensanalys göras. Genom att göra detta kan testfall utformas så att alla allvarliga buggar, kritiska ur kundens syn, kan lösas före tiden. En bra studie av verksamheten, kundens behov och deras användning av programvaran ska tas om hand.

Till exempel, den viktigaste risken som är förknippad med programvara inom banksektorn är säkerhet. Alla nya formulär som läggs till i den redan befintliga programvaran kan vara sårbara. En hel del säkerhetstest rekommenderas genom att lägga till korrekta länkar, omdirigering och navigering till rätt sida, installera proxy om det behövs.

F # 37) Med hjälp av ett exempel på varje prestandatestning, stresstestning och belastningstestning?

Svar : Det bästa fallet här som kan tas är en levande webbplats.

Prestandatester görs för att verifiera fel i systemet när det genomgår ett tillstånd som liknar ett realtidsscenario. Det är inte nödvändigt att utföras under stressade förhållanden. Resultaten av prestandatestning hjälper till att fastställa om systemet är klart för produktion.

För ett enkelt biljettbokningsflöde kan en prestandafråga ha orsakat långsamhet. Till exempel är en del frågor med hjälp av kopplingar lite långsammare som har implementerat onödig klausul eller lagring av data felaktigt i databasen.

Stresstestning är en typ av prestandatestning som utförs genom att sätta programvaran under extrema förhållanden (tunga och odelade belastningar, begränsade beräkningsresurser, hög samtidighet).

Om ett system uppvisar visst beteende som data som går förlorade eller skadas, resurs används även efter att stress har tagits bort, svar eller oriktiga undantag, betyder det att det misslyckades i stresstestning. Ibland kan skivfel, en onödig ökning av GDI-antalet också bli resultatet.

Till exempel, Om webbplatsen är värd på en maskin som redan konsumerar enormt minne eller bombarderar det med upprepade förfrågningar, borde du inte hänga eller logga ut.

Lasttestning observerar systemets beteende samtidigt som belastningen på systemet ständigt ökar tills ett tröskelvärde nås. Arbetsbelastningsmodeller, mätvärden och belastningsnivåer är vanligtvis ingången till belastningstestningen.

Till exempel, tiden för att hämta platstillgänglighet för ett tåg ökar gradvis när tiden för bokning av Tatkal-kvoten närmar sig eftersom antalet användare som sedan är inloggade i systemet ökar med Tatkals bokningstid närmar sig 10:00 eller 11:00.

F # 38) Vad har varit en av dina största utmaningar när du gjorde regressionstester?

Svar : Det kan finnas olika utmaningar när du utför regressionstester.

• Att ompröva flera gånger kanske inte blir så spännande för testare.
• Tidskrävande, eftersom det ibland är nödvändigt att tänka på sådana test.
• Komprometterat affärsvärde.
• Felaktigt val av fall med regressionstest kan hoppa över en större regressionsfel som kan hittas.
• Att reproducera defekten vid produktionen blir därför inkonsekvent.
• Stor svit att köra.

F # 39) Om du blir ombedd att dokumentera testscenarier, testfall, testplaner, teststrategi vad ska du börja med och i vilken ordning kommer resten att följa?

Svar : Sekvensen kommer att vara teststrategi, testplan, testscenarier och slutligen testfall.

F # 40) Vad händer om jag saknar att dokumentera något av ovanstående? Säg att jag saknar att dokumentera testplanen. Vilka blir konsekvenserna?

Svar : Om vi ​​missar att dokumentera testplanen kommer det att bli ett tomrum för testets omfattning och betoning på testning. Det blir då svårt att avgöra vilka funktioner som ska testas, tekniker för att testa, klara eller underkänna kriterier och i slutändan en stor risk förknippad med testningen.

F # 41) Hur skulle du börja testa den version som du nyligen fick: Finns det någon metod du följer t.ex. börja först med rökprovning, sedan Sanity-test?

Svar : Rökprovning> Sanitytest> Exploratory Testing> Functionality Testing> Regression testing and Final Product Validation.

F # 42) Förklara formatet på Bug Report som du följde?

Svar :

En buggrapport bör innehålla följande information:

• Fel-id
• Kartläggning till Krav / Förbättring / Befintlig bugg
• Bug Sammanfattning / titel
• En version av produkten
• Prioritet
• Konfiguration (systemspecifikationer)
• Förutsättningar
• Steg
• Förväntat resultat
• Verkligt resultat
• Loggar. Ögonblicksbilder, videoklipp
• Status
• Andra kommentarer

F # 43) Hur väljer du regressionstestfall eller bildar regressionstestpaketet?

Svar : Ja. Detta är ett resultat av konsekvensanalys. Det är en enkel kartläggning av de funktioner som används eller nås i olika områden som du testar, dess integration med andra funktioner och hela tiden som ett systems slut-till-slut- eller flödestestning.

Du kan också hämta fel som tidigare arkiverats för samma funktionalitet i tidigare versioner. Helst bör en defekt regressionstestas med minst fem olika testfall som använder funktionaliteten.

F # 44) Kan du komma med ett exempel på följande fel

• Låg prioritet Hög allvarlighetsdefekt
• Hög prioritet och låg svårighetsgrad defekt

Svar : En defekt som kraschar applikationen när den endast reproduceras vid en viss tidsstämpel på ett visst operativsystem kan vara en defekt med hög svårighetsgrad och låg prioritet.

En defekt som arkiveras mot en vy som inte öppnas från dubbelklick men öppnas med högerklick kan ha hög prioritet och låg svårighetsgrad.

F # 45) Skriv ett effektivt testfall för att testa om ett visst papper är ett vitbok?

Svar: Om färgen på det bläck som du skriver på vitt papper förblir densamma är papperet vitt. Om du till exempel skriver på ett vitt papper med rött bläck förblir färgen på bläcket röd i pennan och visas också rött på papperet.

Notera: Det finns många andra svar på denna fråga. Du kan komma att tänka på ett sådant giltigt svar med underliggande logik.

F # 46) Vad är stadgtestning?

Svar: En sessionstestning baserad på de mål och agendor som listas under en stadga innan testningen påbörjas kallas stadgtestning.

Testerna här görs i en fast tidslucka med mindre fokus på dokumentation och mer fokus på bara testning. Det är en annan variant av utforskande testning där testingenjörerna verifierar programvaran i en tidsram ( Till exempel, bara 2 timmar) baserat på vissa utvecklade heuristik.

F # 47) Vad är din inställning när du har en högprioriterad version som ska levereras på mycket kort tid?

Svar: Under sådana fall kan en väl genomtänkt plan vara till nytta.

Följande kan göras för att underlätta testning i ett tidsbristsscenario: -

• Använda befintliga uppdaterade automatiseringsskript för körning av regressionstest.
• Testa flödesbaserade scenarier från slut till slut.
• Genomföra testfall med hög prioritet och om tiden tillåter, byt till fall med lägre prioritet.
• Testa om de högprioriterade buggarna som sparats på tidigare versioner.
• Snabb programvarutestning
• Utvecklare kan uppmanas att köra enhetstester för att få mer täckning vid testning.

F # 48) Skriv testfall på någon enhet / föremål som finns runt (Exempel: en stol)?

Svar: Ett råd här skulle vara: Börja alltid med insamlingskrav. Det visar din mognad mot livscykeln för programvaruutveckling. Ställ gärna frågor efter att du har valt objektet.

I detta fall:-

• Vilken typ av stol är det? Kontorsstol, studiebordstol, soffstol, matbordstol, komfortstol?
• Vilket material används för att göra stolen - trä, stål, plast, klädsel?
• Be om måtten (höjd, vikt baserat på stolstyp).
• Be om tillgänglighet. Och baserat på det börja utarbeta dina ärenden.

Testfall skulle skilja sig åt för varje typ av stol, vilket är bättre för din tänkande förmåga ( Till exempel, stolens syfte, dimensioner beroende på stolstyp, bärbar-icke-drickbar, lätt, köpoptioner).

För varje stol, a prestanda testfall kan vara: för att härleda draghållfastheten eller den maximala viktbärande förmågan.

F # 49) Kan allt automatiseras?

Svar: - Till viss del ja. Men automatiseringsverktyg, som andra program, har sina begränsningar. Även programvara som testas eller Applikation som testas fortsätter att uppgraderas.

Så det finns ingen garanti för att programvarutestning kan köras utan manuellt ingripande. När allt kommer omkring är ett verktyg lika smart som testaren är. Det är bara programvarutestning ännu en programvara. Det är koden / skript / bibliotek som måste vara tillräckligt intelligenta för att testa och hitta fel.

Slutsats

Hoppas den här övningen hjälper dig att värma upp med några frågor och ger dig en bra start för dina intervjuer och förfina ditt självförtroende medan du svarar på frågorna. Det kan också finnas andra scenariobaserade frågor som kan komma ur ditt CV / profil.

Därför är det alltid tillrådligt att öva en mock-intervju med självförhand, så att intervjun visar sig vara en vinn-vinn-situation för både intervjuaren och kandidaten. Kom ihåg att en kvalitetsanalytiker är mer än en testingenjör, vars feedback är viktig för inte bara produktens kvalitet utan också för den process som följts för att testa programvaran.

Tack och lycka till med intervjuerna!

Rekommenderad läsning

• Intervjufrågor och svar
• 25+ mest populära ADO.NET intervjufrågor och svar
• 25 bästa intervjuer och svar på Agile Testing
• Spock intervjufrågor med svar (mest populära)
• ETL Testing Intervju Frågor och svar
• 20 mest populära TestNG-intervjufrågor och svar
• Topp 30+ populära gurkaintervjuer och frågor
• Topp 50 mest populära CCNA-intervjufrågor och svar