Topp 60 SDET-intervjuspørsmål og -svar (2026)

by: Thomas Hamilton Thomas Hamilton
Hours oppdatert

SDET-intervjuspørsmål og -svar

Å gjøre seg klar til et testintervju betyr å forutse utfordringer og forventninger. SDET-intervjuspørsmål avslører hvordan kandidater tenker, validerer kvalitet, samarbeider og konsekvent oversetter automatiseringskunnskap til pålitelige ingeniørresultater.

Disse rollene åpner for sterke karriereveier etter hvert som programvarekvaliteten utvikler seg med kontinuerlig levering. Arbeidsgivere verdsetter teknisk erfaring, domeneekspertise og analyser oppnådd i feltet.ping Nyutdannede, ingeniører på mellomnivå og seniorfagfolk anvender ferdigheter, svarer på vanlige spørsmål og svar, støtter team og løser komplekse tekniske utfordringer for seniorledere. Les mer ...

👉 Gratis PDF-nedlasting: SDET-intervjuspørsmål og -svar

De beste SDET-intervjuspørsmålene og -svarene

1) Hva er rollen til en SDET, og hvordan skiller den seg fra en manuell tester?

En programvareutviklingsingeniør i testing (SDET) er ansvarlig for å sikre programvarekvalitet ved å integrere begge deler ferdigheter i programvareutvikling og testekspertiseI motsetning til en tradisjonell manuell tester, skriver en SDET automatiserte testskript, bygger og vedlikeholder testrammeverk, og deltar ofte i design- og utviklingsdiskusjoner tidlig i livssyklusen. SDET-er forventes å automatisere repeterende tester, bygge verktøy og bidra til å forbedre testinfrastrukturen, mens manuelle testere primært utfører tester manuelt og fokuserer på utforskende eller ad hoc-testing.

Viktige forskjeller:

Aspekt SDET Manuell tester
Kodingsinvolvering Høyt Lav eller ingen
Testautomasjon Primært fokus Minimum
Livssyklusinvolvering Gjennom hele SDLC Etterutvikling
Kunnskap om verktøy/rammeverk Påkrevd Valgfritt

2) Forklar programvaretestingslivssyklusen (STLC).

Programvaretestingslivssyklusen (STLC) er en serie definerte faser som veileder hvordan programvare testes. Det begynner med forståelse krav, beveger seg deretter gjennom planlegging, design, utførelse, trackongen av defekter og testavslutningHver fase har spesifikke leveranser, mål og kriterier for inn- og utgang. STLC sørger for at testaktivitetene er systematiske, målbare og i tråd med programvarens utgivelsesplan.

Typiske STLC-faser:

  1. Kravsanalyse
  2. Testplanlegging
  3. Test case utvikling
  4. Miljøoppsett
  5. Test utførelse
  6. Feilmelding
  7. Testavslutning

3) Hva er forskjellen mellom prioritet og alvorlighetsgrad av en feil?

Alvorlighetsgrad beskriver virkningen av en feil på applikasjonen – hvor negativt den påvirker systemets funksjonalitet. Prioritet indikerer hvor raskt en feil bør fikses, ofte basert på forretningsbehov. En feil med høy alvorlighetsgrad kan ødelegge en kjernefunksjon, mens en feil med høy prioritet kan trenge umiddelbar oppmerksomhet på grunn av kundepåvirkning eller utgivelsestidslinjer.

Eksempel: En skrivefeil i brukergrensesnittet har lav alvorlighetsgrad, men kan ha høy prioritet hvis den vises på en markedsføringsside.

4) Beskriv elementene i en god feilrapport.

En sterk feilrapport bør være klar, konsis og handlingsrettetDe viktigste komponentene inkluderer:

  • TittelKort oppsummering av feilen
  • Tekniske beskrivelserHva som var forventet kontra hva som skjedde
  • Fremgangsmåte for å reprodusereTydelige nummererte trinn
  • MiljøOS, nettleser, versjon
  • Skjermbilder/loggerBevis som hjelper med feilsøking
  • Alvorlighetsgrad og prioritet

Gode ​​feilrapporter hjelper utviklere med å raskt forstå og fikse problemer.

5) Hva er testautomatisering, og hvorfor er det viktig?

Testautomatisering bruker verktøy og skript for å utføre repeterende testtilfeller uten menneskelig inngripen. Det forbedrer konsistens, hastighet, testdekningog ressurseffektivitet – spesielt for regresjonstesting og kontinuerlige leveringsprosesser. Automatisering er avgjørende for storskalaapplikasjoner der manuell testing alene ikke er tilstrekkelig.

6) Forklar forskjellen mellom svartbokstesting og hvitbokstesting.

Black-box testing verifiserer at applikasjonen oppfører seg som forventet uten kjennskap til intern kode, med fokus på input og output. White-box testing innebærer testing av interne strukturer (som kodestier, løkker og grener), noe som krever programmeringskunnskap. En testsuite kombinerer ofte begge deler for å sikre omfattende dekning.

7) Hva er kontinuerlig integrasjon (CI), og hva er dens betydning i testing?

Kontinuerlig integrasjon er en praksis der kodeendringer integreres i et delt repository ofte (ofte flere ganger per dag). Hver endring utløser automatiserte bygg og tester – noe som muliggjør tidlig oppdagelse av problemer, opprettholder høy kodekvalitet og støtter raske tilbakemeldingsløkker i utviklingen. CI er nøkkelen til pålitelig automatiseringstesting og DevOps-arbeidsflyter.

8) Hvordan ville du håndtert ustabile automatiserte tester i din suite?

Ustabile tester – tester som noen ganger består og noen ganger mislykkes uten kodeendringer – undergraver tilliten. Løsninger inkluderer:

  • Stabilisering av miljøavhengigheter
  • Unngå hardkodede ventetider
  • Bruk av eksplisitte ventinger/påstander
  • Isolering av tester fra eksterne systemer

