Engineering
Softwareudvikler
Fem niveauer fra juniorudvikler til Principal Engineer og seks kompetencer – fra at levere kode til at udvikle teamet.
- 5 niveauer
- 6 kompetencer
Skabelon til karrierestige
Skabelon til karrierestige for QA engineers
Fire niveauer fra Junior QA til Lead QA Engineer og seks kompetencer – fra testdesign til kvalitetspraksis.
Gratis abonnement · Intet kreditkort nødvendigt
Denne karrierestige er til QA engineers i softwarevirksomheder med cirka 20–200 medarbejdere, hvor testerne sidder i produktteamene, hvor der måske kun er en håndfuld af dem i hele virksomheden, og hvor den samme person ofte laver udforskende test om formiddagen og skriver automatiserede tjek om eftermiddagen. Den beskriver fire niveauer, fra en person, der lærer at teste én feature grundigt, til den person, der bestemmer, hvordan hele virksomheden griber kvalitet an. Det øverste niveau, Lead QA Engineer, er et specialistniveau, ikke en lederrolle.
Hvert niveau er defineret ud fra, hvad personen gør, og hvor langt arbejdet rækker, ikke ud fra antal års erfaring eller antallet af fejl, personen rapporterer. Læs en række i kompetencematrixen fra venstre mod højre for at se, hvordan én forventning vokser; læs afsnittet om et niveau for at se alt, hvad der forventes på det niveau. Brug den til at forklare, hvad det næste skridt betyder, til selvevalueringer og check-ins og til at holde beslutninger om forfremmelse sammenlignelige på tværs af teams.
Se den som et udkast. Hvis jeres QA engineers ikke skriver automatisering, eller hvis udviklerne står for det meste af testen, så ret formuleringerne, før du offentliggør karrierestigen – en forventning, som ingen kan indfri i jeres setup, skaber kun frustration.
Niveauerne i overblik
Junior QA Engineer
Tester veldefinerede features ud fra eksisterende testcases og lærer produktet og dets brugere at kende.
- Omfang
- Enkelte stories eller fejlrettelser i ét område af produktet, med testplaner, som en mere erfaren kollega reviewer.
QA Engineer
Ejer testen af features i ét team, fra at læse kravene til at godkende releasen.
- Omfang
- Ét produktteams features, inklusive deres manuelle og automatiserede tests.
Senior QA Engineer
Former, hvordan et eller to teams bygger kvalitet ind, og ejer teststrategien for større projekter.
- Omfang
- Et eller to teams' teststrategi, automatiseringssuiter og releasebeslutninger samt projekter, der krydser teamgrænser.
Lead QA Engineer
Fastlægger virksomhedens tilgang til kvalitet og gør alle teams bedre til at udgive med færre fejl, der slipper igennem.
- Omfang
- Kvalitet i hele produktet: fælles testinfrastruktur, releasestandarder og hvordan QA bemandes og praktiseres.
Kompetencematrix
Hver række er en kompetence og hver kolonne et niveau. Læs en række fra venstre mod højre for at se hvordan forventningerne vokser.
Hvad hver kompetence betyder
- Testdesign og analyse
- At finde ud af, hvad der kan gå galt, og vælge de tests, der vil finde det.
- Testautomatisering
- At bygge automatiserede tjek, der er hurtige, stabile og har teamets tillid.
- Fejlanalyse og fejlrapportering
- At finde, genskabe og forklare problemer, så de bliver rettet hurtigt.
- Release- og risikovurdering
- At afgøre, om noget er klar til at blive udgivet, og sige det klart.
- Kvalitetspraksis
- At bygge kvalitet ind i teamets måde at arbejde på i stedet for at teste den ind til sidst.
- Mentorskab og videndeling
- At hjælpe andre med at teste bedre og undgå, at viden om produktet kun findes i ét hoved.
| Kompetence | Junior QA Engineer | QA Engineer | Senior QA Engineer | Lead QA Engineer |
|---|---|---|---|---|
| Testdesign og analyse | Udfører eksisterende testcases omhyggeligt, skriver nye cases til små stories, der dækker hovedforløbet og de oplagte kanttilfælde, og spørger ind til uklare krav, før testen starter. | Skriver en testplan for hver feature i teamet, der dækker kanttilfælde, rettigheder, datatilstande og integrationer, og gennemgår kravene, før udviklingen starter, for at finde huller. | Designer teststrategien for projekter, der spænder over flere features eller teams, beslutter, hvad der skal dækkes på unit-, API- og end-to-end-niveau, og fokuserer indsatsen på de dele, der med størst sandsynlighed går i stykker. | Definerer, hvordan virksomheden beslutter, hvad der skal testes og hvor grundigt, ud fra risiko og brugsdata, og sørger for, at alle teams anvender det ensartet. |
| Testautomatisering | Tilføjer automatiserede tests til et eksisterende framework ved at følge etablerede mønstre, kører suiten lokalt og rapporterer fejl, de ikke kan forklare, i stedet for at køre dem igen, indtil de går igennem. | Automatiserer regressionstestene for teamets features, holder dem stabile og læsbare og retter eller fjerner ustabile tests i stedet for at ignorere dem. | Designer strukturen i en automatiseringssuite, kobler den på CI/CD-pipelinen med fornuftige kørselstider og reviewer de tests, som udviklere og andre QA engineers skriver. | Vælger virksomhedens testværktøjer og fælles infrastruktur, afvejer lagene i testpyramiden på tværs af produkter og holder hele suiten så hurtig, at teamene faktisk venter på den. |
| Fejlanalyse og fejlrapportering | Opretter fejlrapporter med klare trin, forventet og faktisk resultat og miljøet, så en udvikler kan genskabe problemet uden at stille opfølgende spørgsmål. | Indkredser fejl ved hjælp af logs, netværkstraces og databasen, vurderer deres alvor ud fra konsekvensen for brugerne og bekræfter rettelser, inklusive tilfældene omkring dem. | Undersøger periodiske fejl og fejl, der kun opstår i produktion, på tværs af services, ser mønstre i tilbagevendende fejl og omsætter dem til forslag, der fjerner en hel kategori af fejl. | Ejer, hvordan virksomheden registrerer og prioriterer fejl, rapporterer tendenser i fejl, der slipper igennem, til udviklingsledelsen og sørger for, at de største fejlkilder får finansierede rettelser. |
| Release- og risikovurdering | Gennemfører de tjek, der er tildelt før en release, rapporterer, hvad der blev testet, og hvad der ikke gjorde, og giver udtryk for bekymringer over for en mere erfaren QA engineer. | Giver en klar go- eller no-go-anbefaling for teamets releases, forklarer de kendte risici og det, der ikke er testet, og deltager i tjek efter releasen. | Beslutter sammen med udviklerne releasetilgangen for risikable ændringer – feature flags, gradvis udrulning, ekstra overvågning – og leder testen under hændelser og hotfixes. | Fastlægger de releasestandarder, alle teams arbejder efter, definerer, hvornår en release kan blokeres, og er den, ledelsen spørger, om produktet er klar til en stor lancering. |
| Kvalitetspraksis | Følger teamets definition of done og testworkflow og påpeger trin, der bliver sprunget over eller er forvirrende. | Deltager i refinement og designdrøftelser for tidligt at tilføje acceptkriterier og hensyn til testbarhed og arbejder sammen med udviklerne om, hvad de skal dække i deres egne tests. | Forbedrer testworkflowet i et eller to teams – testmiljøer, testdata, tjeklister til review – og måler, om ændringen reducerede antallet af fejl, der slipper igennem. | Former kvalitetspraksis på tværs af udviklingsorganisationen, beslutter, hvor QA engineers placeres, og hvad udviklerne ejer, og gør kvalitet til et fælles ansvar i stedet for ét teams job. |
| Mentorskab og videndeling | Dokumenterer, hvad de lærer om produktet, mens de tester, og deler nyttige fund og værktøjer med teamet. | Holder teamets testdokumentation opdateret, introducerer nye kolleger til produktområdet og forklarer testteknikker for udviklere, der spørger. | Er bevidst mentor for junior QA engineers, holder sessioner om testtilgange for udviklere og deltager i jobsamtaler til QA-roller. | Udvikler QA-gruppens færdigheder og karriereveje, definerer, hvordan QA engineers ansættes og onboardes, og udvikler de næste senior og lead QA engineers. |
Rul tabellen sidelæns for at se alle niveauer.
Download som CSV Kan åbnes i Excel, Google Sheets eller Numbers.
Junior QA Engineer: hvad der forventes
Tester veldefinerede features ud fra eksisterende testcases og lærer produktet og dets brugere at kende. Enkelte stories eller fejlrettelser i ét område af produktet, med testplaner, som en mere erfaren kollega reviewer.
- Testdesign og analyse
- Udfører eksisterende testcases omhyggeligt, skriver nye cases til små stories, der dækker hovedforløbet og de oplagte kanttilfælde, og spørger ind til uklare krav, før testen starter.
- Testautomatisering
- Tilføjer automatiserede tests til et eksisterende framework ved at følge etablerede mønstre, kører suiten lokalt og rapporterer fejl, de ikke kan forklare, i stedet for at køre dem igen, indtil de går igennem.
- Fejlanalyse og fejlrapportering
- Opretter fejlrapporter med klare trin, forventet og faktisk resultat og miljøet, så en udvikler kan genskabe problemet uden at stille opfølgende spørgsmål.
- Release- og risikovurdering
- Gennemfører de tjek, der er tildelt før en release, rapporterer, hvad der blev testet, og hvad der ikke gjorde, og giver udtryk for bekymringer over for en mere erfaren QA engineer.
- Kvalitetspraksis
- Følger teamets definition of done og testworkflow og påpeger trin, der bliver sprunget over eller er forvirrende.
- Mentorskab og videndeling
- Dokumenterer, hvad de lærer om produktet, mens de tester, og deler nyttige fund og værktøjer med teamet.
QA Engineer: hvad der forventes
Ejer testen af features i ét team, fra at læse kravene til at godkende releasen. Ét produktteams features, inklusive deres manuelle og automatiserede tests.
- Testdesign og analyse
- Skriver en testplan for hver feature i teamet, der dækker kanttilfælde, rettigheder, datatilstande og integrationer, og gennemgår kravene, før udviklingen starter, for at finde huller.
- Testautomatisering
- Automatiserer regressionstestene for teamets features, holder dem stabile og læsbare og retter eller fjerner ustabile tests i stedet for at ignorere dem.
- Fejlanalyse og fejlrapportering
- Indkredser fejl ved hjælp af logs, netværkstraces og databasen, vurderer deres alvor ud fra konsekvensen for brugerne og bekræfter rettelser, inklusive tilfældene omkring dem.
- Release- og risikovurdering
- Giver en klar go- eller no-go-anbefaling for teamets releases, forklarer de kendte risici og det, der ikke er testet, og deltager i tjek efter releasen.
- Kvalitetspraksis
- Deltager i refinement og designdrøftelser for tidligt at tilføje acceptkriterier og hensyn til testbarhed og arbejder sammen med udviklerne om, hvad de skal dække i deres egne tests.
- Mentorskab og videndeling
- Holder teamets testdokumentation opdateret, introducerer nye kolleger til produktområdet og forklarer testteknikker for udviklere, der spørger.
Senior QA Engineer: hvad der forventes
Former, hvordan et eller to teams bygger kvalitet ind, og ejer teststrategien for større projekter. Et eller to teams' teststrategi, automatiseringssuiter og releasebeslutninger samt projekter, der krydser teamgrænser.
- Testdesign og analyse
- Designer teststrategien for projekter, der spænder over flere features eller teams, beslutter, hvad der skal dækkes på unit-, API- og end-to-end-niveau, og fokuserer indsatsen på de dele, der med størst sandsynlighed går i stykker.
- Testautomatisering
- Designer strukturen i en automatiseringssuite, kobler den på CI/CD-pipelinen med fornuftige kørselstider og reviewer de tests, som udviklere og andre QA engineers skriver.
- Fejlanalyse og fejlrapportering
- Undersøger periodiske fejl og fejl, der kun opstår i produktion, på tværs af services, ser mønstre i tilbagevendende fejl og omsætter dem til forslag, der fjerner en hel kategori af fejl.
- Release- og risikovurdering
- Beslutter sammen med udviklerne releasetilgangen for risikable ændringer – feature flags, gradvis udrulning, ekstra overvågning – og leder testen under hændelser og hotfixes.
- Kvalitetspraksis
- Forbedrer testworkflowet i et eller to teams – testmiljøer, testdata, tjeklister til review – og måler, om ændringen reducerede antallet af fejl, der slipper igennem.
- Mentorskab og videndeling
- Er bevidst mentor for junior QA engineers, holder sessioner om testtilgange for udviklere og deltager i jobsamtaler til QA-roller.
Lead QA Engineer: hvad der forventes
Fastlægger virksomhedens tilgang til kvalitet og gør alle teams bedre til at udgive med færre fejl, der slipper igennem. Kvalitet i hele produktet: fælles testinfrastruktur, releasestandarder og hvordan QA bemandes og praktiseres.
- Testdesign og analyse
- Definerer, hvordan virksomheden beslutter, hvad der skal testes og hvor grundigt, ud fra risiko og brugsdata, og sørger for, at alle teams anvender det ensartet.
- Testautomatisering
- Vælger virksomhedens testværktøjer og fælles infrastruktur, afvejer lagene i testpyramiden på tværs af produkter og holder hele suiten så hurtig, at teamene faktisk venter på den.
- Fejlanalyse og fejlrapportering
- Ejer, hvordan virksomheden registrerer og prioriterer fejl, rapporterer tendenser i fejl, der slipper igennem, til udviklingsledelsen og sørger for, at de største fejlkilder får finansierede rettelser.
- Release- og risikovurdering
- Fastlægger de releasestandarder, alle teams arbejder efter, definerer, hvornår en release kan blokeres, og er den, ledelsen spørger, om produktet er klar til en stor lancering.
- Kvalitetspraksis
- Former kvalitetspraksis på tværs af udviklingsorganisationen, beslutter, hvor QA engineers placeres, og hvad udviklerne ejer, og gør kvalitet til et fælles ansvar i stedet for ét teams job.
- Mentorskab og videndeling
- Udvikler QA-gruppens færdigheder og karriereveje, definerer, hvordan QA engineers ansættes og onboardes, og udvikler de næste senior og lead QA engineers.
Sådan tilpasser du stigen
Skriv jeres fordeling af manuel og automatiseret test ned
Hvis jeres QA engineers fokuserer på udforskende test, så forkort rækken Testautomatisering og udvid Testdesign og analyse. Hvis de primært bygger automatisering, så hæv forventningerne til kodekvalitet. Gør under alle omstændigheder valget udtrykkeligt, så ingen bliver vurderet ud fra et job, de ikke blev ansat til.
Gem Lead-niveauet, til det er et rigtigt job
Med to eller tre QA engineers har virksomheden som regel kun brug for junior-, mellem- og seniorniveau. Tilføj Lead, når nogen reelt sætter kvalitetsstandarder for alle teams – ikke som belønning til den tester, der har været der længst. I denne karrierestige er Lead et specialistniveau; hvis jeres QA lead også leder testere, så tilføj forventningerne til personaleledelse fra karrierestigen for engineering managers.
Afstem niveauerne med karrierestigen for udviklere
Match hvert QA-niveau med det udviklerniveau, der har sammenligneligt ansvarsområde og løn. Når en Senior QA Engineer står ved siden af en Seniorudvikler, bliver et skift mellem de to karrierespor et skridt til siden og ikke en degradering eller et spring.
Indsaml evidens, ikke antal fejl
Til check-ins og forfremmelsessager kan du samle eksempler som en testplan, der fangede en dyr fejl, en ustabil testsuite, der blev gjort pålidelig, eller en releasebeslutning, der holdt. At tælle rapporterede fejl belønner støj og straffer testere i stabile teams.
FAQ
Spørgsmål om denne stige
Hvor mange niveauer skal en karrierestige for QA engineers have?
Tre eller fire er som regel nok for en virksomhed med 20–200 medarbejdere, fordi QA-grupper er små. Denne skabelon bruger fire: Junior QA Engineer, QA Engineer, Senior QA Engineer og Lead QA Engineer. Tilføj kun et femte, når arbejdets omfang reelt vokser ud over at sætte kvalitetsstandarder for hele produktet.
Skal manuelle testere og QA-automatiseringsfolk dele én karrierestige?
I de fleste mindre virksomheder: ja. Kernen i jobbet – at forstå risiko, designe tests og vurdere releases – er den samme; kun værktøjerne er forskellige. Behold én karrierestige, og aftal pr. person eller pr. team, hvor meget af rækken Testautomatisering der gælder.
Kan en QA engineer skifte til udviklersporet?
Ja, og det fungerer bedst som et planlagt skift. Sammenlign personen med karrierestigen for softwareudviklere, aftal nogle få udviklingsaktiviteter som at eje små features eller fejlrettelser, og flyt personen, når vedkommende konsekvent lever op til det niveau. Erfaringen med test gør dem som regel til stærkere udviklere, ikke svagere.
Hvordan måler man en QA engineers præstation uden at tælle fejl?
Se på resultater og adfærd: fejl i deres område, der slap igennem til produktion, hvor pålidelig og hurtig den automatiserede suite er, hvor tidligt de påpeger risici, og hvordan releasebeslutningerne holdt. Drøft konkrete eksempler ud fra karrierestigen i faste check-ins i stedet for kun at læne dig op ad dashboards.
Hvor mange QA engineers har et team af udviklere brug for?
Der er ikke noget fast forhold. Mange virksomheder af denne størrelse har én QA engineer for hver fire til otte udviklere, men det rigtige antal afhænger af, hvor meget udviklerne tester deres eget arbejde, og hvor dyr en fejl er for jeres brugere. Hold øje med fejl, der slipper igennem, og forsinkede releases, og ansæt, når et af dem bliver ved med at stige.
Byg denne karrierestige i LadderKit – gratis
Sæt dens niveauer og færdigheder op til dit team, vurdér folk ud fra dem i check-ins, og hold beslutninger om forfremmelser konsistente.
Gratis abonnement · Intet kreditkort nødvendigt
Relaterede skabeloner
Engineering
DevOps Engineer
Fire niveauer fra Junior til Staff DevOps Engineer og seks kompetencer – fra infrastruktur til at styrke udviklerne.
- 4 niveauer
- 6 kompetencer
Engineering
Engineering Manager
Fire niveauer fra Engineering Manager til VP of Engineering og seks ledelseskompetencer.
- 4 niveauer
- 6 kompetencer