Kravprofil för testautomatiserare: sluta leta efter en manuell testare med kodkunskap

Vem hittar felen i er produkt i dag: era testare eller era kunder? Om svaret gör ont är en testautomatiserare ofta rätt rekrytering. Men rollen har bytt skepnad de senaste åren, och kravprofiler som beskriver gårdagens QA-roll lockar fel kandidater.

Automatiserare är utvecklare, skriv profilen så

En modern testautomatiserare bygger kod: testramverk, pipelines, testdata och miljöer. Det är ett utvecklarjobb med kvalitet som specialitet. Kravprofiler som utgår från manuell testning med lite skript på toppen attraherar kandidater som är på väg bort från marknaden, inte in i den. Skriv i stället profilen som för en utvecklare och lägg kvalitetsansvaret ovanpå.

Kärnan i profilen

• Programmeringsvana på riktigt: kunna bygga och underhålla ett ramverk, inte bara spela in tester
• Förståelse för teststrategi: vad ska automatiseras, på vilken nivå, och vad ska inte automatiseras alls
• Erfarenhet av CI/CD: tester som inte körs automatiskt vid varje ändring är dekoration
• Kommunikativ förmåga: rollen ska påverka hur hela teamet bygger, inte sitta sist i kedjan

Varningssignaler i båda riktningarna

Var vaksam på kandidater som mäter sin framgång i antal testfall. Tusen sköra tester som går sönder vid varje release är sämre än hundra robusta. Men var lika vaksam på er egen organisation: om utvecklarna ser QA som någon annans problem kommer även en lysande automatiserare att misslyckas. Ställ er frågan innan ni rekryterar: är vi beredda att låta den här personen ändra vårt sätt att jobba? Om svaret är nej är det den diskussionen som ska tas först, inte annonsen som ska skrivas.

Ett sista råd: låt kandidaten granska en bit av er riktiga testkod eller pipeline under intervjun. Deras reaktioner, frågor och förslag på en kvart säger mer än två timmars hypotetiska resonemang. De bästa kandidaterna älskar den övningen. Det är också ett tecken.

Räkna slutligen med att rollen betalar sig i det tysta. Färre produktionsfel, snabbare releaser och utvecklare som vågar ändra i koden syns inte i någon enskild rapport, men de märks i tempot efter ett halvår. Sätt gärna ett par enkla mått före rekryteringen, till exempel antal fel som når produktion och tid från kodändring till release. Då kan ni visa svart på vitt vad rekryteringen gav, vilket gör nästa kvalitetssatsning betydligt lättare att motivera.