40 vanlige spørsmål fra QA-intervjuer (og svar!)

Jobbintervjuer er krevende. Det er som om hvert intervjuspørsmål er utformet for å få deg ut av konkurransen.

Du bruker tid på å lese om selskapet før intervjuet, øver på svarene dine på alle spørsmålene du tror de kommer til å stille deg, og på selve intervjudagen møter du opp en time for tidlig og drikker altfor mye kaffe.

Intervjuer kan være angstfremkallende selv under de beste omstendigheter, men vi er her for å bidra til å redusere noe av angsten før intervjuet.

Denne veiledningen løfter lokket på QA-intervjuer, lister opp noen av de vanskeligste intervjuspørsmålene innen programvaretesting og utforsker noen QA-intervjuspørsmål og -svar for å hjelpe deg med å forberede deg til den store dagen.

Slik forbereder du deg til et QA-intervju

Den beste måten å forberede seg på er å vurdere evnene dine ærlig og fokusere på styrkene dine, samtidig som du erkjenner svakhetene dine.

Frisk opp definisjonene dine, forstå arbeidsmarkedet innen QA ved å lese relevante jobbveiledninger for QA-testere, gå gjennom spørsmålene og svarene nedenfor, se gjennom stillingsbeskrivelsen for QA-testeren, og husk at ansettelsesprosessen handler like mye om å finne den rette kulturtilpasningen som å finne den best kvalifiserte kandidaten. 

For å gjøre det godt i QA-intervjuet er det avgjørende å være kjent med bransjeledende programvare for testhåndtering. Disse verktøyene er ofte ryggraden i ethvert vellykket QA-prosjekt. Det kan også være nyttig å lese inspirerende artikler om programvaretesting.

Hvor lenge varer et typisk QA-intervju?

Det avhenger av intervjueren og intervjuobjektet, samt hvor raskt dere går gjennom spørsmålene.

QA-intervjuer kan ta lang tid, enten det gjelder et intervju for en stilling innen kvalitetssikring og databasetesting eller en stilling som ingeniør, analytiker, leder eller fagansvarlig. Ofte vil det være flere intervjurunder og tekniske intervjuer senere i prosessen.

Generelt vil de fleste QA-intervjuer ta én til to timer, selv om det kan være flere intervjuer gjennom hele ansettelsesprosessen. 

Liste over QA-intervjuspørsmål og -svar

Målet mitt med denne artikkelen er å hjelpe deg med å forberede deg på den typen QA-intervjuspørsmål du vil bli stilt, enten de handler om automatisering, testprosessen din eller personligheten din.

Ofte vil intervjueren være interessert i evnene dine som QA-ingeniør og tilnærmingen din til testing.

Noen QA-intervjuspørsmål vil være åpne eller virke vage. Dette er fordi intervjueren ønsker å høre om tilnærmingen din. De prøver å få et inntrykk av hva slags arbeidstaker du er, og enda viktigere, om du er den typen arbeidstaker som vil passe inn i testteamet deres.

Uten mer om og men, her er en liste over mulige QA-intervjuspørsmål og -svar som kan gi deg en idé om hvordan du kan svare. Lykke til!

1. Hvorfor bør jeg ansette deg?

Dette er et favorittspørsmål blant intervjuere over hele verden. Det er ikke et lurespørsmål – det er en innledning.

Grip denne muligheten til å vise deg fra din beste side. Snakk om hva som gjør deg lidenskapelig opptatt av QA, og hvorfor du vil gjøre jobben bedre enn noen andre i QA-teamet, takket være den unike kombinasjonen av talenter og personlighetstrekk som bare du kan tilføre rollen. Ikke bekymre deg for å være selvkritisk eller overdrevent ydmyk her. Spørsmålet er utformet for å få frem søkerens styrker. 

2. Hva er en feil?

En feil er enhver feil, unøyaktighet eller svikt i programvarekode som hindrer programvarefunksjonen i å bli utført korrekt. 

3. Hva er forskjellen mellom alvorlighetsgrad og prioritet?

