Hva er SDET: Vet forskjellen mellom tester og SDET

what is sdet know difference between tester

Denne opplæringen diskuterer alle aspektene ved en SDET (programvareutviklingsingeniør i test) inkludert ferdighetssett, roller og ansvar, lønn og karrierevei:

Vi vil diskutere SDET-rollen i dybden, forventningene og ansvaret fra denne rollen som selskapene forventer, ferdighetssettet som en SDET må ha, verktøy og teknologier som kandidaten skal være praktisk med, og også lønnene generelt tilbys.

Hva du vil lære:

• Forstå SDET-rollen
  • Sammenligning mellom SDET og manuell QA
  • Programvareutviklingsingeniør i Test Skillset
  • Roller og ansvar
  • Bli en flott SDET
  • Sertifisering for SDET-er
  • Intervjuer
  • SDET Lønn
  • Karrierevei
• Konklusjon
  • Anbefalt lesing

Forstå SDET-rollen

Den utvidede formen for SDET er - Programvareutviklingsingeniør i test

I veldig enkle ord er denne rollen en kombinasjon av et mellomliggende mellom en ren utviklerrolle og en ren testerrolle. SDET er dyktige fagpersoner innen begge - Quality Engineering så vel som programvareutvikling.

Begrepet SDET ble først oppfunnet av Microsoft, som deretter ble fulgt og brukt av de fleste store produktnavn som Google, Amazon, Adobe, Expedia, etc. Rollene store forventningene var å erstatte manuelle repetitive oppgaver med litt automatisering for å øke effektiviteten samt pålitelighet for applikasjonene som testes.

Sammenligning mellom SDET og manuell QA

Manuelle QA-testere er hovedsakelig fokusert på Black Box eller Application testing. Hva det betyr er, for en QA-tester, det som betyr noe, er en spesifikasjon av hvordan en app forventes å oppføre seg når den får en viss innspill.

nettsted for å konvertere youtube-videoer til mp3

QA-tester ville bare bruke applikasjonen / systemet som ble testet som en vanlig bruker / kunde ville bruke, men med fokus på mer detaljerte detaljer samt kantscenarier ved å prøve forskjellige inngangskombinasjoner, etc.

SDET’s fokuserer på applikasjon fra både White Box og Black Box testing. Med andre ord, de ville også være klar over den indre funksjonen til appen, som gjør det mulig for dem å skrive automatiseringstester ved hjelp av både White Box eller Black Box testteknikker.

I hovedsak må en programvareutviklingsingeniør i test være klar over alle Black Box-testteknikker sammen med praktisk utvikling / kodingskunnskap for å forstå den indre funksjonen til appen som sikrer bedre kvalitetsstandarder samt et mindre defekt programvareprodukt.

I hovedsak bør en SDET fungere som en aktivator for effektiv kvalitetssikring på alle måter. Hva dette også betyr, at den enkelte vil bruke sine ferdigheter for å sikre at alle deler av programvaren som testes blir validert på best mulig måte, som skal omfatte testing av både funksjonelle og ikke-funksjonelle områder.

La oss se sammenligning av SDET og manuell tester på forskjellige parametere

Programvareutviklingsingeniør i Test Skillset

Nedenfor vises ferdighetssettene som en SDET må ha:

# 1) Åpne tankesett

Den første og viktigste ferdigheten er at enhver programvareutviklingsingeniør i test skal være åpen for å lære skriptspråk / verktøy som kreves for å gjøre det mulig for dem å ha grundig testing av appen som testes.

Det er ganske sannsynlig at du som SDET i ett selskap kan ende opp med å bruke Microsoft / .NET tech stack, men i et annet selskap er utviklingsspråk primært Java - så SDET forventes å ha et åpent tankesett for å lære nye ting / tech som og når det er nødvendig.

# 2) Adaptiv

En programvareutviklingsingeniør i test må tilpasse seg prosjektets behov, verktøy og teknologier, databaser osv. For eksempel - som SDET kan du ha en erfaring med å gjøre API-testing, men en annen rolle krever at du tester brukergrensesnitt eller frontend. Derfor krever rollen at du tilpasser deg prosjektets behov, for å levere et standardprodukt av høy kvalitet.

# 3) Multitasker

