Skal QA være en del af agile teams?

For at sige det lige ud, er der noget som har gået mig på længe: spørgsmålet om den rigtige sammensætning af et agilt team. Et agilt team er jo selv-organiserende og tværfunktionel hvis man følge best-practice, og dermed skal teamet besidde alle de nødvendige kompetencer for at kunne levere et klar-til-release produkt fra iteration til iteration. Det vil sige ingen hængere ift. test, ingen afsluttende “test runs” så test må ikke være en flaskehals. Betyder det så at test bør være en stærk kompetence hos et agilt team? Ja! Er det så ikke bare med at ansætte flere testere?

Sagen er at titler og roller som “Tester” udvandes i den agile ideologi. Mens der er mange agile teams benytter sig af Scrum, skriver Ken Schwaber og Jeff Sutherland i deres “The Scrum Guide” fra 2013 om et typisk Scrum team:

  • Scrum recognizes no titles for Development Team members other than Developer, regardless of the work being performed by the person; there are no exceptions to this rule.
  • Scrum recognizes no sub-teams in the Development Team, regardless of particular domains that need to be addressed like testing or business analysis; there are no exceptions to this rule; and,
  • Individual Development Team members may have specialized skills and areas of focus, but accountability belongs to the Development Team as a whole.

Så der er ingen titler, ingen undergrupper og ansvaret ligger altid hos teamet. Det er netop op til teamet at søge de nødvendige kompetencer – enten ved at tage dem ind på teamet eller søge dem ude. Traditionelt har testen ligget til sidst i udviklingsprocessen, selv om gode intentioner har forsøgt at skube den tidligere, som i V-modellen.

På et agilt team tester vi ideelt hele tiden, så snart der er noget klar til det. Realiteten kan være en anden – det afhænger af hvor god er teamet til at planlægge og styre igennem mængen af opgaver, så der er noget at lave til alle.

Efter nærmere overvejelse hos den lokale HR manager tilknyttet vores fiktive team, bør testerens profil matche typen af de test opgaver der kan forekomme:

  • Tidlig test kan være at review’e stories og accept kriterier for at sikre dem efter INVEST og på den måde få kvalitetssikring tidligere ind i processen
  • Tidlig og løbende test er at sikre alle acceptkriterier er testet, intet er glemt og eventuelle ændringer (som helt sikkert vil være der!) er reflekteret i fælles forståelse og evt dokumentation i form af tests eller tekstuel beskrivelse
  • Tidlig test kan indebære review af arkitektur med henblik på testbarhed.
  • Tidlig test kan indebøre review af produktionskode og input til automatiseret test (som regel kode igen)
  • Tidlig test kan indebære at teste REST/ API interfaces med tools, både funktionelt og måske med heblik på performance og sikkerhed.

Disse er blot for at nævne nogle, ud fra egne erfaringer – men de illustrerer ret godt et billede af en mere teknisk profil der er i stand til at arbejde sammen med teamet meget tidligt i processen. Samtidig har profilen en rigtig god forretningsforståelse, overblik og kommunikationsevner. Findes der sådan en rolle vi kan “hyre ind” på teamet?

Der er højst sandsynligvis få som er gode til det hele på en gang. Og det er netop pointen med agile / scrum teams at der skal ikke være sådan nogle roller! Kompetencer bør være spredt, og ideelt kan udviklere også teste, mens de test mindede førhenværende testere skal kunne finde sin anvendelse i at understøtte testen på alle mulige måder — også ved at skrive (test) kode. Hermed er agil QA født som en kompetence, snarere end en rolle!

Poul sagte:

  • Agil QA: et mindset du kan tilegne dig for at blive rigtig god til at kvalitetssikre(ok det er nok ikke kun mig der har sagt det, men jeg har i hvert faldt skrevet det her)

Tilbage ved spørgsmålet om hvorvidt bør QA være en del af et agilt team: forudsat teamet har et behov, er det en rigtig god ide! Jeg ved at svar der indeholder et “men” har en begrænsende virkning, så måske kunne man formulere det som “det afhænger af kontekst, såsom teamets sammensætning og typen af opgaver”.

Hvis teamets mindset ligger langt fra “vi skal også tænke på testbarhed og teste selv”, eller når disse mangler decideret som kompetencer — så kan man ikke komme udenom det. En eller flere personer med stærke kompetencer, eller om ikke andet viljen til at lære QA kan så frø og starte en kultur hvor test er en naturlig test af udvikling (så ja til en dedikeret QA i en periode). En del af opgaven vil også være at lære teamet om QA, hvilket er ret svært uden at være en del af teamet.

Et mere modent team med kompetencer i kvalitetssikring kan måske undvære en dedikeret QA i en periode. Der vil dog være fare for at fokus på god kvalitetssikring vil blive udvandet, og her kunne man tænke et setup hvor QA rollen er “assisterende” i form af en Test Coach der både kan stille de rigtige spørgsmål og rette teamets opmærksomhed efter de ting som kræver dette. Men hvem bestemmer så om hvorvidt teamet er modent nok til at undvære en dedikeret QA..? Jeg ville ønske jeg kunne være fagligt korrekt og skrive “teamet”, men i realiteten har organisationen ofte den sidste ord. Økonomi, projektmål og politik vil jeg ikke ind på i dette indlæg, så tilbage står en klar anbefaling om at teamet i hvert fald giver udtryk for hvad er i deres overbevisning et behov for at være gode og effektive til deres arbejde, og ikke mindst selv søge veje derhen (hvilket jeg også skrev om i et tidligere indlæg).

ps. på samme måde kunne man tage en dialog om roller / kompetencer som user experience (UX), Business Analyst (BA) osv. Hvis teamet laver et produkt der er afhængig af god UX, skal denne kompetence ikke være en mangelvare eller en flaskehals. Selv den bedste dedikeret UX’er tage på ferie, blive sygmeldt eller generelt  være en eftertragtet person alle vil tale med 😀 – et agilt team bør ikke være afhængig af enkelte personer hverken på eller udenfor teamet!

Reklamer

Skriv et svar

Udfyld dine oplysninger nedenfor eller klik på et ikon for at logge ind:

WordPress.com Logo

Du kommenterer med din WordPress.com konto. Log Out /  Skift )

Google+ photo

Du kommenterer med din Google+ konto. Log Out /  Skift )

Twitter picture

Du kommenterer med din Twitter konto. Log Out /  Skift )

Facebook photo

Du kommenterer med din Facebook konto. Log Out /  Skift )

Connecting to %s