Det er viktig å forstå disse forskjellene for effektiv tidsstyring. Alvorlighetsgrad viser til hvor komplisert det er å løse et problem, mens prioritet angir hvor presserende det er å håndtere det.

At et problem har høy alvorlighetsgrad, betyr ikke nødvendigvis at det har høy prioritet, og omvendt.

Her er et eksempel på et problem med høy alvorlighetsgrad og lav prioritet:

• Programmet krasjer når en sjelden brukt funksjon kjøres i eldre programvare som de fleste brukere ikke har tilgang til.

Her er et eksempel på et problem med lav alvorlighetsgrad og høy prioritet:

• Feil firmalogo vises ved oppstart. 

4. Hva er forskjellen mellom assert- og verify-kommandoer i testautomatisering?

Det er mange likheter mellom de to kommandoene. Begge kontrollerer om kodebetingelsene er sanne. Forskjellen er hva som skjer etterpå.

• Når en assert-kommando mislykkes, slutter den å kjøre kode, og testen settes på pause.
• Når en verify-kommando mislykkes, fortsetter den og kjører resten av koden.

5. Hva er forskjellen mellom kvalitetssikring, kvalitetskontroll og kvalitetstesting?

Kvalitetssikring planlegger hvordan et team og en organisasjon skal overvåke testprosessen. Kvalitetskontroll finner feil og foreslår måter å forbedre programvaren på. Testing er prosessen der kvalitetssikring og kvalitetskontroll finner feil.

Her er en relatert veiledning om forskjellen mellom kvalitetssikring og kvalitetsutvikling, samt forskjellen mellom kvalitetskontroll og kvalitetssikring.

6. Når bør QA starte?

QA bør begynne så tidlig som mulig. Jo tidligere QA-analytikere, QA-testere og QA-teamledere involveres i prosessen, desto flere problemer unngås senere i programvareutviklingssyklusen. Statiske tester kan utføres før programvaren er fullt funksjonell. 

7. Hva er livssyklusen for QA-testing?

Du kan snakke om testprosessen du kjenner best, men her er en standardversjon:

1. Krav
2. Planlegging 
3. Analyse 
4. Utforming 
5. Implementering 
6. Utførelse 
7. Konklusjon 
8. Avslutning 
   

 8. Hva er en testplan? 

En testplan er et dokument som beskriver detaljene for den planlagte testen. Før testingen begynner, angir den hvilke roller som kreves, potensielle risikoer og løsninger, samt hvilke ressurser som skal brukes.

9. Hva inneholder en testplan?

Testplaner bør inneholde:

• Omfang
• Tilnærming
• Nødvendige ressurser
• Planlagt tidsplan for testen(e) 

10. Hva er de viktigste fordelene med testautomatisering i programvareutvikling?

Testautomatisering øker effektiviteten ved å kjøre testtilfeller raskere og redusere menneskelige feil. Den forbedrer testdekningen ved å kjøre omfattende og repeterende testscenarier på tvers av ulike miljøer.

I tillegg støtter testautomatisering kontinuerlig integrasjon og levering (CI/CD), noe som muliggjør raskere utgivelser og høyere programvarekvalitet.

11. Hva ville du inkludert i en testplan for automatisering?

Siden det er en omfattende oppgave å lage en plan for testautomatisering, trenger du ikke å gå inn på alle detaljer.

Fokuser heller på noen viktige aspekter ved en testplan – for eksempel hvordan planen skal beskrive hvordan testene skal utformes, hvordan de skal kjøres, hvordan feil skal håndteres, og hvordan rapporteringen fra testautomatiseringen skal se ut.

12. Hva er et brukstilfelle?

Brukstilfeller beskriver årsak og virkning for en funksjon. De sikrer at brukerhandlingen og systemresponsen kommuniserer riktig med hverandre. 

13. Hva er en teststrategi?

Teststrategien beskriver planen for testfasen i programvareutviklingen.

I motsetning til testplanen, som beskriver én spesifikk test, dekker teststrategien hele testfasen i utviklingen og inkluderer en beskrivelse av testverktøyene, testgruppene, testprioriteringene, vedlikehold av testdokumentasjon og testsammendraget. 