Ustabile tester bør enten fikses, settes i karantene eller merkes for å redusere støy i resultatene.

RELATERTE ARTIKLER

9) Forklar sideobjektmodellen (POM) i testautomatisering.

Sideobjektmodell (POM) er et designmønster som innkapsler nettsideelementer som objektklasser med metoder som beskriver atferd. POM forbedrer vedlikehold og lesbarhet ved å skille testlogikk fra sidestruktur, noe som forenkler oppdateringer når brukergrensesnittet endres.

10) Hva er kjernelagene i et automatiseringsrammeverk?

Et effektivt automatiseringsrammeverk inneholder vanligvis lag for:

  • Test skript
  • Sideobjekter / UI-modeller
  • Verktøy (hjelpere, ventehåndterere)
  • Konfigurasjonsstyring
  • Rapportering
  • Integrasjon med CI/CD-verktøy

Denne modulariseringen muliggjør tydelige ansvarsområder og enklere forbedringer.

11) Hvordan går du frem for API-testing?

API-testing validerer kommunikasjon mellom tjenester. Du bør bekrefte:

  • Statuskoder for svar
  • Korrektheten av svarteksten
  • Skjemavalidering
  • Autentisering/autorisasjon
  • Resultatmålinger

Vanlige verktøy inkluderer Postman, Vær tryggog Karate.

12) Hva er programvareutviklingslivssyklusen (SDLC), og hvordan passer testing inn i den?

SDLC er hele prosessen med å planlegge, lage, teste, distribuere og vedlikeholde programvare. Testing er integrert i flere SDLC-stadier – fra kravanalyse til utgivelse – og bidrar til å sikre programvarekvalitet før levering til brukeren. Automatiseringsrammeverk og CI/CD oppmuntrer til tidligere testutførelse.

13) Hvordan ville du designe et skalerbart automatiseringsrammeverk fra bunnen av?

Viktige faktorer når man utformer et skalerbart rammeverk inkluderer:

  • modularitetgjenbrukbare komponenter
  • vedlikeholdbarhet: tester som enkelt kan oppdateres
  • CI/CD-integrasjon
  • Støtte for parallell utførelse
  • Omfattende rapportering
  • Støtte for flere nettlesere/enheter

Et godt designet rammeverk akselererer testutførelsen og tilpasser seg prosjektets vekst.

14) Forklar forskjellen mellom enhetstesting, integrasjonstesting og systemtesting.

Testtype Formål Omfang
Enhetstesting Test individuelle komponenter Utviklernivå
Integrasjonstesting Valider grensesnitt mellom moduler Flere moduler
Systemtesting Valider hele systemet mot krav Ende til ende

Hver type har en unik rolle i å sikre den generelle programvarekvaliteten.

15) Hvilke programmeringsspråk brukes vanligvis av SDET-er?

SDET-er bruker ofte språk som Java, Pythonog JavaScript på grunn av deres rike testøkosystem og rammeverk. Disse språkene støtter populære verktøy som Selenium, JUnit/TestNG (Java), spørsmål (Python), Og Dramatiker/Cypress (JavaManus).

16) Hvordan sikrer du kodekvalitet i testautomatiseringsskript?

Å sikre kodekvalitet i automatiseringsskript er avgjørende for langsiktig vedlikehold og skalerbarhet. Skript av høy kvalitet reduserer falske positiver, forenkler feilsøking og forbedrer påliteligheten.

For å opprettholde kodekvaliteten:

  1. Følg konsistente kodestandarder (navnekonvensjoner, innrykk, kommentarer).
  2. Implementer kodegjennomganger før du slår sammen skript.
  3. Bruk designmønstre som sideobjektmodell eller fabrikkmønster.
  4. Bruk verktøy for statisk kodeanalyse (SonarQube, ESLint).
  5. Skriv gjenbrukbare og modulære funksjoner.
  6. Innlemme linting og versjonskontrollkroker å håndheve disiplin.

Eksempel: I en Selenium prosjektet, sørg for at lokaliseringsenheter og handlinger lagres i gjenbrukbare sideklasser i stedet for direkte i testtilfeller.

17) Hva er forskjellige typer rammeverk for testautomatisering?

Automatiseringsrammeverk er strukturer som definerer hvordan tester organiseres og utføres. Nedenfor er hovedtypene og deres fordeler:

Rammetype Tekniske beskrivelser Fordeler
Lineær (opptak-avspilling) Enkle manus innspilt sekvensielt Rask oppstart, minimal oppsett
Modulært rammeverk Testskript delt inn i moduler Enklere vedlikehold
Data drevet Testdata lagret eksternt (Excel, DB) Testfleksibilitet
Søkeorddrevet Bruker nøkkelord for operasjoner Ikke-programmerere kan delta
Hybrid Kombinerer datadrevet og søkeorddrevet Høy gjenbrukbarhet
Atferdsdrevet (BDD) Bruker naturlig språksyntaks (Cucumber, Oppfør deg) Forretningslesbare scenarier

Moderne SDET-prosjekter bruker ofte hybrid or BDD rammeverk for bedre vedlikehold og kommunikasjon mellom QA og utviklere.

18) Forklar livssyklusen til en defekt.

Ocuco Defektens livssyklus (også kalt feillivssyklus) definerer stadier en feil går gjennom fra identifisering til lukking.

Stadier inkluderer:

  1. Ny – Testeren logger en feil.
  2. Tildelt – Utvikler vurderer eierskap.
  3. Åpent / Pågår – Utvikleren jobber med løsningen.
  4. Fikset – Problemet er løst.
  5. retest – Testeren validerer rettelsen.
  6. Verifisert / Gjenåpnet – Bekreftet eller rapportert på nytt hvis vedvarende.
  7. Stengt – Problemet ble løst.

