Meny

Programvaruhandbok Testning av intervjufrågor för erfarna yrkesverksamma


software manual testing interview questions

Prova Vårt Instrument För Att Eliminera Problem

Vanligaste scenariobaserade manuella testintervjufrågor för erfarna proffs med detaljerade svar:


Jag har nyligen haft denna unika upplevelse av QA coaching (10 års erfarenhet) för att delta i en klientintervju med ett ledande underhållningsföretag i Los Angeles. Webbplatsen som skulle testas var en enkel kundinriktad webbplats (ungefär som en online-TV-kanal) som hade både webb- och mobilkomponenter.

Software Manual Testing Intervjufrågor


Ett konsultföretag projekterade profiler till den här klienten för en på plats tester + koordinatorposition men ingen av dem klarade sig genom testintervjuprocessen. Så de bestämde sig för att samla in QA-intervjufrågor från de tidigare deltagarna och de gav mig ett frågeformulär.

göra en kopia av en matris

De ville att jag skulle ge svaren till nästa kandidat och coacha det person att lyckas i testning QA intervju.

Manual Testing intervjufrågor för erfarna


När jag fick en lista med frågor blev jag förvånad och ”inte förvånad” samtidigt. Förvånad - för att frågorna var riktigt enkla och en 10-årig erfaren QA borde ha kunnat svara lätt på dem. Inte så förvånad eftersom QA är det område inom IT som har mest ogräs enligt min mening - men låt oss inte gå in på det.

Efter att ha gjort det med övningen tyckte jag att det skulle vara trevligt att dela denna erfarenhet med STH-läsarna. För nybörjare kommer detta att vara bra live exponering. För andra kommer det att vara en vänlig påminnelse om hur viktigt grundläggande är oavsett hur erfarna vi är.

Rekommenderad läsning=> 101+ Programtestintervjuer och svar.


Här kommer…..

Manuella testintervjuer för erfarna

De 9 vanligaste QA-programvarutestningsintervjufrågorna för både nybörjare och erfarna kandidater:

#Q 1) Vad är processen för att skapa ett testskript?


Svar:

Steg 1: är att få en grundlig förståelse för AUT:

  • Detta kan vara genom att läsa kravdokumenten noggrant.
  • I avsaknad av dokument kan vi försöka förstå vilken referenspunkt vi har - en tidigare version av applikationen eller trådramar eller skärmdumpar

Steg 2: Efter att ha förstått kraven gör vi en lista över vilka områden i denna applikation som måste testas. Med andra ord identifierar vi testkraven. Fokus i detta steg är att identifiera 'Vad' att testa. Resultatet av detta steg är en lista över Testa scenarier .

Steg 3: När vi väl har testscenarierna koncentrerar vi oss sedan på ”Hur” för att testa dem. Denna fas innebär att man skriver detaljerade steg om hur man testar en viss funktion, vilka data som ska anges ( Testdata ) och vad är det förväntade resultatet.

När dessa tre steg är klara är vi redo för testning.

#Q 2) Vilka är fälten i en felrapport?

Svar: Följande viktiga fält bör ingå i a bra felrapport :

  1. Ett unikt ID
  2. Defektbeskrivning: en kort beskrivning av vad felet är.
  3. Åtgärder för att reproducera: detaljer om hur man kommer fram till felet, exakta testdata, när fel upptäcktes (om tillämpligt) miljö: all information som kan hjälpa till att möta problemet igen
  4. Modul / avsnitt av applikationen (om tillämpligt)
  5. Allvarlighetsgrad
  6. Skärmdump
  7. Ansvarig QA: vid uppföljningsfrågor angående denna fråga

#Q 3) Hur testar jag en kundinriktad programvara?

Svar: Med alla applikationer som vi testar försöker vi se om en viss uppsättning krav uppfylls av applikationen eller inte. Men när det gäller en användarinriktad webbplats, förutom att koncentrera oss på funktionalitet, måste vi också titta på några användbarhetsfunktioner, kanske prestations- och säkerhetsaspekter också i viss utsträckning.

Den första testnivån är : Uppfyller webbplatsen dess funktionella krav.

Till exempel, om det är en webbplats för hantering av lån, måste vi titta på - kan den nya kunden ansöka om ett lån, kan den befintliga kunden få tillgång till sin låninformation, är den ränteprocent som tillämpas på lånebeloppet korrekt, etc.

Nästa testnivå är :hur lätt är det att använda webbplatsen, gör alternativen logiskt och uppfyller användarens förväntningar eller inte.

Till exempel, om användaren måste passera 3-4 skärmar för att skicka den grundläggande informationen kommer de att bli irriterade, så sådana frågor måste åtgärdas.

Annan exempel, efter att ha angett användarnamn och lösenord kan användaren klicka på fliken - vilket innebär att kontrollen ska gå till “Logga in” -knappen, istället om den kommer att avbrytas kommer användaren att bli riktigt irriterad och upplevelsen av att använda webbplatsen är kommer att äventyras. Sådana frågor måste fångas.

Prestandatester i fullständig utsträckning kanske inte är i räckvidd men enkla situationer som, hur lång tid tar sökresultaten för att visas och hur mycket tid det tar för systemet att hämta kundinformation under topptiden - det här är några exempel på typ av saker vi skulle vilja hålla ett öga på.