14. Er teststrategier og testplaner det samme dokumentet?

Nei. Testplaner samler og organiserer testtilfeller.

Teststrategier beskriver tilnærmingen til testing. Generelt administreres teststrategier av QA-lederen eller QA-ansvarlig, mens QA-testerne administrerer testplaner.

15. Hvilke ulike typer testing finnes?

Regresjonstesting, utforskende testing, funksjonell testing, belastningstesting, integrasjonstesting, enhetstesting, testing på tvers av nettlesere, hvitboks- og svartboks-testing, volumtesting, alfatesting, betatesting og mange flere.

Se innlegget vårt om typer programvaretesting for mer informasjon om testingsteknikker.

16. Hva mener du er noen av fordelene med manuell testing?

Her er noen fordeler med manuell testing som du kan snakke om:

• Det kan være rimeligere enn automatisert testing.
• Det kan være enklere for nye team eller personer som er nye innen QA, å lære hvordan man utfører en manuell test, slik at den kan rulles ut raskere.
• På samme måte kan manuell testing være viktig i kortsiktige prosjekter når testskript ikke brukes på nytt så ofte.
• Du kan analysere produktet fra sluttbrukerens perspektiv når du utfører manuell testing.
• Testing av det grafiske brukergrensesnittet kan føles mer intuitivt og gi mer nøyaktige resultater ved manuell testing; visuell tilgjengelighet og brukerpreferanser kan være vanskelige å automatisere.

Her er en artikkel der du kan lese mer om fordelene og ulempene ved manuell og automatisert testing.

17. Hva kjennetegner et godt testtilfelle?

Et godt testtilfelle angir tydelig parameterne for testen og feilene det er ment å finne. 

18. Hva er forskjellen mellom funksjonell og ikke-funksjonell testing?

Funksjonell testing tester de viktigste delene av programvaren for å sikre at den samsvarer med krav og spesifikasjoner. Ikke-funksjonell testing tester viktige, men ikke avgjørende, aspekter ved programvaren, som lastetider, belastning og generell ytelse. 

19. Bør QA løse problemer i produksjon?

Du kan ha ulike meninger om dette, men jeg vil anbefale deg å svare «Ja».

Det er ofte bra at QA er involvert i å løse problemer i produksjon. Når det er mulig, bør de skrive testtilfeller, gjennomgå testdata og forsøke å finne problemene. Ved å involvere seg reduserer QA antallet problemer i det ferdige produktet.

20. Når du finner en feil i produksjon, hvordan sikrer du at feilen blir løst?

Det beste er å skrive et testtilfelle for feilen umiddelbart og kjøre en regresjonstest – på den måten bør alle fremtidige tester av programvaren spesifikt kontrollere om feilen finnes. 

21. Hva gjorde du i det forrige prosjektet ditt?

Det finnes ingen klare svar på dette, bare retningslinjer. Det er vanlig at intervjuere spør om karriereutviklingen og tidligere prosjekter, så lag en rask liste over punkter på forhånd, slik at du kan snakke om prosjektene som du mener representerer arbeidet ditt best.

Mitt viktigste råd er å svare så ærlig som mulig. Ikke overdriv eller undervurder bidraget ditt til tidligere team. Fremhev situasjoner der du påtok deg arbeid som QA-prosjektleder utenfor ansvarsområdet ditt, for å vise eierskap. Fortell dem hva den daglige rollen din var, hvilke verktøy du brukte, og hvordan QA-testingen gikk. 

22. Hvordan prioriterer du når du har så mange oppgaver?

Tenk på hvordan du har håndtert travle perioder tidligere. Er du en som planlegger strengt? Eller foretrekker du å disponere tiden mer løst, slik at du har rom til å tilpasse deg plutselige problemer? Igjen handler disse intervjuspørsmålene om testing mer om å avgjøre om du passer personlig inn i teamet deres. 

Hvis du føler at det å prioritere flere prosjekter er et av dine svake punkter, har Harvard Business Review en veiledning i hvordan man prioriterer riktig på jobb. 