Hos de fleste produktselskapene blir DEV og QA-forhold ofte skjevt i stor grad. Dette betyr at det er vanlig å se lag som har et DEV: QA-forhold på 4: 1 eller til og med 5: 1. Derfor er det viktig at en SDET forventes å være involvert i flere ting og levere.

Dette er et par ansvarsområder som en SDET forventes å jobbe med:

• Delta i interessentmøter: En SDET må ha tett kontakt med både utviklere så vel som produktfolk for å forstå produktet fra både utviklere og produktperspektiv, og deretter utforme / foreslå automatiseringsstrategi.
• Lag rammeverk / verktøy
• Strategiser testplanlegging
• Hev / undersøk mangler
• Noen ganger kan det være nødvendig å bidra til enhetstesting sammen med utviklere.

# 4) Utforskende tankesett

Hver SDET bør huske disse linjene til enhver tid - “ Hvis du gjentar de samme handlingene hele tiden, bør du vurdere å automatisere det '

Personen ville ha et tankesett for å redusere innsatsen for alt som kommer deres vei ved hjelp av verktøy for å øke produktiviteten, samt for å sikre programvareprodukter av høy kvalitet.

I tillegg til alt automatiseringsarbeid, er SDETs primære jobb å levere produkter av høy kvalitet med det som trengs, og derfor vil han / hun også trenge å fokusere på å teste produkter gjennom utforskende måter å avdekke flere og flere skjulte feil og feil.

# 5) Samarbeid, bidra og kommunisere

SDETs rolle mandater til å samarbeide mellom forskjellige interessenter som utviklere, produkt, manuelle testere osv.
Det er viktig at SDET-er samarbeider med alle nødvendige interessenter, samt kommuniserer alle nødvendige detaljer når og når det er aktuelt.

SDETs og QA-teamet holder kvalitetsportene til et produkt før det er åpent for publikum, og derfor spiller de en viktig rolle når det gjelder å anse at et produkt er egnet til å bli lansert for kunder eller ikke.

Roller og ansvar

Så la oss prøve å forstå, hva er SDETs daglige jobber og ansvar og de forskjellige oppgavene de forventes å gjøre.

• Arbeid sammen med utviklere og forretningsinteressenter og forsøk å automatisere akseptkriteriene. Dette betyr med enkle ord - SDET forstår først kravene fra aksept / kundeperspektiv og må også forstå måten produktet er utviklet med hensyn til kodingsspråk, databaser osv., Og planlegger deretter en strategi for å automatisere maksimale scenarier som mulig. .
• Ansvarlig for å bygge robuste og høykvalitets testautomatiseringsløsninger for funksjons-, regresjons- og ytelsestesting.
• Lag gjenbrukbare skript / verktøy der det er nødvendig.
• Bidra til både funksjonelle og ikke-funksjonelle testområder. Funksjonstesting inkluderer testing fra funksjonalitet / kravperspektiv og er i stor grad drevet av akseptkriterier eller brukerhistorier.
  Imidlertid er ikke-funksjonell testing også viktig. For eksempel, hvor effektiv applikasjonen er, er applikasjonen sikker nok, sørg for at det ikke er noen hacks igjen i appen, noe som kan føre til hinder for sikkerheten til appen og kan ende opp med å medføre et stort tap for både kunder og organisasjonen.
• De deltar også i diskusjoner om design og arkitektonisk design, samt gir effektive tilbakemeldinger i kodevurderinger.

Bli en flott SDET

For å bli en flott SDET, la oss se noen tips / grunnleggende verktøy og tekniske ferdigheter som må læres for å få det bedre i rollene.

I forrige avsnitt lærte vi om egenskaper en programvareutvikler i Test må ha for å bli gode i rollene. De må ha et åpent tankesett, være tilpasningsdyktige og skal være i stand til å kommunisere, samarbeide og bidra på den måten som pålagt av produktet eller teamet.

La oss se en liste over noen vanlige verktøy og teknologier som SDET-er må lære:

