Meny

Programvarehåndbok Testing av intervjuspørsmål for erfarne fagpersoner

software manual testing interview questions

Prøv Instrumentet Vårt For Å Eliminere Problemer

Ofte stilte scenariobaserte manuelle tester intervjuspørsmål for erfarne fagpersoner med detaljerte svar:

Jeg har nylig hatt denne unike opplevelsen av QA coaching (10 års erfaring) for å delta på et klient Software Testing-intervju med et ledende underholdningsselskap i Los Angeles. Nettstedet som skulle testes var et enkelt kundevendt nettsted (omtrent som en online TV-kanal) som hadde både web- og mobilkomponenter.

Programvare manuell testing Intervju spørsmål

Et konsulentselskap projiserte profiler til denne klienten for en stedet tester + koordinatorstilling men ingen av dem klarte det gjennom testintervjuprosessen. Så de bestemte seg for å samle inn QA intervju spørsmål fra de forrige deltakerne, og de ga meg et spørreskjema.

hvordan du trekker ut .7z-filer på mac

De ønsket at jeg skulle gi svarene til neste kandidat og trener det person for å lykkes i test-QA-intervjuet.

Manuell testing intervju spørsmål for erfarne

Da jeg fikk listen over spørsmål, ble jeg overrasket og ‘ikke overrasket’ samtidig. Overrasket - fordi spørsmålene var veldig enkle og en 10 år erfaren QA burde ha vært i stand til å svare på dem enkelt. Ikke så overrasket fordi QA er det feltet IT som har mest ugress etter min mening - men la oss ikke komme inn på det.

Etter å være ferdig med øvelsen, tenkte jeg at det ville være hyggelig å dele denne erfaringen med STH-leserne. For nybegynnere vil dette være god liveeksponering. For andre vil det være en vennlig påminnelse om hvor viktig grunnleggende er uansett hvor erfarne vi er.

Anbefalt lesing=> 101+ programvaretestintervjuespørsmål og svar.

Her går…..

Manuell testing Intervjuespørsmål for erfarne

De 9 vanligste QA-programvaretestingsintervjuspørsmålene for både nybegynnere og erfarne kandidater:

#Q 1) Hva er prosessen for å lage et testskript?

Svar:

Trinn 1: er å få en grundig forståelse av AUT:

  • Dette kan være ved å lese kravdokumentene grundig.
  • I mangel av dokumenter kan vi prøve å forstå hvilket referansepunkt vi har - en tidligere versjon av applikasjonen eller wire-frames eller skjermbilder

Steg 2: Etter å ha forstått kravene, lager vi en liste over hvilke områder i denne applikasjonen som må testes. Med andre ord identifiserer vi testkravene. Fokuset i dette trinnet er å identifisere 'Hva' du skal teste. Resultatet av dette trinnet er en liste over Test scenarier .

Trinn 3: Når vi har fått testscenariene, konsentrerer vi oss videre om “Hvordan” for å teste dem. Denne fasen innebærer å skrive detaljerte trinn om hvordan du tester en bestemt funksjon, hvilke data du skal legge inn ( Testdata ) og hva er forventet resultat.

Når disse tre trinnene er gjort, er vi klare for testing.

#Q 2) Hva er feltene i en feilrapport?

Svar: Følgende viktige felt bør inkluderes i a god feilrapport :

  1. En unik ID
  2. Defektbeskrivelse: en kort beskrivelse av hva feilen er.
  3. Fremgangsmåte for å reprodusere: detaljer om hvordan du kommer frem til feilen, nøyaktige testdata, tidspunktet da feilen ble funnet (hvis aktuelt) miljø: all informasjon som vil bidra til å møte problemet på nytt
  4. Modul / seksjon av applikasjonen (hvis aktuelt)
  5. Alvorlighetsgrad
  6. Skjermbilde
  7. Ansvarlig kvalitetssikring: i tilfelle spørsmål om oppfølging angående dette problemet

#Q 3) Hvordan teste en programvare som vender mot kunden?

Svar: Med et hvilket som helst program vi tester, prøver vi å se om et bestemt sett med krav blir oppfylt av applikasjonen eller ikke. Men når det gjelder et brukervendt nettsted, bortsett fra å konsentrere oss om funksjonalitet, må vi også se på noen få brukervennlige funksjoner, kanskje ytelses- og sikkerhetsaspekter også til en viss grad.

Det første testnivået er : Oppfyller nettstedet dets funksjonelle krav.

For eksempel, hvis det er et nettsted for låneadministrasjon, må vi se på - er den nye kunden i stand til å søke om et lån, er den eksisterende kunden i stand til å få tilgang til låninformasjonen sin, er den rente% som er brukt på lånebeløpet riktig, etc.

Neste testnivå er :hvor enkelt det er å bruke nettstedet, gjør alternativene logisk og oppfyller forventningene til brukeren eller ikke.

For eksempel, Hvis brukeren må passere 3-4 skjermer for å sende inn den grunnleggende informasjonen, blir de irritert, så slike problemer må løses.

En annen eksempel, etter å ha tastet inn brukernavn og passord, kan brukeren klikke på fanen - noe som betyr at kontrollen skal gå til “Logg inn” -knappen, i stedet for hvis den skal avbrytes, blir brukeren veldig irritert og opplevelsen av å bruke nettstedet er kommer til å bli kompromittert. Slike saker må fanges opp.

Ytelsestesting i det fulle omfanget kanskje ikke i omfang, men enkle situasjoner som, hvor lang tid tar søkeresultatene for å vises og hvor lang tid det tar for systemet å hente kundeinformasjon i topptimen - dette er noen eksempler på slags ting vi ønsker å holde øye med.