säkerhet - För webbplatser där det finns en säker inloggning för att komma åt webbplatsen måste minimifunktionaliteten runt den testas. Till exempel, om jag lämnar webbplatsen inaktiv i mer än 10 minuter, är det automatiskt att logga ut eller inte. Något så grundläggande som det bör fokuseras på.

#Q 4) Hur löser man utmaningen att inte ha ingångsdokumentation för testning?

Svar: Om den detaljerade standarddokumentationen som BRD och FSD inte är tillgänglig måste testaren vara beroende av någon referenspunkt.

  • Skärmdumpar
  • En tidigare version av applikationen
  • Trådramar osv

En annan faktor som hjälper oerhört är att prata med utvecklarna eller affärsanalytikerna (när de är tillgängliga) för att få en bekräftelse på vår förståelse eller förtydliganden i händelse av tvivel.

När ingen av dessa situationer fungerar kan vi bara konceptualisera applikationen baserat på vår tidigare IT-applikationsupplevelse och skapa den grundläggande uppsättningen testskript. När testfasen kommer upp kan vi ställa in en del av testcykeltiden och göra lite testfallshantering (gör de redan skapade skripten perfekta) så vi har dokumentet för nästa faser.

#Q 5) Hur man får maximal produktivitet från ett offshore-team?

vad är den bästa datorrengöringsprogramvaran

Svar: Nyckeln är att se till att alla testare känner till alla moduler och att det inte finns någon kunskapskoncentration på ett ställe. Att involvera alla i testskript peer reviews, defektmöten och KT-sessioner kommer att säkerställa att alla är medvetna om applikationen i bästa möjliga utsträckning.

Genom att uppmuntra begreppet lagarbete kan vi också få teammedlemmarna att samarbeta, hjälpa och hjälpa varandra för bättre produktivitet.

Regelbundna uppföljningsmöten hjälper också processen mycket.

#Q 6) Vilka roller och ansvar har en koordinator på plats? Testar han / hon också?

Svar: Koordinatorn på plats är en kontaktpunkt för offshore-teamet och till klienten för all information angående testuppdraget.

Detta jobb inkluderar:

  • KT från och till offshore och kunder
  • Få miljön att testa allt klart
  • Sanity testning, rök testning
  • Testning - nyckelfunktionen.
  • Bug review - hittades av offshore-teamet
  • Bug tilldelar respektive dev
  • Presentera mätvärden
  • Ger avloggning

Ja, även en koordinator på plats måste testa.

#Q 7) Inkonsekventa buggar- Varför på plats kan hitta det, men offshore kan inte och vice versa - Hur hanterar du den här situationen?

Svar: Varje fel måste noteras och analyseras - oavsett om det påträffas på plats eller offshore, oavsett om det kan repeteras eller inte. Ett verkligt mervärde till en testares jobb är när vi involverar oss i Root Cause Analysis-processen för ett fel snarare än att bara rapportera det.

Några av sätten vi kan hantera denna situation på är:

  • Alla teammedlemmar på plats och offshore bör följa en riktlinje att skärmdumpar måste tas för varje fel som vi stöter på - repeterbara eller inte.
  • Om det finns loggar, systemfiler eller något liknande, kan det hjälpa oss att hitta bevis på problemet - vi bör försöka hitta det.
  • Trots alla dessa steg, om vi fortfarande inte kan berätta varför och när problemet uppstår, bör vi rapportera det till utvecklaren på samma sätt - med så mycket information som vi kan.

#Q 8) Video / ljudrelaterad testning - Vad inkluderar detta?

Svar: Hur testar jag ett program med video eller ljud?

Här är viktiga punkter att tänka på:

  • Åtkomstnivåer (begränsad eller inte - lösenordskontrollerad)
  • Olika typer av miljöer
  • Webbläsarkompatibilitet
  • Skärmupplösningar
  • Internetanslutningshastigheter
  • De specifika alternativen på en video - som att spela, stoppa, stänga av ljud etc.
  • Video efter storlek
  • Svar på videorna - kommentarer (begränsningar av kommentarlängden och antalet kommentarer det kan ta)
  • Videosvar på videorna
  • Gränssnitt med sociala nätverkssajter - Interoperabilitet
  • Bufferthastighet
  • Bädda in videon

#Q 9) ​​Testning av mobilapplikationer - Vad innehåller det kort?

Svar: Test av mobilappar Viktiga testscenarier:

  • Kontrollera om appen fungerar bra med flera operatörer och flera enheter.
  • Användbarheten av funktionerna på en mobilskärm.
  • Testar det på olika mobila plattformar - som Android och iOS.
  • Installationer, avinstallation, start av appen med nätverk och utan nätverk, testfunktionalitet.
  • Nätverksanslutningar –WiFi, 2G, etc.
  • Loggar på iOS iPhone-konfigurationsverktyg för Android Monitor.bat kan användas för felsökning.

Det var det. Nu var det inte så enkelt.

Som en sista anmärkning upprepar jag filosofin på STH - känner till grunderna väl, resten följer automatiskt.

Jag avslutar och hoppas att denna insats kommer att vara till nytta och meningsfull för våra läsare. Vänligen meddela oss nedan i kommentarfältet om hur vi gjorde.

vad är det bästa operativsystemet för en bärbar dator

Författare: Det här inlägget är skrivet av vår STH-teammedlem Swati Seela.

Rekommenderad läsning


^