Testarens roll – förändringen driven av agila strömmar.

För att prata om agil testning måste man först definiera vad man menar med agil utveckling och reflektera över hur denna tillkommit. Den agila utvecklingsmodellen är framtagen av utvecklare som själva ville förbättra sin ansats till hantverket. Det är ett resultat av att man under en lång tid förädlat och förbättrat detta hantverk och dessutom tagit fram verktyg för att underlätta arbetet.

Agil utveckling är inte en process utan mer ett synsätt med vissa grundstenar. Eftersom det blivit så populärt så är det många i ledande befattning som idag efterfrågar att utvecklingen ska ske enligt agila principer. Det har gjort att många som inte velat förändras tvingats in i någon form av agil process. Resultatet är ganska brokigt och många team som påstår sig jobba agilt utan att applicera många grundprinciper. Detta gör det hela lite komplext när man ska reflektera över hur testning bäst gör sig eller vilka krav som ställs, det beror på hur långt teamet själva kommit med en agil utvecklings ansats och vilka principer de valt att applicera.

En av grundstenarna i agil utveckling är att hålla hög nivå på kvaliteten i hantverket så att den tekniska skulden hålls låg. I och med detta skall man snabbt få upp momentum i utvecklingen och så snabbt som möjligt leverera affärsvärde. Det ökar vinstmarginalen per nerlagd timme. Man förespråkar också till stor del att motsträva specialister och säger att det bästa resultatet för affärsvärde nås genom samarbete i ett team. Detta ställer höga krav på utvecklarens breddkunskaper: att förstå vad affärsmålet är, arbeta för en arkitektur som har håller hög kvalitet, och som kan förändras i hög takt.

Så hur håller man en låg teknisk skuld? Och vad utgör ett bra agilt team? En av grundprinciperna är snabb återkoppling och att i hög grad använda verktyg och automatisering för detta. T.ex. att applicera kontinuerlig integration, testdriven utveckling och hög grad av automatisk testning på flera nivåer. Både funktionellt och icke-funktionellt, modulnära och på övergripande systemnivå. Testdriven utveckling syftar också till att tvinga fram en bra design, vilket är en bra förutsättning både för kvalitet och testbarhet. Om man kan få snabb återkoppling kan man snabbt isolera vilken nytillkommen del som skapade problem och därmed förkortas tiden för korrigering av problemet och framförallt att man hanterar det direkt istället för att lägga det på skuldberget.

Man kan hävda att hur ett utvecklingsteam applicerar de olika agila principerna inte är något som bör beröra testrollen. I den kontextkänsliga skolan säger man till och med att man lägger in det som en del av kontexten och helt enkelt anpassar testningen utifrån förutsättningarna. Det är till väldigt stor del helt rätt och kommer att bidra till ökad marginal på varje nerlagd utvecklingstimme. Den kontextkänsliga skolans ansats kommer maximera nyttan av varje nerlagd testtimme, vilket kan sägas vara att maximera affärsvärdet. Dock kommer den ansatsen kommer inte jobba för att hålla ner den tekniska skulden, men ge bra direkta resultat.

Då är frågan: Kan den framtida testrollen både bidra till att hålla nere den tekniska skulden och maximera vinstmarginalen för varje nerlagd testtimme? Borde inte ansvaret för teknisk skuld ligga på utvecklingssidan? Tar man upp teamperspektivet som är starkt inom agil utveckling så blir inte detta så svart och vitt. Där förespråkar man inte en uppdelning av rollerna i de som producerar och de som kritiskt granskar oberoende utfallet av det som producerats. Eftersom alla i teamet är en del av strävan att nå kvalitet och effektivitet är alla en del av målet. Självklart är det då naturligt att ifrågasätta behovet av specialistkompetenser alls.

Om man ser vart trenderna är på väg när det gäller kvalitetsfrågor i den agila utvecklingsvärlden så handlar det om att flera andra roller i högre grad blir involverade i olika aktiviteter inom testning på många olika nivåer. Att använda verktyg både för att automatisera testningen och för att automatisera hela deploymentkedjan. Skapa en snabb återkopplingsloop och värna om kontinuerlig låg teknisk skuld samt en integration mellan utvecklar- och testrollerna.

Man skulle kunna se framtidens testare som en sorts kvalitetscoacher. Istället för att se utvecklare som rena producenter och testare som kvalitetsansvariga bör man arbeta för att teamet som en helhet är delaktiga i kvalitetsarbetet och hjälps åt att hålla den tekniska skulden låg. Kravbilden för testaren i detta är relativt hög tekniskt kunnande, kompetent inom testning och testdesign, men framförallt en strävan att hela tiden vilja lära sig mer och effektivisera.