23. Fortell meg om ditt mest utfordrende prosjekt.

Trekk pusten dypt. La alt komme tilbake til deg: følelsene, de sene kveldene med å prøve å finne problemet, det enorme antallet take-away-esker som hopet seg opp på testen din.

Dette er en utmerket anledning til å la engasjementet ditt for QA komme til uttrykk. Gå gjennom hva som skapte de største vanskelighetene for deg, hvorfor det var så vanskelig å finne løsningen, og hvor hardt du jobbet for å løse det. 

 24. Fortell meg om en gang du overså en feil.

I det første spørsmålet ba jeg deg om å vise din beste side uten å være selvbevisst. Derfor vil ikke alle spørsmål være formulert på en måte som får deg til å fremstå best mulig.

I et QA-intervju må personen som har ansvar for ansettelsesbehovene vite at potensielle teammedlemmer er åpne om å gjøre feil.

Det verste en QA-tester kan gjøre, er å opptre som om de aldri har gjort en feil. Vær åpen og ærlig. Når du sitter i et intervju, er det sikkert at du har oversett en feil eller gjort en tabbe. Fortell dem om feilene dine, hvordan du løste problemet, og hva du har lært. 

25. Hvordan ville du testet en ødelagt brødrister?

Dette er et bonusspørsmål fordi noen organisasjoner liker slike spørsmål, mens andre ikke gjør det. På den ene siden setter det intervjueren i en vanskelig situasjon, som de nesten helt sikkert ikke forventet å havne i. Fordelen er imidlertid at det krever rask tenkning utenfor boksen og lar intervjuobjektene demonstrere kreativitet. 

På grunn av spørsmålets natur kommer jeg ikke til å fortelle deg hvordan du skal teste en ødelagt brødrister. Det er opp til deg. 

26. Hvilke egenskaper er avgjørende hos ledere innen QA?

Et spørsmål som dette vil sannsynligvis være blant intervjuspørsmålene for QA-ingeniører eller lignende stillinger med fokus på ledelse. Du kan også bli stilt dette spørsmålet fordi din fremtidige leder ønsker å vite hvilke egenskaper du ser etter hos lederne dine.

Uansett er det beste svaret et ærlig svar. Tenk gjennom dette, og forbered deg på å snakke om hvilke typer arbeidsmiljøer du fungerer best i, og hvordan ledere kan bidra til å skape et slikt miljø.

Noen temaer du kan snakke om, er god kommunikasjon, aktiv lytting, ærlighet, psykologisk trygghet, myndiggjøring, autonomi, visjon og mer.

27. Hva er den viktigste testmålingen, og hvorfor?

Det finnes ikke noe riktig svar på dette spørsmålet, først og fremst fordi målingen du velger, vil avhenge av målene dine og typen test du gjennomfører – akseptansetesting vil for eksempel måle helt andre ting enn utforskende testing.

For å svare på dette spørsmålet bør du forberede deg på å snakke om standardmålinger innen QA, for eksempel «feil per test», som kan brukes på mange ulike typer testing, og hvilken innsikt denne målingen gir deg.

Forbered deg også på å snakke om begrunnelsen for å velge en bestemt måling basert på målene for testen din, målene til den overordnede organisasjonen, testmiljøet og hvordan du kan gjennomføre det.

For ekstra uttelling bør du lese Niall Lynchs artikkel om en QA-måling han har utviklet, kalt T2Q eller Time to Quality – den kan brukes ganske universelt på alle tester, er enkel å måle og forteller deg noe meningsfullt om testarbeidet ditt.

28. Hvilke mål har du for karrieren din?

Du må finne svarene på disse spørsmålene selv, men for å få noen ideer kan du lese denne artikkelen om hvordan du styrer QA-karrieren din.

29. Hva er datadrevet testing?

Datadrevet testing er en programvaretestingsteknikk som lagrer testdata i tabell- eller regnearkformat. Dette gjør det mulig for testere å kjøre flere testtilfeller ved hjelp av ett enkelt testskript, ved å hente datainndata dynamisk fra eksterne kilder som databaser, regneark eller XML-filer. Testresultatene logges deretter i det samme strukturerte formatet, noe som gjør det enklere å analysere ytelsen på tvers av ulike datasett.

