Sagan om projektledarkråkan som skulle ut och åka

Detta är sagan om projektledarkråkan som skulle ut på en resa med sitt projekt men inte hade någon som styrde över kvalitetsaktiviteterna. 

Projektledaren kan vi kalla Håkan för enkelhetens skull. Håkan hade varit med i gamet ett tag och kände att han hade koll på hur projekt skulle bedrivas. Dessutom var han omgiven av väldigt kompetenta utvecklare, enligt sin egen mening. Detta innebar att Håkan inte hade mycket till övers för olika aktiviteter för att säkra kvaliteten. Det brukade ändå lösa sig på slutet då man körde igenom några testfall för att se att saker och ting snurrade. Håkan hade nyligen läst om Scrum och fann det tilltalande att arbeta på detta sätt eftersom man då snabbt kunde komma igång och producera kod istället för att ha långa diskussioner med kunden. Det kunde man lösa på vägen helt enkelt förstod han, efter att ha läst om lyckade projekt på nätet.

Projektet drog igång och man hade arbetat med kunden Kurt tidigare. Därför ansåg man att man hade en bra uppfattning om vad Kurt ville ha. Dessutom kunde Kurt vara ganska obeslutsam så man var inte så intresserad av att sitta i en massa möten med honom och diskutera krav. Man skulle köra Scrum och då skulle det lösa sig på vägen. Några av utvecklarna hade också läst en del om agil utveckling och fastnade för att sätta upp en automatiserad byggmiljö och man producerade även ett antal automatiserade testfall som skulle köras när man gjorde ett nytt bygge. Tyvärr hade man lite svårt att få dessa testfall stabila och de uppdaterades inte efterhand som koden förändrades. Efter ett tag blev det att man helt enkelt inte exekverade dem.

Samma sak hände med morgonmötena. Det kom egentligen inte upp något speciellt och alla hade koll på vad de skulle göra så man tyckte helt enkelt att det var bättre att lägga denna tid på att producera kod. Tanken var även att Kurt skulle vara med på demonstrationerna men eftersom han hade fått mer ansvar var han tvungen att resa ganska ofta vilket förhindrade honom att delta på dessa. Håkan löste detta genom att även ta på sig rollen som produktägare eftersom han ju visste vad Kurt egentligen ville ha.

Det rullade på och dagen för leverans närmade sig och man började köra lite manuella tester i sin utvecklingsmiljö. Håkan tyckte det såg bra ut även om det fanns några små konstigheter om man gjorde saker som man inte borde göra med systemet. Med andra ord skulle det lösa sig. Systemet levererades till Kurt som tillsammans med några kollegor började acceptanstesta systemet i sin produktionsmiljö. Det Kurt såg gjorde honom inte glad. Vissa funktioner fanns inte med, det fanns saker som han inte förstod varför de fanns med, prestanda och tillförlitlighet var under all kritik samt att en av de viktigaste punkterna, användbarheten, var helt förbisedd. Projektet hade kört rakt ner i kvalitetsdiket!

Håkan skyllde på Kurt att han inte hade varit tydlig eller närvarande i projektet medan Kurt skyllde på Håkan för att han inte hade lyssnat och kört projektet på sitt eget sätt. Det ingen av dem såg var att det inte fanns någon som styrde test- och kvalitetsarbetet när projektledarkråkan skulle ute och åka...

Sensmoralen från denna saga är att det inte bara går att läsa något på nätet och sedan tro att man kan implementera det rakt av och få det att snurra. Det vi ser idag är att både mer traditionella projekt och agila projekt kör i diket på grund av att många projektledare och beslutsfattare inte har förståelse för varför test och andra kvalitetssäkringsaktiviteter behövs och hur dessa skall genomföras på bästa sätt, beroende på vilken utvecklingsmodell man har valt.  Det krävs utbildning, kunskap och erfarenhet om man vill undvika detta!

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

Dr. Magnus C. Ohlsson,
Quality Assurance Specialist

Läs mer

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