Å opprettholde riktig feilstatus hjelper team med å prioritere og track fremgang nøyaktig i verktøy som JIRA eller Bugzilla.

19) Hva er de viktigste forskjellene mellom Selenium og Cypress?

Aspekt Selenium Cypress
Språkstøtte Java, Python, C#, JavaManus osv. JavaKun skript
Utførelsesmiljø Fungerer utenfor nettleseren via WebDriver Kjører inne i nettleseren
Speed Litt tregere Raskere utførelse
Støtte for flere nettlesere Utmerket Begrenset (hovedsakelig krombasert)
Architecture Klient server Direkte DOM-manipulasjon
Best For Komplekse, storskala rammeverk Front-end-fokuserte, moderne webapper

Konklusjon: Selenium er fortsatt best for fleksibilitet på tvers av språk, mens Cypress tilbyr raskere, utviklervennlig testing for moderne JavaSkriptapplikasjoner.

20) Hvordan integrerer man automatiserte tester i en CI/CD-pipeline?

Integrering av automatisering med CI/CD sikrer at alle bygg gjennomgår testing automatisk. Trinnene inkluderer:

  1. Send kode til depotet (f.eks. GitHub).
  2. CI-server (JenkinsGitLab CI Azure DevOps) utløserbygging.
  3. Kjør testpakken ved hjelp av skript (Maven, npm, pytest).
  4. Publiser rapporter (HTML, Allure, Extent-rapporter).
  5. Merk bygging som bestått/ikke bestått basert på testresultater.

Denne prosessen muliggjør tidlig feildeteksjon, kontinuerlig tilbakemeldingog raskere utgivelser – i samsvar med DevOps-prinsippene.

21) Hva er TestNG, og hvorfor er det populært for automatisert testing?

TestNG (Test neste generasjon) er en Java testrammeverk inspirert av JUnit men designet for mer fleksibilitet.

Viktige funksjoner:

  • Støtter parallell testutførelse
  • Gir merknader (@BeforeClass, @Test, @DataProvider)
  • Muliggjør parameterisering
  • Tilbud kraftig rapportering
  • muliggjør kranping og avhengighetskontroll

Eksempel:

@Test(groups={"smoke"})
public void verifyLogin() {
      // test steps
}

Skalerbarheten og den rene strukturen gjør den ideell for testprosjekter på bedriftsnivå.

22) Hvordan ville du utforme et datadrevet testrammeverk ved hjelp av Selenium og Excel?

A datadrevet rammeverk skiller testlogikk fra testdata, slik at den samme testen kan kjøres med flere inndatasett.

Nærme seg:

  1. Lagre input/output-data i Excel eller CSV.
  2. Bruk Apache POI or Åpne CSV å lese data.
  3. Send data til tester gjennom en løkke.
  4. Generer rapporter per dataiterasjon.

Fordeler:

  • Gjenbrukbarhet og fleksibilitet.
  • Effektiv regresjonsutførelse.
  • Forenklet vedlikehold.

Eksempel på bruk: Påloggingsvalidering med forskjellige brukernavn-passord-kombinasjoner lagret i Excel.

23) Hva er formålet med et teststrategidokument?

Ocuco Teststrategi er et dokument på overordnet nivå som beskriver den overordnede testtilnærmingen for prosjektet. Det dekker:

  • Omfang og mål
  • Testnivåer (enhet, integrasjon, system, UAT)
  • Test miljøoppsett
  • Verktøy, målinger og automatiseringsomfang
  • Risikoreduserende strategier
  • Inn- og utreisekriterier

Det sikrer samsvar mellom interessenter og definerer en tydelig testvisjon.

24) Forklar hvordan REST API-validering fungerer i automatiserte tester.

API-validering innebærer å verifisere forespørsels-svar-atferd. Bruk av verktøy som RestAssured, kan du teste REST-endepunkter effektivt.

Nøkkelvalideringer:

  • status Code: 200 OK, 404 Ikke funnetOsv
  • Svartekst: Innholdsstruktur og verdier.
  • Overskrifter: Autentiseringstokener, CORS, osv.
  • Skjema: JSON/XML-skjemavalidering.

Eksempel:

given().get("/users")
.then().statusCode(200)
.body("data[0].id", equalTo(1));

Denne tilnærmingen sikrer at backend-systemet oppfører seg riktig og sikkert før UI-integrasjon.

25) Hva er forskjellen mellom røyktesting og tilregnelighetstest?

Kriterier Røykprøving Sanitetstesting
Formål Bekreft grunnleggende stabilitet i konstruksjonen Valider spesifikke feilrettinger
Dybde Grunt og bredt Smal og dyp
Fremført av QA ingeniører QA ingeniører
Egnethet for automatisering Høyt Ofte manuell
Når utført Etter nybygg Etter mindre endringer

Sammendrag: Røyktester bekrefter at bygget er testbart; tilregnelighetstester bekrefter at nylige rettelser ikke ødela funksjonaliteten.

26) Hvordan ville du utforme et rammeverk for testautomatisering for en mikrotjenestearkitektur?

Mikrotjenester introduserer flere uavhengige tjenester som kommuniserer via API-er. Derfor bør automatiseringsrammeverk fokusere på API-nivåvalidering, contract-testingog integrasjonstesting.

Nærme seg:

  1. Bruk Vær trygg, Postmaneller Karate for API-automatisering.
  2. Vedlikeholde testdata og miljøisolering ved hjelp av Docker-containere.
  3. Implementere tjenestevirtualisering (F.eks WireMock) for utilgjengelige tjenester.
  4. Integrer med CI / CD-rørledninger for kontinuerlig validering av distribusjon.
  5. inkluderer medtract-testing verktøy (f.eks. Pact) for å sikre API-kompatibilitet.

Eksempel: For en e-handelsapp, valider hver tjeneste – autentisering, katalog, bestilling og betaling – uavhengig via API-automatiseringspakker.

