software manual testing interview questions
De hyppigst stillede scenariebaserede manuelle testinterviewspørgsmål til de erfarne fagfolk med detaljerede svar:
Jeg har for nylig haft denne unikke oplevelse af QA coaching (10 års erfaring) til at deltage i et klient Software Testing-interview med et førende underholdningsfirma i Los Angeles. Webstedet, der skulle testes, var et simpelt kundeorienteret websted (som en online tv-kanal), der havde både web- og mobilkomponenter.
Et konsulentfirma projicerede profiler til denne klient for en onsite tester + koordinatorposition men ingen af dem kom igennem testinterviewsprocessen. Så de besluttede at indsamle QA interview spørgsmål fra de tidligere deltagere, og de gav mig et spørgeskema.
hvordan man tilføjer svn-lager i formørkelse
De ville have mig til at give svarene til den næste kandidat og coach det person til at få succes i testet QA interview.
Da jeg fik listen over spørgsmål, blev jeg overrasket og 'ikke overrasket' på samme tid. Overrasket - fordi spørgsmålene var virkelig grundlæggende, og en 10 års erfaren kvalitetssikring burde have været i stand til at besvare dem let. Ikke så overrasket, fordi QA er det felt inden for IT, der efter min mening har mest ukrudt - men lad os ikke komme ind på det.
Efter at være færdig med øvelsen, tænkte jeg, at det ville være rart at dele denne oplevelse med STH-læserne. For begyndere vil dette være en god liveeksponering. For andre vil det være en venlig påmindelse om, hvor vigtigt det er grundlæggende er uanset hvor erfarne vi er.
Anbefalet læsning=> 101+ Software Testing Interview Spørgsmål og svar.
Her går ... ..
Manuel test Interviewspørgsmål for erfarne
9 mest almindelige QA-softwaretest Interviewspørgsmål for begyndere såvel som erfarne kandidater:
#Q 1) Hvad er processen til oprettelse af et testscript?
Svar:
Trin 1: er at få en grundig forståelse af AUT:
- Dette kan være ved at læse kravsdokumenterne grundigt.
- I mangel af dokumenter kan vi prøve at forstå ethvert referencepunkt, vi har - en tidligere version af applikationen eller trådrammer eller skærmbilleder
Trin 2: Efter at have forstået kravene, laver vi en liste over, hvilke områder i denne applikation der skal testes. Med andre ord identificerer vi testkravene. Fokus i dette trin er at identificere “Hvad” der skal testes. Resultatet af dette trin er en liste over Test scenarier .
Trin 3: Når vi først har testscenarierne, koncentrerer vi os derefter om “Hvordan” vi tester dem. Denne fase involverer at skrive detaljerede trin om, hvordan man tester en bestemt funktion, hvilke data der skal indtastes ( Testdata ) og hvad er det forventede resultat.
Når disse 3 trin er færdige, er vi klar til test.
#Q 2) Hvad er felterne i en fejlrapport?
Svar: Følgende vigtige felter skal medtages i a god fejlrapport :
- Et unikt ID
- Defektbeskrivelse: en kort beskrivelse af, hvad fejlen er.
- Skridt til at reproducere: detaljer om, hvordan man kommer frem til fejlen, nøjagtige testdata, det tidspunkt, hvor fejl blev fundet (hvis relevant) miljø: alle oplysninger, der kan hjælpe med at genopstå problemet
- Modul / afsnit af applikationen (hvis relevant)
- Alvorlighed
- Skærmbillede
- Ansvarlig QA: i tilfælde af eventuelle opfølgningsspørgsmål vedrørende dette spørgsmål
#Q 3) Hvordan testes en kundeorienteret software?
Svar: Med enhver applikation, som vi tester, forsøger vi at se, om et bestemt sæt krav opfyldes af applikationen eller ej. Men når det kommer til et brugervendt websted, bortset fra at koncentrere os om funktionalitet, er vi også nødt til at se på et par brugervenlige funktioner, måske ydeevne og sikkerhedsaspekter også til en vis grad.
Det første testniveau er : Opfylder webstedet dets funktionelle krav.
For eksempel, hvis det er et lånestyringssted, skal vi se på - er den nye kunde i stand til at ansøge om et lån, er den eksisterende kunde i stand til at få adgang til deres låninfo, er den rente%, der anvendes på lånebeløbet korrekt osv.
Det næste testniveau er :hvor let er det at bruge webstedet, gør indstillingerne logisk og imødekommer brugerens forventninger eller ej.
For eksempel, hvis brugeren skal passere 3-4 skærme for at indsende de grundlæggende oplysninger, bliver de irriterede, så sådanne problemer skal løses.
En anden eksempel, efter at have indtastet brugernavn og adgangskode, kan brugeren muligvis klikke på fanen - hvilket betyder at kontrollen skal gå til “Log ind” -knappen, i stedet for hvis den vil annullere, bliver brugeren virkelig irriteret, og oplevelsen af at bruge siden er vil blive kompromitteret. Sådanne problemer skal fanges.
Test af ydeevne i det fulde omfang er muligvis ikke i omfang, men enkle situationer som, hvor lang tid tager søgeresultaterne at blive vist, og hvor lang tid tager det for systemet at hente en kundeinfo i spidsbelastningen - dette er et eksempel på slags ting, vi gerne vil holde øje med.
selen find element ved css-vælger
Sikkerhed - for websteder, hvor der er et sikkert login for at få adgang til webstedet, skal minimumsfunktionaliteten omkring det testes. For eksempel, hvis jeg lader siden være inaktiv i mere end 10 minutter, er det automatisk at logge af eller ikke. Noget så grundlæggende som det skal fokuseres på.
#Q 4) Hvordan overvindes udfordringen med ikke at have inputdokumentation til testning?
Svar: HVIS den detaljerede standarddokumentation som BRD og FSD ikke er tilgængelig, skal testeren afhænge af et referencepunkt.
- Skærmbilleder
- En tidligere version af applikationen
- Wireframes osv
En anden faktor, der hjælper enormt, er at tale med udviklerne eller forretningsanalytikerne (når de er tilgængelige) for at få en bekræftelse på vores forståelse eller afklaringer i tilfælde af tvivl.
Når ingen af disse situationer fungerer, kan vi bare konceptualisere applikationen baseret på vores tidligere it-applikationsoplevelse og oprette det grundlæggende sæt testscripts. Når testfasen kommer op, kan vi indstille en del af testcyklustiden og lave nogle test case management (gøre de allerede oprettede scripts perfekte), så vi har dokumentet til de næste faser.
#Q 5) Sådan får du maksimal produktivitet fra et offshore-team?
Svar: Nøglen er at sikre, at alle testere kender til alle modulerne, og at der ikke er nogen videnkoncentration ét sted. At inddrage alle i test script peer reviews, defekt møder og KT sessioner vil sikre, at alle er opmærksomme på applikationen i bedst muligt omfang.
Ved at opmuntre begrebet teamwork kan vi også få teammedlemmerne til at samarbejde, hjælpe og hjælpe hinanden til bedre produktivitet.
Regelmæssige opfølgningsmøder hjælper også processen meget.
#Q 6) Hvad er rollerne og ansvaret for en koordinator på stedet? Tester han / hun også?
Svar: Koordinatoren på stedet er et kontaktpunkt for offshore-teamet og til klienten for enhver information vedrørende testopgaverne.
Dette job inkluderer:
oracle pl / sql interview spørgsmål og svar til 7 års erfaring
- KT fra og til offshore og kunder
- At få miljøet til at teste alt klar
- Sanity test, røg test
- Test - nøglefunktionaliteten.
- Bug review - fundet af offshore-teamet
- Fejl tildeles til den respektive dev
- Præsentation af målinger
- Tilbyder afmelding
Ja, selv en koordinator på stedet skal teste.
#Q 7) Inkonsekvente bugs - Hvorfor kan stedet finde det på stedet, men offshore kan det ikke og omvendt - Hvordan håndteres denne situation?
Svar: Hver fejl skal noteres og analyseres - om den opstår på stedet eller offshore, hvad enten den kan gentages eller ej. En reel værdi-tilføjelse til en testers job er, når vi involverer os i Root Cause Analysis-processen for en fejl snarere end blot at rapportere den.
Nogle af måderne vi kan håndtere denne situation på er:
- Alle teammedlemmer på stedet og offshore skal følge en retningslinje om, at skærmbilleder skulle tages for hver fejl, vi støder på - gentagelig eller ej.
- Hvis der er logfiler, systemfiler eller noget lignende, kan det hjælpe os med at finde evidens for problemet - vi skal prøve at finde det.
- På trods af alle disse trin, hvis vi stadig ikke kan fortælle hvorfor og hvornår problemet opstår, bør vi rapportere det til udvikleren alligevel - med så mange oplysninger som vi kan.
#Q 8) Video- / lydrelateret test - Hvad inkluderer dette?
Svar: Hvordan tester jeg et program, der har video eller lyd?
Her er de vigtige punkter at overveje:
- Adgangsniveauer (begrænset eller ikke - adgangskodestyret)
- Forskellige miljøer
- Browser kompatibilitet
- Skærmopløsninger
- Internetforbindelseshastigheder
- De specifikke muligheder på en video - som afspilning, stop, lydløs osv.
- Video efter størrelse
- Svar på videoerne - kommentarer (begrænsninger i kommentarlængden og antallet af kommentarer, det kan tage)
- Videosvar til videoerne
- Interface med sociale netværkssider - Interoperabilitet
- Buffningshastighed
- Integrering af videoen
#Q 9) Test af mobilapplikationer - Hvad inkluderer det kort?
Svar: Test af mobilapps Vigtige testscenarier:
- Kontroller, om appen fungerer godt med flere operatører og flere enheder.
- Brugbarheden af funktionerne på en mobilskærm.
- Test det på forskellige mobile platforme - som Android og iOS.
- Installationer, afinstallation, start af appen med netværk og uden netværk, testfunktionalitet.
- Netværksforbindelser –WiFi, 2G osv.
- Logfiler i iOS iPhone-konfigurationsværktøj til Android Monitor.bat kan bruges til fejlfinding.
Det var det. Nu var det ikke så simpelt.
Som en sidste note gentager jeg filosofien på STH - kender det grundlæggende godt, resten følger automatisk.
Jeg konkluderer og håber, at denne indsats vil være gavnlig og meningsfuld for vores læsere. Giv os besked nedenfor i kommentarfeltet om, hvordan vi gjorde det.
Forfatter: Dette indlæg er skrevet af vores STH-teammedlem Swati Seela.
Anbefalet læsning
- Interviewspørgsmål og svar
- Nogle interessante spørgsmål om software-test Interview
- Sådan forberedes du på software-testinterview
- QA-softwaretestressourcer og downloads
- Bedste softwaretestværktøjer 2021 (QA Test Automation Tools)
- 20 enkle spørgsmål til kontrol af din software Test af grundlæggende viden (Online Quiz)
- Software Testning QA Assistant Job
- Hvad er det bedste øjeblik i din testkarriere? - Svar på sådanne 14 interessante interviewtest til softwaretest