Historien upprepar sig när kunskapen inte finns

Åren går men problemen består skulle man kunna säga… I drygt tjugo år har jag mött företag med olika mognadsgrad med avseende på hur bra kontroll de har på sin mjukvaruutveckling. Problemen som har presenterats för mig har inte varierat allt för mycket och det som till en början gjorde mig en aning chockad visade sig senare bara vara en indikation på den resa som väldigt många företag gör och har gjort under dessa år. Från att själv har gjort en lång kunskapsresa under många år på universitetet var detta också resan där dessa företag antingen hade samlat på sig kunskap aktivt eller lärt sig av sina misstag.

När jag började arbeta som konsult i början av 2000 fick jag möjlighet att samarbeta med en erfaren kollega som lärde mig många saker om test och testarbete, en sann mentor. Tillsammans var vi ute hos ett antal företag och gjorde processutvärderingar med fokus på hur man bedrev sin testverksamhet. Dessa uppdrag och diskussionerna vi hade lärde mig oerhört mycket och gav mig erfarenheter som är applicerbara än idag. Åren gick och jag lämnade konsultbranschen för att arbeta som chef på både mindre och större företag. På dessa företag bedrev vi även processförbättringsprojekt i varierande grad beroende på hur mogna företagen var. Efter några år var jag sedan tillbaka i konsultbranschen igen och första uppdraget var att göra en processutvärdering.

Efter att ha genomfört de första intervjuerna började jag se ett mönster. Ett mönster som jag kände igen allt för väl från de första åren som konsult. Problembilden var den samma då som förr så min fråga var om det inte hade hänt mer på de tio år som hade passerat? Jag började fundera på att leta fram en gammal rapport och göra en ”sök-ersätt” på företagsnamnet och krydda med några citat om problem med att få ordning på den agila utvecklingen och på så sätt göra det enkelt för mig. Nu blev det inte så utan arbetet med en djupgående analys inleddes och genomfördes. Rapporten blev omfattande och kunden var nöjd med resultatet, både analysen och den handlingsplan vi lade fram.

Under resans gång funderade jag väldigt mycket på varför det inte hade hänt mer på dessa tio åren. Slutsatsen blev att det har hänt massor av saker och att många företag har utvecklats och blivit mognare. Jag kom också till insikten att under dessa år hade det tillkommit flera företag som inte har mjukvaruutveckling som sitt primära eller ens sekundära levebröd. Exempelvis handlar det om företag där man utvecklat vissa stödsystem ute i de olika affärsenheterna och sedan beslutat sig för att ta bilda en IT-enhet eller företag vars produkter har utvecklats mot att bli mer och mer beroende av mjukvara runtomkring. Min insikt var att det saknades kompetens om vad test och aktivt kvalitetsarbete innebär och att man också hade inställningen att man kan själv och därför sprang på mina efter mina.

Min uppfattning är att dessa företags resa hade både blivit billigare och enklare om man hade tagit ett helhetsgrepp om kompetensutvecklingen satsat på att utbilda sin personal på olika nivåer i organisationen om vad test och kvalitetssäkring innebär. Detta oavsett om man arbetar traditionellt eller mer agilt. I början av 2000 fanns det tyvärr inte så många utbildningar inom området men idag finns det ett betydligt större utbud som bör passa både mindre och mer mogna organisationer för programvaruutveckling. Om inte så skulle vara fallet så går det alltid att skräddarsy en utbildning för de speciella krav en organisation kan ha eller anpassa till exempel övningar till internt material.

En av de viktigaste aspekterna med att gå en kurs är, både enligt mig själv och väldigt många kursdeltagare, mötet med andra personer oberoende av om det är personer från en annan avdelning eller ett annat företag. Att få lyssna till andras problemställningar och erfarenheter är något som man inte får genom att läsa en bok hemma på sin kammare. De diskussioner man har på luncherna eller fikapauserna har en väldigt stor betydelse för att sätta in kunskapen i ett sammanhang. Det är också på kursen man kan få hjälp av en erfaren lärare att börja bena ut vad ens problem består av för att sedan koppla detta till kursinnehållet för att sedan komma tillbaka till arbetsplatsen utrustad med applicerbara förbättringsverktyg.

Har du påbörjat din kunskapsresa?

Skribent: Dr. Magnus C. Ohlsson

Informator erbjuder flera spännande kurser inom Kravhantering och Testmetodik. Se alla våra kurser inom Krav och Test här

Läs mer

Seminarier för den agila testaren!

Välkommen på våra nya, kostnadsfria seminarier för den agila testaren!