27) Forklar hvordan du kan oppnå parallell utførelse i Selenium.

Parallell utførelse reduserer total utførelsestid ved å kjøre flere testtilfeller samtidig.

Metoder:

  • TestNG Parallell utførelse: Definer parallelle tester i testng.xml.
  • Selenium Nett: Kjør tester på tvers av flere nettlesere/noder.
  • Plattformer for skytesting: Bruk tjenester som BrowserStack eller Sauce Labs for distribuerte kjøringer.
  • Docker-Selenium Oppsett: Opprett containeriserte noder for skalerbar utførelse.

Eksempel på XML:

<suite name="ParallelTests" parallel="tests" thread-count="3">

Parallell utførelse sikrer raskere tilbakekoblingsløkker i CI-pipelines og akselererer regresjonssykluser.

28) Hva er fordelene og ulempene med automatisert testing?

Aspekt Fordeler Ulemper
Speed Utfører tester raskt Innledende oppsettstid
Nøyaktighet Eliminerer menneskelige feil Begrenset til utforskende testing
Reus Evne Skript gjenbrukt på tvers av bygg Vedlikehold overhead
Dekning Bred og dyp dekning Komplekst oppsett av testdata
Integrasjon Enkel CI/CD-kompatibilitet Krever dyktige ressurser

Sammendrag: Selv om automatisering forbedrer effektiviteten, krever vedlikehold av store pakker sterk rammeverksdesign og kontinuerlig vedlikehold.

29) Hvordan håndterer du dynamiske elementer i Selenium?

Dynamiske elementer endrer attributtene sine (som ID eller klasse) ofte.

strategier:

  1. Bruk XPath-funksjoner: inneholder(), starter med()eller tekst().
  2. Kjøp helst CSS-velgere over sprø XPaths.
  3. Påfør eksplisitte ventetider (WebDriverWait) i stedet for statiske forsinkelser.
  4. Bruk relative lokaliseringspunkter in Selenium 4 (over(), nær(), og så videre).

Eksempel:

driver.findElement(By.xpath("//button[contains(text(),'Submit')]")).click();

Dette sikrer teststabilitet til tross for DOM-endringer.

30) Hva er de forskjellige måtene å utføre dataparameterisering på i TestNG?

Dataparameterisering hjelper med å gjenbruke tester for flere datasett.

Tilnærminger:

  1. @Dataleverandør annotering: Leverer data programmatisk.
  2. @Parametere i XML: Sender kjøretidsparametere.
  3. Eksterne filer: Excel (via Apache POI), CSV eller JSON.
  4. Databasekilde: Hent dynamiske testdata fra databasen.

Eksempel:

@DataProvider(name="loginData")
public Object[][] data(){
return new Object[][]{{"user1","pass1"},{"user2","pass2"}};
}

31) Hvordan måler og forbedrer du ytelsen til testautomatisering?

For å optimalisere ytelsen til automatiseringspakken, bør du vurdere følgende faktorer:

  • Parallell testutførelse
  • Selektive regresjonskjøringer
  • Hån mot eksterne tjenester
  • Effektiv håndtering av testdata
  • Reduser unødvendig venting og søvn
  • Profiler langsomme tester ved hjelp av verktøy som Allure, JUnit rapporter

Målinger til Track:

  • Utførelsestid per suite
  • Forholdet mellom bestått og ikke bestått test
  • Ustabil testfrekvens
  • Gjennomsnittlig tid å oppdage (MTTD)

Forbedring krever kontinuerlig optimalisering og analyse av rapporter fra CI/CD-dashbord.

32) Hva er simulerte objekter, og hvorfor er de viktige i testing?

Hånte gjenstander simulere virkelige komponenter som er utilgjengelige eller trege under testing. De er viktige i enhets- og integrasjonstesting.

Bruk saker:

  • Hån mot eksterne API-er (betaling, e-post osv.)
  • Testing av avhengige moduler før full integrasjon
  • Redusere påvirkningen av nettverksforsinkelsen

Eksempel: Ved hjelp av Mockito in Java:

UserService mockService = mock(UserService.class);
when(mockService.getUser("123")).thenReturn(new User("John"));

Mocks øker påliteligheten og hastigheten ved å eliminere eksterne avhengigheter.

33) Hva er forskjellen mellom belastningstesting og stresstesting?

typen Formål Scenarioeksempel
Load Testing Kontrollerer ytelsen under forventet belastning 1000 samtidige brukere
Stresstesting Evaluerer stabilitet under ekstreme forhold 5000+ samtidige brukere eller databasefeil
Utfallet Måler systemets skalerbarhet Bestemmer bruddpunktet

Verktøy brukt: JMeter, Gatling, Gresshopper.

Begge deler bidrar til å identifisere flaskehalser og optimalisere ressursutnyttelsen.

34) Hvordan kan du sikre testpålitelighet og redusere ustabile testfeil?

Å forsikre seg om testpålitelighet, følg disse strategiene:

  • Bruk eksplisitte ventetider i stedet for faste forsinkelser.
  • Unngå avhengighet mellom tester.
  • Isoler tester fra miljødata.
  • Bruk simulerte servere for stabile endepunkter.
  • Anvende prøve mekanismer på nytt og testmerking for å overvåke trender med flakighet.

Ustabile tester må logges, settes i karantene og analyseres for å opprettholde tilliten til CI-testresultatene.

35) Skriv en enkel kodebit for å sjekke om en streng er et palindrom ved hjelp av Java.

Dette er et vanlig SDET-kodingsspørsmål for å vurdere logikk og språkferdigheter.

public class PalindromeCheck {
public static void main(String[] args) {
    String str = "madam";
    String rev = new StringBuilder(str).reverse().toString();
    if(str.equalsIgnoreCase(rev))
       System.out.println("Palindrome");
    else
       System.out.println("Not Palindrome");
   }
}