• Bør ha en solid forståelse av testprinsipper, testtyper og metoder.
• Svært dyktige i feilsøkingsproblemer - lær feilsøkingsverktøy som - Chrome Web Debugger som er ekstremt nyttige for feilsøking av webapplikasjoner, samt for å undersøke nettverkslogger for en app som testes.
• De skal kunne skrive kode / skript som kan brukes på nytt, og derfor bør de være dyktige i minst ett skriptspråk. Det enkleste å lære er Python som kan brukes på et bredt utvalg av oppgaver, automatiseringsrammer osv.
• Vær kjent med API-testing av klienter som POSTBUD
• Bør være oppmerksom på verktøy og teknikker for White Box-test - som Mocking Frameworks ( Mockito ) osv., ettersom de kan forventes å bidra med å skrive enhetstester også når det er nødvendig.
• De bør være klar over versjonsverktøy som Gå . De bør også være kjent med begrepene Trekk forespørsler , kodevurderinger osv.
• Forståelse av arkitektur for webapplikasjoner og generell klient-servermodell.
• Bør være klar over grunnleggende objektorienterte programmeringskonsepter og forståelse av FAST modell ( S ingle Ansvar, ELLER penn / lukket prinsipp, L iskov-bytte, Jeg nterface Segregation, D ependency Inversion)
• Grunnleggende forståelse av Kontinuerlig integrering / Kontinuerlig levering konsepter (CI / CD) og bør også være klar over CI-verktøy som Jenkins / Bamboo, etc.
  SDET-er forventes generelt å ta seg av distribusjonsproblemer, og det er derfor viktig å forstå disse verktøyene.
• De bør være kjent med minst ett rammeverk for automatisering av frontend. Den enkleste og mest brukte i Selen . Det er den hellige gralen ved frontend-testing for webapplikasjoner, og nesten alle organisasjoner bruker Selenium-rammeverket for å automatisere UI-tester.
• Lære det grunnleggende om ytelsestesting, samt skrive enkle skript ved hjelp av åpen kildekode-ytelsesverktøy som JMeter er veldig nyttig, og du kan referere til dette Jmeter opplæring . Dette er nyttig ettersom SDETs også forventes å ivareta ikke-funksjonelle krav som ytelsestesting.
• De bør også være klar over de grunnleggende konseptene for sikkerhetstesting. Dette inkluderer også å ha kunnskap om grunnleggende kodestandarder som sikrer at det ikke er noen grunnleggende sikkerhetsfeil som ikke blir adressert i appen. OWASP er en flott referanse for alle slike grunnleggende konsepter.
• Det forventes at SDET-er kjenner, forstår og implementerer smidige utviklingsmetoder, og de bør være komfortable i å samarbeide med team som bruker Sprint / Scrum-metoden for smidig.
• Bør være klar over noen skyteknologiplattformer som - Amazon AWS , Google GCP , eller Microsoft Azure .
  Siden de fleste av selskapene nå flytter til en skybasert infrastruktur, er det generelt nyttig å komme i gang med å ha en grunnleggende forståelse av skyverktøy og teknologier.

Sertifisering for SDET-er

Generelt er det ingen spesifikke sertifiseringer som er tilgjengelige for SDET-er

Hvis noen vil starte sin programvareutviklingsingeniør i testreise, kan de bare fokusere på punktene som er nevnt i delen 'Hvordan bli en flott SDET' i denne opplæringen, og deretter bør SDET-er med sitt åpne tankesett fortsette sin læringsreise på jobben.

For å teste terminologi og grunnleggende er det bra å ha alle som er i programvaretestingsyrket for å bli sertifisert med ISTQB Foundation testsertifikat .

Denne sertifiseringen dekker alle de grunnleggende programvaretestkonseptene som,

• Testtyper - funksjonelle / ikke-funksjonelle
• Svart boks / Hvit boks / Testing av grå boks
• Testplanlegging / Feilhåndtering
• Testteknikker - Partisjonering av ekvivalens, sporbarhetsmatrise, etc.

Det finnes også andre internasjonale programvaretestingsertifiseringer, men de fleste av dem er ikke veldig viktige utvalgskriterier for selskaper å ansette SDET-er.

En liste over alle slike sertifiseringer er tilgjengelig her.

Intervjuer

Med de fleste av de større produktselskapene, er Software Development Engineer i testintervju mye mer sammenlignet med de med utviklerintervjuer, ettersom det forventes at de vet mest om utviklingen av metoder og relaterte konsepter.

Intervjuene er imidlertid litt lette sammenlignet med utviklere. Det som vektlegges her er hvordan kandidaten nærmer seg et problem og hvor bredt en person kan tenke på problemet.

Generelt består SDET-intervjuer av følgende runder / spørsmålstyper på nesten alle store produktorganisasjoner som - Amazon, Microsoft, Adobe, Expedia, etc.