30. Hvordan implementeres datadrevet testing?

I tradisjonell testing er testinndata hardkodet, noe som begrenser fleksibilitet og skalerbarhet. Datadrevet testing fjerner denne begrensningen ved å parameterisere testtilfeller og bruke globale variabler som leser direkte fra eksterne datakilder. Denne tilnærmingen sikrer testdekning for ulike inndatascenarioer uten at testskriptet må endres. I et automatiseringsrammeverk som Selenium kan testere for eksempel bruke eksterne CSV- eller Excel-filer til å legge inn dynamiske verdier i testtilfeller, noe som muliggjør omfattende validering med minimalt vedlikehold av skriptet.

31. Hva er en sporbarhetsmatrise, og hvorfor er den viktig i programvaretesting?

En sporbarhetsmatrise er et dokument som brukes i programvaretesting for å sikre at alle krav er koblet til tilsvarende testtilfeller. Den bidrar til å spore testdekningen, slik at ingen krav forblir utestet og hull i valideringen unngås. Dette er spesielt nyttig ved konsekvensanalyse når det oppstår endringer, fordi teamene kan identifisere hvilke testtilfeller som må oppdateres eller kjøres på nytt.

32. Hvordan bekrefter du at databasebegrensninger, for eksempel fremmednøkler eller unikhet, fungerer som forventet?

Jeg vil forsøke å sette inn eller oppdatere poster som skal bryte hver begrensning – for eksempel forsøke å sette inn en rad med en fremmednøkkel som ikke finnes, eller opprette duplikatoppføringer der det finnes en unik indeks – og bekrefte at databasen avviser dem. Ved å gå gjennom feillogger og bekrefte at databasen returnerer de riktige feilkodene, kan man sikre at begrensningene håndheves.

33. Hva er de tre typene sporbarhetsmatriser, og hvilken rolle spiller sporbarhetsmatrisen for å sikre grundig testing?

Fremoversporbarhetsmatrisen (FTM), som sikrer at hvert krav har tilordnede testtilfeller for fullstendig dekning; bakoversporbarhetsmatrisen (BTM), som sikrer at hvert testtilfelle kan spores tilbake til et krav for å forhindre redundans; og den toveis sporbarhetsmatrisen (BTM), som kombinerer fremover- og bakoversporbarhet for å bekrefte full testdekning og eliminere unødvendige testtilfeller. Sporbarhetsmatrisen bidrar til å sikre fullstendig testdekning ved å knytte testtilfeller til prosjektkrav og bekrefte at all funksjonalitet er testet. Den gjør det mulig for teamene å spore endringer i kravene og deres innvirkning på testtilfellene, noe som reduserer risikoen for at kritisk funksjonalitet blir oversett. I tillegg støtter den kvalitetssikring ved å identifisere hull, forhindre redundante tester og sikre at alle krav er validert før implementering.

34. Hvordan skiller utforskende testing seg fra skriptbasert testing, og hva er de viktigste fordelene?

Utforskende testing er en uskriptet testtilnærming der testere aktivt utforsker applikasjonen for å identifisere feil, i motsetning til skriptbasert testing, som følger forhåndsdefinerte testtilfeller. Den gir større fleksibilitet og avdekker uventede problemer som strukturerte tester kan overse. Denne tilnærmingen bidrar til å oppdage brukervennlighetsproblemer, kanttilfeller og nye feil som nylige endringer har introdusert.

35. Hva er de viktigste forskjellene mellom svartbokstesting og hvitbokstesting?

Svartbokstesting fokuserer på å verifisere programvarefunksjonalitet uten kjennskap til den interne kodestrukturen, og baserer seg på inndata og forventede utdata. I motsetning til dette krever hvitbokstesting forståelse av den interne koden, logikken og strukturen for å utforme testtilfeller. Mens svartbokstesting vanligvis brukes til testing på brukernivå og funksjonell testing, egner hvitbokstesting seg bedre til enhetstesting, analyse av kodedekning og sikkerhetstesting.