Forklaring: Strengen reverseres ved hjelp av StringBuilderHvis den reverserte strengen er lik den opprinnelige (ignorerer store og små bokstaver), er det et palindrom.

36) Hvordan feilsøker man en automatisert test som mislykkes?

Feilsøking er en av de viktigste ferdighetene for en SDET. Når en test mislykkes, er det viktig å avgjøre om problemet ligger i applikasjon, testskripteller miljø.

Systematisk feilsøkingsmetode:

  1. reprodusere problemet lokalt.
  2. Analyser logger (applikasjonslogger, testrapporter, CI-logger).
  3. Ta skjermbilder og konsollutdata.
  4. Valider selektorer eller lokaliseringsverktøy ved hjelp av nettleserutviklerverktøy.
  5. Sjekk nettverks-/API-svar (spesielt for UI-testfeil).
  6. Revse de siste kodeendringene i versjonskontroll.
  7. Kjør på nytt med feilsøking aktivert (F.eks TestNG - feilsøke modus).

Tips: Sørg alltid for at testene er idempotente – flere kjøringer bør gi samme resultat.

37) Hvordan håndterer du synkroniseringsproblemer i Selenium?

SyncProblemer med hormonisering oppstår når skript kjøres raskere enn programmet lastes inn.

Løsninger:

  • Implisitte ventetider: Gjelder globalt (anbefales ikke for komplekse tester).
  • Eksplisitte ventetider: Vent på bestemte elementer eller betingelser ved bruk av WebDriverWait.
  • Flytende venter: Tillater avspørringsfrekvens og ignorerer unntak.

Eksempel:

WebDriverWait wait = new WebDriverWait(driver, Duration.ofSeconds(10));
wait.until(ExpectedConditions.visibilityOfElementLocated(By.id("loginBtn")));

Eksplisitte ventetider tilbyr finjustert kontroll, noe som sikrer stabilitet på tvers av dynamiske webapplikasjoner.

38) Hvordan versjonskontrollerer du automatiserte tester effektivt?

SDET-team administrerer testkode akkurat som applikasjonskode.

Beste praksis:

  • Bruk gå for versjonskontroll.
  • Vedlikeholde forgreningsstrategi (funksjon, utgivelse, hovedfunksjon).
  • Implementere pull-forespørsler (PR-er) med fagfellevurderinger.
  • Kjøring av taggtest med commit-hasher for tracevne.
  • Butikk testrapporter og artefakter i CI/CD-lagring eller S3-bøtter.

Eksempel: Automatiseringsrepositorier speiler ofte applikasjonsrepositorier – én gren per utgivelsessyklus for å sikre samsvar.

39) Forklar hvordan du ville teste et REST API-endepunkt ved hjelp av Postman og automatisering.

Testing av et REST API innebærer å verifisere funksjonalitet, ytelse og dataintegritet.

Ved hjelp av Postman:

  • Opprett en ny forespørsel med et endepunkt og en HTTP-metode.
  • Legg til overskrifter (Authorization, Content-Type).
  • Legg til nyttelast for POST/PUT.
  • Valider svarstatus og brødtekst via skript (pm.forvent).

Bruk av automatisering (RestAssured-eksempel):

given().header("Content-Type","application/json")
.when().get("https://api/users/1")
.then().statusCode(200)
.body("data.id", equalTo(1));

Tips: Inkluder alltid negativ testing (f.eks. ugyldige tokener eller manglende parametere) for å sikre robusthet.

40) Hvordan håndterer du testmiljøer i storskala automatisering?

Miljøadministrasjon sikrer at automatisering kjører konsekvent på tvers av utvikling, oppstart og produksjonsreplikaer.

Beste praksis:

  • Konfigurasjoner av butikkmiljø (URLs, legitimasjon) i eksterne filer (YAML, JSON).
  • Implementere miljøvelgere ved hjelp av Maven-profiler eller miljøvariabler.
  • Bruk Dockerbeholdere å gjenskape miljøer konsekvent.
  • Vedlikeholde dataisolering (f.eks. dedikerte testkontoer).

Eksempel: Bruk config.properties fil for å laste inn miljødata dynamisk.

41) Hva er forskjellen mellom en stub og en mock?

Aspekt stub håne
Formål Gir forhåndsdefinerte svar Verifiserer atferd/interaksjoner
bruk Brukes til dataoppsett Brukes til å hevde metodekall
Verifisering Ingen bekreftelse Har forventningsbekreftelse
Eksempelverktøy Tilpasset dummy-klasse Mockito rammeverk

Eksempel:

// Mock
verify(mockObject, times(1)).processData();

Mocks validerer at avhengige metoder kalles riktig – stubber returnerer bare falske data.

42) Hvordan sikrer dere skalerbarhet i testautomatiseringsarkitekturen deres?

Skalerbarhet sikrer at automatiseringen din kan vokse etter hvert som applikasjonen vokser.

Kjerneprinsipper:

  1. Modulær design: Separate bekymringer (tester, verktøy, rapporter).
  2. Parallellisering: Bruk Grid- eller skyleverandører.
  3. Løs kobling: Rammeverket bør enkelt tilpasse seg nye moduler.
  4. CI/CD-integrasjon: Kontinuerlig utførelse i rørledninger.
  5. Versjonskompatibilitet: Sørg for støtte på tvers av verktøy og bibliotek.

Eksempel: Design rammeverkslag som BaseTest, PageObject, verktøyog Tester pakker for å muliggjøre enkel utvidelse.

43) Skriv en Java Program for å fjerne duplikater fra en array.

import java.util.*;
public class RemoveDuplicates {
    public static void main(String[] args) {
        int[] nums = {1, 2, 2, 3, 4, 4, 5};
        Set<Integer> unique = new LinkedHashSet<>();
        for(int n : nums) unique.add(n);
        System.out.println(unique);
    }
}