1. Skriftlig runde: Skrive prøvesaker for et gitt produkt. Her er intensjonen å få en ide om hva alle fasetter av testing kan personen tenke på kandidaten som hvis han tenker / lister opp alle funksjonsscenarier, edge-case scenarier, er kandidat som fokuserer på sikkerhetstesting, ytelsestesting, etc.
2. Koderunde: Det gis en liten kodingsøvelse, og det forventes også at kandidaten skriver ned alle enhetstester og funksjonstestingsscenarier. Her er området eller ferdigheten som testes - grunnleggende koding / konstruksjon av koding, skriving av testbar kode og kunnskap om testteknikker for hvite bokser som enhetstesting, spotting, etc.
3. Designrunde: Et systemdesignspørsmål kastes, eksempel , hvordan vil du designe youtube
   Denne typen spørsmål har generelt mer relevans for utviklere, men for SDETs leter intervjueren etter hvor bredt personen kan tenke, vet kandidaten om OOPs-begreper, er kandidaten i stand til å tenke på skalerbarhet, robusthet, lastbalansering osv. , kan kandidaten bruke riktige databaser for applikasjonen som skal utformes
4. HR / lederrunde: Her observeres ting som teamfitness, kulturfitness osv. Om kandidaten, samt lønnsdiskusjoner, og forhandlinger blir også gjort.

Anbefalt lesing => SDET intervju spørsmål

SDET Lønn

Som vi har diskutert i våre forrige seksjoner, har SDETs høyere lønn enn de fleste av de manuelle testrollene. I mange tilfeller er lønn sammenlignbar med utviklere på et lignende opplevelsesnivå.

Du kan henvise her for å finne ut om lønnsutvalget ved forskjellige SDET-profiler i forskjellige organisasjoner. Generelt er SDET-lønn forskjellig fra erfaring og organisasjon.

Nedenfor er en sammenligning av SDET-lønn for toppbedrifter som Microsoft, Expedia.

Karrierevei

Generelt starter SDET-karrierestigen og vokser på følgende måte:

• SDET-1 - Juniornivå SDET i stand til å skrive automatiseringsskript.
• SDET-2 - Erfarne SDET i stand til å skrive gjenbrukbare verktøy og automatiseringsrammer.
• Mr SDET Seniornivå SDET i stand til å være en individuell bidragsyter som SDET 1 og SDET 2, men er også i stand til
  • Gjennomfører kodevurderinger.
  • Delta i designdiskusjoner og komme med forslag til passende endringer i design.
  • Delta i den overordnede teststrategien for produktet.
  • Delta i CI / CD-leveringsmodeller, opprett kjøreledninger osv.
• SDET Manager - Etter SDET2 kan du velge Sr SDET eller SDET Manager Path. En SDET-leder har også leder- / lederansvar i tillegg til kjernen i SDET-arbeidet.
• Testarkitekt / Løsningsingeniør - Testarkitekt eller løsningsingeniør er noen som for det meste designer / arkitekter et overordnet rammeverk for flere prosjekter, rammer testspesifikasjoner, kan også fungere som en leveringsleder. Disse menneskene er til enkeltpersoner og hjelper flere prosjekter med å oppnå testresultatene og leverer et omfattende, godt testet og feilfritt produkt.

Her er en representasjon på blokknivå av SDET Career Path:

mp3 gratis nedlastinger for Android-telefoner

Konklusjon

I denne veiledningen lærte vi grundig om hva som er en SDET når det gjelder roller og ansvar, må-ha-ferdigheter, hva som er forskjellen mellom SDET og manuelle testere, og hva som skal til for å bli en flott programvareutviklingsingeniør i test.

Generelt er SDET en rolle som er i høy etterspørsel, og nesten alle gode produktselskaper har denne rollen i sine team og er høyt verdsatt.

Anbefalt lesing

• SDET intervju spørsmål og svar (komplett guide)
• De 10 BESTE selskapene og tjenestene for programvareutvikling i 2021
• 20 BESTE verktøy for programvareutvikling (2021 rangeringer)
• Tiltak for SSDLC (Secure Software Development Life Cycle)
• SDLC (programvareutvikling livssyklus) faser, metoder, prosesser og modeller
• Programvareutvikling og testmetoder (med fordeler og ulemper)
• 5 ting en nybegynnerutvikler (og tester) bør vite om programvaretesting
• 5 måter å være en fet og selvsikker programvaretester