Sikkerhet - for nettsteder der det er sikker innlogging for å få tilgang til nettstedet, må minimum funksjonalitet rundt det testes. For eksempel, hvis jeg lar nettstedet være inaktiv i mer enn 10 minutter, er det automatisk utlogging eller ikke. Noe så grunnleggende som det bør fokuseres på.

#Q 4) Hvordan løse utfordringen med ikke å ha inngangsdokumentasjon for testing?

Svar: Hvis detaljert standarddokumentasjon som BRD og FSD ikke er tilgjengelig, må testeren være avhengig av et referansepunkt.

hva er den beste programvaren for rengjøring av datamaskiner
  • Skjermbilder
  • En tidligere versjon av applikasjonen
  • Wireframes, etc

En annen faktor som hjelper veldig, er å snakke med utviklerne eller forretningsanalytikerne (når tilgjengelig) for å få en bekreftelse på vår forståelse eller avklaringer i tilfelle tvil.

Når ingen av disse situasjonene fungerer, kan vi bare konseptualisere applikasjonen basert på vår tidligere IT-applikasjonserfaring og lage det grunnleggende settet med testskripter. Når testfasen kommer opp, kan vi sette opp en del av testsyklustiden og gjøre noe testsakshåndtering (gjør de allerede opprettede skriptene perfekte), slik at vi har dokumentet for de neste fasene.

#Q 5) Hvordan få maksimal produktivitet fra et offshore-team?

Svar: Nøkkelen er å sørge for at alle testerne kjenner til alle modulene, og at det ikke er noen kunnskapskonsentrasjon på ett sted. Å involvere alle i testmanuskripter, defektmøter og KT-økter, vil sikre at alle er klar over applikasjonen i best mulig grad.

Ved å oppmuntre til teamarbeid kan vi også få teammedlemmene til å samarbeide, hjelpe og hjelpe hverandre for bedre produktivitet.

Regelmessige oppfølgingsmøter hjelper også prosessen veldig mye.

#Q 6) Hva er rollene og ansvaret til en koordinator på stedet? Tester han / hun også?

Svar: Koordinatoren på stedet er et kontaktpunkt for offshore-teamet og til klienten for informasjon om testoppdraget.

Denne jobben inkluderer:

  • KT fra og til offshore og kunder
  • Få miljøet til å teste alt klart
  • Sanity testing, røyk testing
  • Testing - nøkkelfunksjonaliteten.
  • Feilanmeldelse - funnet av offshore-teamet
  • Feil tilordne til respektive dev
  • Presentere beregninger
  • Gir avlogging

Ja, selv en koordinator på stedet må teste.

#Q 7) Inkonsekvente feil - Hvorfor kan stedet finne det, men offshore kan det ikke og omvendt - Hvordan håndtere denne situasjonen?

Svar: Hver feil må noteres og analyseres - om den oppstår på stedet eller offshore, enten det kan repeteres eller ikke. En reell verdiøkning til en testers jobb er når vi involverer oss i Root Cause Analysis-prosessen for en feil i stedet for bare å rapportere den.

Noen av måtene vi kan håndtere denne situasjonen på er:

  • Alle teammedlemmene på stedet og offshore burde følge en retningslinje om at skjermbilder måtte tas for hver feil vi støter på - repeterbar eller ikke.
  • Hvis det er logger, systemfiler eller noe sånt, kan det hjelpe oss med å finne bevis på problemet. Vi bør prøve å finne det.
  • Til tross for alle disse trinnene, hvis vi fremdeles ikke kan fortelle hvorfor og når problemet oppstår, bør vi rapportere det til utvikleren likevel - med så mye informasjon som mulig.

#Q 8) Video- / lydrelatert testing - Hva inkluderer dette?

Svar: Hvordan tester jeg et program som har video eller lyd?

hva er det beste operativsystemet for en bærbar PC

Her er de viktige punktene du bør vurdere:

  • Tilgangsnivåer (begrenset eller ikke - passordstyrt)
  • Ulike miljøer
  • Nettleserkompatibilitet
  • Skjermoppløsninger
  • Internett-tilkoblingshastigheter
  • De spesifikke alternativene på en video - som å spille, stoppe, dempe osv.
  • Video etter størrelse
  • Svar på videoene - kommentarer (begrensninger på kommentarlengden og antall kommentarer det kan ta)
  • Videosvar på videoene
  • Grensesnitt med sosiale nettverk - Interoperabilitet
  • Bufferhastighet
  • Legge inn videoen

#Q 9) ​​Testing av mobilapplikasjoner - Hva inkluderer det kort?

Svar: Mobilapptesting Viktige testscenarier:

  • Sjekk om appen fungerer bra med flere operatører og flere enheter.
  • Brukbarheten til funksjonene på en mobilskjerm.
  • Tester det på forskjellige mobilplattformer - som Android og iOS.
  • Installasjoner, avinstallering, start av appen med nettverk og uten nettverk, testfunksjonalitet.
  • Nettverkstilkoblinger –WiFi, 2G, etc.
  • Logger på iOS iPhone-konfigurasjonsverktøy for Android Monitor.bat kan brukes til feilsøking.

Det var det. Nå var det ikke så enkelt.

Som et siste notat gjentar jeg filosofien på STH - kjenner det grunnleggende godt, resten følger automatisk.

Jeg avslutter og håper at denne innsatsen vil være gunstig og meningsfull for våre lesere. Gi oss beskjed nedenfor i kommentarfeltet om hvordan vi gjorde det.

Forfatter: Dette innlegget er skrevet av vårt STH-teammedlem Swati Seela.

Anbefalt lesing

^