Forklaring: Ocuco LinkedHashSet fjerner automatisk duplikater samtidig som rekkefølgen bevares – et vanlig SDET-kodingsspørsmål som tester grunnleggende kunnskap om datastruktur.

44) Hva er kontinuerlig testing, og hvordan er det relatert til DevOps?

Kontinuerlig testing (CT) betyr testing gjennom hele programvareleveransesyklusen – fra kodeoverføring til distribusjon.

Forhold til DevOps:

  • CT sørger for at alle trinn i rørledningen valideres automatisk.
  • CI/CD-verktøy som Jenkins triggertester etter hver commit.
  • Det akselererer tilbakemeldingsløkker og sikrer slipp selvtilliten.

Fordeler:

  • Tidlig oppdagelse av feil
  • Redusert manuell inngripen
  • Økt frigjøringshastighet

Eksempel: Automatiserte regresjons- og røyktester utløses etter hver sammenslåingsbygg før distribusjon.

45) Hvordan identifiserer du ytelsesflaskehalser i webapplikasjoner?

Ytelsesflaskehalser er trege punkter som forringer brukeropplevelsen.

Fremgangsmåte:

  1. Bruk verktøy som JMeter, Gatlingeller Lighthouse for profilering.
  2. Analyser responstid, gjennomstrømningog CPU-/minnebruk.
  3. Bruk APM-verktøy (Ny relikvie, Dynatrace) for kodenivå tracing.
  4. Identifiser langsomme databasespørringer or API-forsinkelse.
  5. Implementere mellomlagring og tilkoblingspooling optimaliseringer.

Eksempel på metrikktabell:

Metric Ideell verdi Tiltak ved brudd
Responstid <2 sekunder Optimaliser API- eller DB-spørring
CPU bruk <80% Optimaliser kode eller øk ressursene
Minnebruk <70% Reparer lekkasjer eller juster GC

46) Hvilke designmønstre brukes i rammeverk for testautomatisering?

Designmønstre bidrar til å lage rammeverk for testautomatisering modulær, vedlikeholdbarog skalerbar.

Vanlige mønstre inkluderer:

Pattern Formål Eksempel
Sideobjektmodell (POM) Innkapsler sideelementer Selenium rammer
Singleton Sikrer én enkelt driverforekomst WebDriver-oppsettklasse
Fabrikkmønster Administrerer objektoppretting DriverFactory for nettlesere
Strategimønster Støtter flere strategier dynamisk Håndtering av pålogging for ulike roller
Observatørmønster Tracks testhendelser Logging av lyttere for rapporter

Eksempel: Bruk av Singleton-mønster for WebDriver forhindrer at flere forekomster kommer i konflikt under parallelle tester.

47) Hvordan ville du håndtere testdatahåndtering i automatisering?

Testdatahåndtering (TDM) sikrer pålitelige, repeterbare og konsistente testkjøringer.

Tilnærminger:

  1. Statiske data: Lagret i JSON-, XML- eller Excel-filer.
  2. Dynamiske data: Generert under kjøring (UUID, tidsstempel).
  3. Databasedrevet: Hent ekte data via spørringer.
  4. API-generert: Bruk API-kall før testing for å lage simulerte data.
  5. Datamaskering: Beskytter sensitiv informasjon i testmiljøer.

Beste praksis: Oppbevar data i eksterne kilder, ikke hardkodet i skript. Bruk fabrikker til å generere input dynamisk for skalerbarhet.

48) Hva er noen av de viktigste utfordringene ved vedlikehold av store automatiseringspakker?

Vanlige utfordringer:

  • Hyppig UI endres pauselokaliseringssystemer.
  • flassete tester på grunn av miljømessig ustabilitet.
  • Langsom utførelse på grunn av overflødige tester.
  • Dårlig modulariserte skript økende vedlikeholdskostnader.
  • Dataavhengigheter som fører til ikke-repeterbare tester.

Løsninger:

  • Adopter modulær rammeverkdesign.
  • aktiver parallelle løp i CI/CD.
  • Kontinuerlig gjennomgå og avvikle utdaterte tester.
  • Implementere robust logging og overvåking.

49) Hvordan ville du automatisere testing for en React- eller Angular-webapplikasjon?

Moderne front-end-rammeverk (React, Angular) er i stor grad avhengige av asynkron gjengivelse.

Beste praksis:

  1. Bruk eksplisitte ventetider for å håndtere asynkron lasting.
  2. Kjøp helst data-testid attributter for stabile lokaliseringspunkter.
  3. Utnytt verktøy som Cypress, Dramatikereller TestCafe.
  4. Validere komponenttilstander og DOM-øyeblikksbilder for regresjon.

Eksempel:

cy.get('[data-testid="submitBtn"]').click()
cy.url().should('include', '/dashboard')

Hvorfor: Cypresss automatiske ventinger og feilsøking med tidsreiser gjør den utmerket for moderne JS-baserte apper.

50) Hvordan håndterer du API-skjemavalidering i automatiseringstesting?

Skjemavalidering sikrer at API-svar samsvarer med forventede datastrukturer.

Bruk av RestAssured:

given().get("/users/1")
.then().assertThat()
.body(matchesJsonSchemaInClasspath("user-schema.json"));

Fordeler:

  • Oppdager manglende eller feil navngitte felt tidlig.
  • Garanterer bakoverkompatibilitet.
  • Forhindrer problemer med serialisering under kjøring.

Tips: Hold skjemaer versjonerte i Git sammen med tester for CI-validering.

51) Hvordan håndterer du inkonsekvente miljøer på tvers av utvikling og kvalitetssikring?

Tilnærminger:

  • Bruk Docker or Kubernetes å containerisere miljøer.
  • Lagre konfigurasjoner i Miljøvariabler.
  • Bruk har flagg for å slå av/på ufullstendig funksjonalitet.
  • Automatiser miljøklargjøring med terra or Ansible.
  • Implementere simulerte servere for utilgjengelige API-er.