36. Hva er belastningstesting, stresstesting og volumtesting?

Belastningstesting, stresstesting og volumtesting er ytelsesteknikker som evaluerer hvordan et system oppfører seg under ulike forhold.

• Belastningstesting måler systemytelsen under forventet brukerbelastning for å sikre at systemet kan håndtere normal trafikk uten problemer.
• Stresstesting presser systemet utover grensene ved å påføre ekstrem arbeidsbelastning for å identifisere bristepunkter og systemets evne til å gjenopprettes etter feil.
• Volumtesting evaluerer systemets evne til å behandle store datamengder og sikrer stabilitet og effektivitet ved håndtering av høy databelastning.

Hver test bidrar til å vurdere systemets pålitelighet, skalerbarhet og robusthet under varierende forhold.

37. Hvordan bruker du BVA for å sikre grundig dekning av inndataområder?

Grenseverdianalyse fokuserer på å teste ytterpunktene i inndataområder, for eksempel minimums-, maksimums-, like under-, like over- og gyldige grenseverdier. Hvis et skjemafelt for eksempel godtar verdier fra 1 til 100, vil jeg vanligvis teste 0, 1, 2, 99, 100 og 101 (hvis relevant) for å sikre at systemet håndterer alle kritiske grenser korrekt.

38. Kan du forklare hvordan ekvivalensklasseinndeling bidrar til å optimalisere utformingen av testtilfeller?

Ekvivalensklasseinndeling grupperer inndata i sett som forventes å oppføre seg likt – dette forhindrer redundante tester. Hvis gyldige inndata for et passordfelt for eksempel er 8 til 16 tegn, kan du teste én gyldig lengde og én ugyldig lengde på hver side av dette området, i stedet for å kontrollere hvert enkelt tall fra 1 til 20. Det sparer tid, samtidig som det sikrer bred dekning.

39. Når vil du bruke en beslutningstabelltilnærming, og hvordan strukturerer du testtilfellene dine deretter?

Beslutningstabeller egner seg best for scenarioer med flere betingelser og utfall – for eksempel komplekse forretningsregler. Jeg identifiserer først alle mulige betingelser og setter deretter opp en tabell over handlingene eller utfallene som utløses av hver kombinasjon. Denne metoden gir en tydelig og systematisk oversikt over alle mulige forløp, slik at ingen logisk gren blir oversett.

40. Hva er erfaringen din med å teste ulike typer API-er, og hvilke utfordringer møter du vanligvis med SOAP sammenlignet med REST?

REST er vanligvis mer lettvektig, bruker ofte JSON og passer godt sammen med nettbaserte integrasjoner. SOAP er mer rigid, bruker XML og baserer seg på WSDL-definisjoner. Utfordringene kan blant annet være å håndtere komplekse autentiseringsmetoder, tolke XML kontra JSON og forholde seg til strengere standarder i SOAP-baserte tjenester. Jeg har erfart at automatiserte tester for REST ofte trenger omfattende dekning av ulike HTTP-metoder, mens SOAP-tester kan kreve nøye validering av XML-skjemaer.

Hva skjer videre?

Når alt kommer til alt, handler de fleste QA-intervjuer like mye om å vise hvem du er, som om hva du kan. Ja, du må ha kontroll på viktige konsepter som automatisert kontra manuell testing eller alvorlighetsgrad kontra prioritet, men ikke undervurder verdien av selvinnsikt og ærlig historiefortelling.

Ansettelsesteamene ønsker noen som kan samarbeide effektivt, ta ansvar for egne feil og holde prosjekter på rett spor under press.

Ha disse spørsmålene i bakhodet, men husk også at hvert intervju går begge veier – benytt muligheten til å finne ut om selskapet passer for deg. Hvis du møter forberedt, nysgjerrig og klar til å tilpasse deg, gir du deg selv best mulig sjanse til å få og trives i din nye QA-stilling.

Abonner på The CTO Clubs nyhetsbrev for flere intervjuspørsmål og innsikt i QA.