Nu lite om de roller vi idag har i teamet jag arbetar med. Vi har valt att dela in gruppen i två rollkategorier. Ett vi kallar testverktygsutvecklare, och ett som vi kallar testingenjörer. Rollen som testverktygsutvecklare är bred och inkluderar både att skapa eller använda existerande verktyg och jobba för att deployment pipeline ska automatiseras och effektiviseras. Men det kan även vara att refaktorera testdesignen i vissa fall eller att hjälpa ett team sätta upp ett projekts automatiska testning.

Kompetensmässigt kräver detta både en god utvecklarförmåga för att göra bra lösningar, men också kompetens runt hur utvecklingsprocessen kan se ut, verktyg och på vilket sätt man på ett bra sätt kan automatisera så användandet blir effektivt.

Testingenjör är också ett brett begrepp, det kan innebära uppgifter allt ifrån att utöka existerande automatiska testsviter med nya bra testfall för att utöka kravtäckningen, att refaktorera testfall som inte är bra eller inte stämmer överens med kravbilden, jobba med explorativ testing direkt med ett team och att deltaga eller leda olika former av sessionsbaserad testning (SBTM) där andra testingenjörer, utvecklare eller affärskunniga supportpersoner deltar.

Vi utövar SBTM som ramverk för explorativ testning, och skapar ”test charters” i samma verktyg som vi har alla ärenden dvs både krav och buggar. Verktyget är även integrerat med versionshanteringssystemet och alla incheckningar refererar till ärenden eller krav. En test charter beskriver målet och syftet med testningen inom ett område men innehåller ingen detaljerad testdesign. När vi utövar SBTM genomförs detta i ett dedikerat rum vi kallar ”Testlabbet” för att få kvalitetstid i testningen samt en öppen dialog mellan alla som testar ihop.

Att jobba med explorativ testning med supportpersonal är väldigt effektivt. Kompetensen om domänen minskar orakelproblematiken. När nya komponenter, ny affärsfunktionalitet ska ut till kunder finns det ofta ett behov för supporten att skaffa sig kompetens om vad detta medför. Genom testningen finns ett naturligt sätt att lära sig, vilket undviker annan form av överlämning kompetensmässigt av en ny version eller produkt. Många är väldigt duktiga på att snabbt skaffa fram rätt information som behövs för att skriva felrapporter och med en kombination av testingenjörer som coachar blir kvaliteten i felrapporter hög vilket gör dem enklare att hantera för utvecklare. Med SBTM ges också en lagom styrande struktur för att kunna dela upp arbetet mellan flera personer samt se till att vi går igenom de områden vi har satt upp som mål för sessionen.

Sammanfattningsvis kan sägas att den framtida testrollen är bredare. Detta gäller dels vilka man arbetar med i olika testaktiviteter, dels att test design anses vara en integrerad del av allas arbete, och dessutom att ha djupare kompetens tekniskt och verktygsmässigt. Lite på liknande sätt som utvecklarrollen har högre krav och bredare fokus i en agil utvecklingsprocess. I båda rollerna ingår att man bäst lär sig och blir bättre genom att jobba tätt ihop med erfarna personer och därför lär sig hantverket istället för att skapa interna hierarkier i roller.

Anna Almén
Engineering • Orc Group
Manager Test & Build

---------------------------------------------------------------------------------------

Anna Almén är bland annat ledare för Release Services for Orc Software med fokus på testing men även ledare för andra roller. Sedan 1997 har Anna arbetat i finansmarknaden i olika roller både som utvecklare, produktchef samt teamchef både för utvecklare och testare. Sedan 2008 har fokus legat till större delen mot testning både i en klassisk test organisation och agila organisationer, men alltid med team som mer eller mindre har automatisk testning som bas.

---------------------------------------------------------------------------------------

Orc provides powerful solutions for the global financial industry. Orc delivers trading and market access solutions that are used by proprietary trading and market making firms, investment banks, hedge funds and brokerage houses worldwide.

Their business continues to shape the way their customers trade today, tomorrow and in the future.

With an organization spread across every major financial center, offering market solutions tailored to meet both global and local requirements in EMEA, the Americas and Asia Pacific, Orc is well positioned to provide best-of-breed trading technology solutions and services for the worldwide financial industry.