Mål: Oppnå miljøparitet mellom utvikling, kvalitetssikring og oppsett – eliminerer problemer med at «fungerer på maskinen min».

52) Forklar hvordan du kan bruke Docker i automatiseringstesting.

Docker sikrer konsistente, isolerte testmiljøer.

Bruk tilfeller:

  • kjører Selenium Rutenettcontainere for parallell testing.
  • Lokal hosting av webapper og API-er for integrasjonstester.
  • Pakke hele automatiseringspakken i en container.

Eksempel på kommando:

docker run -d -p 4444:4444 
selenium/standalone-chrome

Dette muliggjør umiddelbar oppsett uten manuelle nettleserkonfigurasjoner.

53) Hva er kontinuerlig overvåking, og hvordan brukes det i kvalitetssikring?

Kontinuerlig overvåking (CM) involverer sanntid trackongen av applikasjonshelse i produksjons- og testmiljøer.

Verktøy: Prometheus, Grafana, ELK Stack, Datadog.

Bruk av QA:

  • Identifiser feil etter utrulling.
  • Overvåk API-responstider og systemoppetid.
  • Oppdag regresjoner gjennom syntetiske tester.

Ved å kombinere CI, CD og CM, oppnår organisasjoner fullstendig synlighet og pålitelighet gjennom hele programvarens livssyklus.

54) Hvordan tester man hendelsesdrevne arkitekturer (Kafka, RabbitMQ, osv.)?

Testing av hendelsesdrevne systemer krever validering av meldingsflyt, bestilling og leveringsgarantier.

Nærme seg:

  1. Imitere produsenter/forbrukere.
  2. Bekreft meldingsskjemaet ved hjelp av Avro- eller JSON-skjema.
  3. Valider leveringssemantikken minst én gang eller nøyaktig én gang.
  4. Simuler feil for å teste robusthet.

Eksempelverktøy:

  • Kafka Streams Testverktøy
  • TestContainere for Kafka
  • WireMock for meldingsnyttelaster

55) Hvilke målinger bruker du for å måle automatiseringseffektivitet?

Kvantitative målinger:

  • Utførelsesrate for testtilfeller
  • Prosentandel for bestått test
  • Feildeteksjonsrate
  • Automatiseringsdekning (%)
  • Gjennomsnittlig tid til å oppdage (MTTD) og løse (MTTR)
  • Flakingsforhold

Kvalitative målinger:

  • vedlikeholdbarhet
  • Reus Evne
  • CI-integrasjonspålitelighet

Mål: Vis at automatisering gir avkastning på investeringen gjennom målbar effekt.

56) Hvordan prioriterer du testtilfeller for automatisering?

Prioriteringsfaktorer:

Faktor rasjonale
Høy forretningsmessig innvirkning Kritiske moduler (f.eks. betaling)
Høy regresjonsfrekvens Ofte endrede funksjoner
Gjentakelse Ideell for automatisering
Stabil funksjonalitet Reduserer vedlikehold
Teknisk gjennomførbarhet API-er før dynamiske brukergrensesnitt

Eksempel: Automatiser innlogging, betaling og API-helsesjekker før sjelden brukte funksjoner.

57) Hvordan administrerer du hemmeligheter (tokens, legitimasjon) sikkert i testautomatisering?

Aldri hardkode hemmeligheter i skript.

Beste praksis:

  • Bruk Miljøvariabler or Hemmelige CI/CD-hvelv.
  • Leverage Hashi Corp Vault, AWS Secrets Managereller Azure nøkkel Vault.
  • Masker sensitive data i rapporter og logger.
  • Roter hemmeligheter med jevne mellomrom.

Eksempel: System.getenv("API_TOKEN") henter token sikkert under kjøretid.

58) Beskriv et scenario fra den virkelige verden der du optimaliserte en ustabil automatiseringspakke.

Scenarioeksempel: En testsuite for e-handel hadde ~20 % ustabilisering på grunn av trege API-responser og dynamisk UI-gjengivelse.

Handlinger utført:

  • Erstattet hard venting med eksplisitte ventetider.
  • implementert prøv på nytt-logikk for midlertidige nettverksproblemer.
  • La til simulerte servere for eksterne avhengigheter.
  • konfigurert CI-rørledning å isolere mislykkede tester for gjennomgang.

Resultat: Flakkingen ble redusert fra 20 % til <3 %, noe som forbedret pipeline-påliteligheten og utviklerens tillit.

59) Hva er forskjellen mellom shift-venstre og shift-høyre-testing?

Tilnærming Definisjon Fokusområde
Shift-Venstre testing Tidlig testing i SDLC Enhet, integrasjon, CI-automatisering
Shift-Riktig testing Testing etter utrulling Produksjonsovervåking, A/B-tester
Mål Forebygg feil tidlig Observer brukeratferd i sanntid

Eksempel: Shift-venstre = integrering av enhetstester i CI.

Shift-right = overvåking av API-forsinkelse i produksjon.

60) Atferdsspørsmål – Hvordan håndterer du en situasjon når automatiseringspakken din feiler før en utgivelsesfrist?

Svarrammeverk (STAR-metoden):

  • Situasjon: Regresjonspakken din mislykkes med 30 % røde tester før utrulling.
  • Oppgave: Identifiser om problemet ligger i koden eller miljøet.
  • Handling:

    • Analyser CI-logger.
    • Kjør kritisk røykpakke først.
    • Samarbeid med utviklere for å fikse blokkeringsfeil.
    • Logg ustabile tester for gjennomgang etter utgivelse.
  • Resultat: Leverte utgivelsen i tide med validerte kritiske flyter samtidig som automatiseringen ble stabilisert i neste sprint.

Viktige egenskaper demonstrert: Eierskap, analytisk tenkning, samarbeid og risikostyring.

🔍 De beste SDET-intervjuspørsmålene med virkelige scenarioer og strategiske svar