I Stockholm kan du gå på Magnus C Ohlssons prisbelönta seminarium The Agile Hangover - handling testable agile requirements. Föredraget kom på andra plats när Foo Café utsåg de bästa föredragen 2014. Magnus C. Ohlsson är lärare på utbildningarna ISTQB Foundation, ISTQB Advanced Test Manager, Grundläggande Testdesign, Tillämpad Testdesign och Tillämpad Testledning. 
Datum: Torsdag 11 dec, Stockholm

Är du nyfiken på kursen ISTQB Agile Tester men vill veta mer innan du bokar dig på kurs?
Då är seminariet  Den T-formade testaren – en agil superhjälte något för dig. Detta seminarium hålls på Drakegatan 7 i Göteborg. Det talas allt mer om att ha en T-formad kompetens. Medarbetare ska ha både bredd och djup. Men vad innebär det? Måste testare även kunna koda och hur djup kunskap ska vi ha på bredden? Är det rimligt att alla kan allt i ett självorganiserande team? Vi diskuterar varför den T-formade kompetensen blivit så viktig och formar tillsammans vår agila superhjälte: den T-formade testaren. Se fram emot ett seminarium med intressanta diskussioner!
Datum: Torsdag 11 dec, Göteborg

Läs mer om seminarierna och boka dig här

Här kan du läsa mer om nya kursen ISTQB Agile Tester

Markus Niklasson & Michael C Ohlsson                                                                                                                                                




  

Läs mer

Den mjuka och den hårda testaren – varför båda behövs i det agila teamet

Agil utveckling har blivit allt vanligare inom mjukvaruutveckling och många företag har anammat det agila tänket för att hitta sin väg framåt mot en effektivare utveckling, med mer kontinuerliga leveranser och en lösning som ligger närmare att uppfylla det behov som kunden har. Agila team bildas och att test behöver inkluderas i teamen håller de flesta med om. Frågan är vilken testkompetens som behöver finnas i ett agilt team?

Många av oss som primärt jobbar med test har en resa framför oss att anpassa oss till den nya miljö som agil utveckling innebär, med mer frekventa leveranser, ständigt föränderlig kravbild, kommunikation och samarbete med övriga discipliner, osv. Miljön ställer nya krav på oss som testare och det är inte alltid lätt att veta hur man ska passa in och bidra i sitt team.

För att försöka bena ut vilken testkompetens som krävs i ett agilt team kan man prata om två olika testare, den mjuka och den hårda. Den mjuka testaren har fokus på verksamheten och användarna, lär sig hur systemet ska användas och vilken nytta systemet ska tillföra. Troligtvis arbetar den mjuka testaren en hel del med utforskande testning och har frekvent kommunikation med användare och verksamheten. Den hårda testaren har en djupare teknisk förståelse med kunskap om gränssnitt för tester, systemets arkitektur, processer för continuous integration och continuous delivery.

Förmodligen jobbar den hårda testaren med testautomatisering och design av automatiska testfall genom ATDD eller BDD. Tillsammans med utvecklarna arbetar den hårda testaren för att hålla utvecklingstakten i teamet uppe genom att skapa en säkerhet vid förändringar och förhindra regression.

Förhållandet mellan den mjuka sidan och den hårda sidan beror självfallet på vad det är för typ av lösning eller system som man tar fram. För vissa system bör man lägga större vikt på den mjuka sidan och för andra system bör vikten ligga på den hårda sidan.

Kanske kan det låta som att man pratar om två olika personer i form av den mjuka testaren och den hårda testaren. Visst, det kan vara så att det är två eller flera personer som tillsammans har kunskapen men det kan också vara så att den mjuka testaren och den hårda testaren befinner sig i samma fysiska kropp, som någon form av agil supertestare.
Det viktiga är att det finns både mjuk och hård testkompetens i teamet. Tyvärr är detta inte alltid fallet och det är inte ovanligt att man missar att inkludera antingen den hårda eller den mjuka testaren i teamets kontinuerliga arbete. Alternativt att man försöker lägga in det i någon som inte har rätt tänk och kompetens inom testning. Har ni både den mjuka testaren och den hårda testaren i ert team?

Markus Niklasson har en magisterexamen (M.Sc.) i datavetenskap från Högskolan i Skövde och har därefter arbetat för bland annat Volvo Cars, SAAB Microwave Systems, Ericsson och Siemens med testautomatisering och agil testning.
Markus Niklasson har spetskompetens inom agil testning och brinner för kontinuerliga förbättringar. 

Informator erbjuder flera spännande kurser inom Kravhantering och Testmetodik. Se alla våra kurser inom Krav och Test här

Läs mer