1) Hvordan skiller du mellom rollen til en SDET og en tradisjonell QA-ingeniør?

Forventet fra kandidaten: Intervjueren ønsker å vurdere din forståelse av SDET-rollen og hvordan den går utover manuell testing til ingeniør- og automatiseringsansvar.

Eksempel på svar: En SDET skiller seg fra en tradisjonell QA-ingeniør ved å ha et sterkere fokus på programvareutviklingsferdigheter. En SDET er ansvarlig for å designe automatiseringsrammeverk, skrive testkode på produksjonsnivå og integrere testing i utviklingslivssyklusen. I min forrige rolle samarbeidet jeg tett med utviklere for å sikre at testbarhet og kvalitet var innebygd i applikasjonen fra starten av.

2) Hvilke rammeverk for testautomatisering har du designet eller jobbet med, og hvorfor valgte du dem?

Forventet fra kandidaten: Intervjueren evaluerer din praktiske erfaring med automatiseringsrammeverk og din evne til å ta informerte tekniske beslutninger.

Eksempel på svar: Jeg har jobbet med datadrevne og atferdsdrevne automatiseringsrammeverk. I en tidligere stilling valgte jeg et modulært rammeverk fordi det forbedret vedlikeholdbarheten og tillot parallell testkjøring. Valget var drevet av prosjektets skala, teamets ferdigheter og behovet for enkel integrasjon med kontinuerlige integrasjonsrørledninger.

3) Hvordan sikrer du at testautomatisering forblir stabil og vedlikeholdbar over tid?

Forventet fra kandidaten: De ønsker å forstå din tilnærming til langsiktig automatiseringshelse og teknisk gjeldshåndtering.

Eksempel på svar: Jeg sikrer stabilitet ved å følge rene kodeprinsipper, implementere riktig feilhåndtering og regelmessig refaktorere testskript. I min forrige jobb introduserte jeg kodegjennomganger for automatisering og la til detaljert logging, noe som reduserte ustabile tester betydelig og forbedret feilsøkingseffektiviteten.

4) Beskriv en situasjon der du fant en kritisk feil sent i utgivelsessyklusen. Hvordan håndterte du det?

Forventet fra kandidaten: Dette spørsmålet tester dine problemløsningsevner, kommunikasjonsevner og evne til å håndtere pressede situasjoner.

Eksempel på svar: I min forrige rolle identifiserte jeg et kritisk ytelsesproblem rett før lansering. Jeg kommuniserte umiddelbart risikoen til interessentene, ga tydelige reproduksjonstrinn og samarbeidet med utviklere for å validere en løsning. Ved å prioritere åpenhet og samarbeid unngikk vi å lansere en defekt funksjon.

5) Hvordan bestemmer du hvilke testtilfeller som skal automatiseres kontra manuelt testes?

Forventet fra kandidaten: Intervjueren ønsker å se din strategiske tenkning og forståelse av testoptimalisering.

Eksempel på svar: Jeg prioriterer automatisering for repeterende, høyrisiko- og regresjonstester. Manuell testing er mer egnet for utforskende og brukervennlige scenarier. Denne balanserte tilnærmingen sikrer effektiv dekning samtidig som verdien av automatiseringsarbeidet maksimeres.

6) Hvordan integrerer du testing i en kontinuerlig integrasjons- og leveringsprosess?

Forventet fra kandidaten: De vurderer din erfaring med DevOps-praksiser og automatiseringsmodenhet.

Eksempel på svar: Jeg integrerer automatiserte tester i pipelinen slik at de kjører på hver kode-commit og distribusjon. Røyktester kjøres tidlig, etterfulgt av regresjonstester på senere stadier. Dette sikrer rask tilbakemelding og bidrar til å fange opp feil så tidlig som mulig.

7) Fortell meg om en gang du måtte utsette en utgivelse på grunn av kvalitetsproblemer.

Forventet fra kandidaten: Dette evaluerer din dømmekraft, kommunikasjonsevner og forpliktelse til kvalitet.

Eksempel på svar: Jeg la en gang merke til uløste feil med høy alvorlighetsgrad som utgjorde en risiko for brukerne. Jeg presenterte tydelige data og testresultater for ledelsen og forklarte den potensielle effekten. Ved å fokusere på fakta snarere enn meninger, kunne jeg påvirke beslutningen om å utsette lanseringen.

8) Hvordan håndterer du stramme tidsfrister når automatiseringsoppgaver ikke fullføres?

Forventet fra kandidaten: Intervjueren ønsker å forstå dine prioriteringer og tilpasningsevne under press.

Eksempel på svar: Jeg fokuserer på å automatisere de mest kritiske stiene først og kommuniserer realistiske forventninger. Om nødvendig supplerer jeg automatisering med målrettet manuell testing. Denne tilnærmingen sikrer dekning uten at det går på bekostning av leveringsfrister.

9) Hvilke målinger bruker dere for å måle effektiviteten av testarbeidet deres?

Forventet fra kandidaten: De ønsker innsikt i hvordan du kvantifiserer kvalitet og track-forbedring.

Eksempel på svar: Jeg bruker målinger som defektlekkasje, automatiseringsdekning, testutførelsestid og feiltrender. Disse målingene bidrar til å identifisere hull i testing og veilede kontinuerlige forbedringsinitiativer.

10) Hvordan holder du ferdighetene dine oppdatert som SDET?

Forventet fra kandidaten: Intervjueren vurderer din forpliktelse til kontinuerlig læring i et felt i rask utvikling.

Eksempel på svar: Jeg studerer jevnlig nye testverktøy, programmeringspraksiser og bransjetrender gjennom tekniske blogger, nettkurs og praktisk eksperimentering. Ved å holde meg oppdatert kan jeg bringe moderne og effektive testpraksiser til teamet mitt.

Oppsummer dette innlegget med: