Krav är som miljön och IREB är som miljöskyddslagen

Visst kan man till viss mån värna om miljön utan att det ska behöva finnas lagar, förordningar och regler. Alla människor tycker ju om ren luft och rent vatten och vill hellre se grönska än grå betong utanför sina fönster. Inte heller finns det några miljöpsykopater, som blir glada när det förorenar och skräpas ned med flit. Utan dessa besvärliga och ganska tråkiga lagar (försök exempelvis lusläsa ”Svensk författningssamling 1969:387”!) blir det dock lätt helt fel och miljön förstörs utan att någon egentligen vill det.

Samma sak gäller krav, både affärskrav och systemkrav. Man kan till viss mån lyckas att fatta bra affärsbeslut och bygga bra IT-system utan att det måste finnas utpräglade projektaktiviteter som heter kravinsamling, kravanalys och kravvalidering. Alla tycker bättre om smidiga arbetsflöden och lyckade satsningar, och vill hellre se fina IT-tjänster än https://javlaskitsystem.se/. Det finns inte heller så många projektpsykopater som trivs bra förrän det råder riktigt kaos och system sjösätts under dramatiska former i sista minuten. Utan dessa besvärliga och ganska tråkiga normer (försök till exempel lusläsa ISO/IEC/IEEE 29148:2011 ”Requirements Engineering Standard”!) blir det lätt helt fel i projekt trots att alla gör sitt bästa för att det ska bli bra.

Vi människor är duktiga på att dölja sanningen bakom fasader – alla kulturer baseras på denna kunskap. Samma sak händer ofta med kravhantering. Ju mer man tror sig veta att man minsann inte behöver någon specialaktivitet för att ta hand om sådana självklarheter som projektmål, systemfunktionalitet eller produktbacklogg desto mer säker blir jag på att mycket kravarbete faktiskt pågår, fast under ett annat namn.. En gång fick jag höra att kraven var ”arkaiska” när man kör med kontinuerlig integration och leverans, och motsatsen är ett faktum: för att uppnå hög leveranstakt och en värdedriven releaseplanering krävs mycket smidigt kravfotarbete.

Kravarbete går under många olika öknamn som ”förfining av produktbackloggen”, ”specification by example” eller BDD i den agila världen. Det försvinner i projektledningens avgrund inne i PMBOK, eller ges kraftig mindervärdeskomplex i BABOK som en lillebror av det stora och prestigefyllda verksamhetsanalysen; sist men icke desto minst, uteblivna eller bortglömda krav tar man hand om som sista åtgärd av testare, speciellt inom ramar för utforskande testning.

Det är inget självändamål att lyfta fram kravarbete och systemkrav till en mera prominent plats, det är inte fråga om prestige utan det handlar främst om effektivitet och lönsamhet. Det helt enkelt lönar sig att ta hand om krav på ett ordentligt sätt och att använda de rätta begreppen som främjar raka budskap.

För drygt tjugo år sedan insåg man samma princip vad gällde testning. ISEB, och sedan ISTQB testcertifieringar startades. De har blivit så populära att idag har fler än en halv miljon människor skaffat sig sådana. Man har lärt sig att visst går det bra ibland att uppnå bra kvalitet med testning inbyggt i andra aktiviteter, men det går mycket bättre när testningen betraktas som delvis separat, självständig disciplin och kunskap. Det är dags att uppnå samma mognadsnivå vad gäller krav och kravarbete.

IREB certifieringsschema kan hjälpa oss ordentligt på vägen dit. Personligen, har jag ingen överdriven entusiasm för certifieringar som sådana, men vissa självklara fördelar har de: de skapar ordning och reda, alstrar referensramar, gör ordning på terminologin, och framför allt, skapar en solid, heltäckande bas för alla. Först när du behärskat den, blir det fritt fram att kritiskt granska och komma med bättre idéer.

IREB schema är dessutom riktigt bra skapat av både industrispecialister och akademiker, erfarna människor som vet vilka kunskaper deras och andras projekt behöver.

I mitt nästa blogginlägg tänker jag beskriva IREB huvudpelare i detalj: idag får en ritning räcka till 😊. Hej då!

Bogdan Bereza

Programmerare, testare, psykolog, kvalitolog, verksamhetsanalytiker, traditionsälskare, agil-entusiast och utforskare. Pragmatisk, drömmare och visionär, allt i en och samma person. Han blandar gärna testning med kravarbete, mixar agila och utforskande metoder med försiktig förebyggande planering och kopplar ihop praktiskt projektarbete med bokskrivandet och undervisning. Hans elever tycker om honom för hans förmåga att göra svåra ämnen lättbegripliga. 

Bogdan undervisar i kurser inom Kravhantering som IREBCPRE Foundation, IREBcertifierad agil kravspecialist, IREBCertifierad Kravspecialist - Avancerad - Kravmodellering, IREBcertifierad kravspecialist - avancerad - kravanskaffning och konsolidering, IREBCertifierad Kravspecialist - Avancerad - Hantering av Krav, IREB CPRE Advanced Requirements Management och REQB- IREB

Läs mer

Bör ”IT-avdelningar” ens finnas?

”Allt är IT” är en fras som dyker upp allt oftare. Om detta nu är sant, är uppdelningen mellan den så kallade kärnverksamheten och IT-avdelningen då verkligen relevant? Och om den är det, hur kan vi förbättra kommunikationen? År 2016 borde det finnas effektivare metoder än röksignaler och stelbenta ärendehanteringssystem.

I ett av mina första uppdrag som testare - för vad som nu är ganska många år sedan - fanns det ett 

enda sätt att kommunicera med de utvecklare som skrev koden för produkten vi testade: ett felrapporteringssystem. Det säger sig självt att kommunikationen blir ganska bristfällig om det är den enda kommunikationsvägen och ledtiderna var extrema, det tog dagar och ibland veckor att få svar på en fråga eller att få tillbaka den för testare så bekanta frasen ”cannot reproduce”.

Som tur är förändras saker och ting, och kommunikationen är kanske en av de saker som förändrats mest. Jag minns att vi var överlyckliga när vi fick möjlighet att maila direkt till utvecklarna och diskutera den vägen, och senare dök också ett chatprogram upp som ytterligare minskade gapet och tröskeln att ta kontakt. Var de satt hade vi fortfarande ingen aning om, men telefonen tog oss förstås ännu ett steg närmare.

Förändringarna har fortsatt och idag arbetar väldigt många i agila utvecklingsteam där man ofta sitter tillsammans och har ett väldigt tätt samarbete mellan de olika rollerna i gruppen. Vissa har tagit det ännu längre och börjat lösa upp rollerna som sådana – vi är alla utvecklare där vissa kanske har mer fokus på till exempel test, eller så skriver vi kod en dag och testar nästa. Oavsett upplägg så finns det förstås stora fördelar med att arbeta så tätt, inte minst så ökar kunskapen och förståelsen för alla i gruppen avsevärt.

När vi nu brutit ner många av de barriärer som i många fall funnits inom mjukvaruutveckling, så har testarna bättre insikt i koden vilket kan göra det lättare att förstå hur och vad som behöver testas. Utvecklarna i sin tur har en bättre förståelse för testarnas behov, och inte minst så har alla förhoppningsvis god tillgång till kraven och en kravansvarig som kan berätta vad det är kunden behöver.

Här finns det dock enligt min erfarenhet en extremt tydlig gräns: kunden, det vill säga kärnverksamheten, och IT-avdelningen, där nyutveckling och modifiering sker av det IT-stöd som verksamheten behöver.

Är detta verkligen en relevant uppdelning? IT är ju idag en så stor och viktig del av många arbetsprocesser som finns inom ett större företag – ”allt är IT” är en fras som hörs ibland. Om vi nu har sådan närhet i utvecklingsprocessen, varför måste just kraven och verksamhetsförståelsen gå via den ibland trånga tratt som kravanalytikern kan vara?

Den närhet, direkta kommunikation och förståelse för varandra som kommer av att vara ett gemensamt team och gärna arbeta nära varandra rent fysiskt, det är något som skulle kunna gynna både IT och verksamhet.

Testare med god insikt i verksamheten (eller som faktiskt är en del i verksamheten) har en större förståelse för vad som är viktigt att testa, hur tester kan ske och hur de bör prioriteras. De kan förstås också på ett bättre sätt bedöma lämpligheten i en IT-lösning och dessutom göra bedömningar av användbarheten hos systemet.

För en utvecklare är fördelarna likartade, för oavsett hur bra och väl specificerade kraven och designen är, så måste det fattas en mängd beslut under utvecklingsprocessen. Med en god insikt om användarna och användandet blir det lättare att fatta beslut som i slutändan leder till en bättre produkt.

Även verksamheten skulle ha mycket att vinna, till exempel är min erfarenhet att de som ställer krav och kommer med önskemål kan ha svårt att tänka utanför boxen och verkligen tänka nytt. En del i detta är att man inte har någon uppfattning om vilka möjligheter som finns, eller hur svårt respektive lätt det är att genomför vissa idéer. Kanske vågar man inte ställa vissa krav eller så behöver man helt enkelt inspiration utifrån för att tänka om.

Jag säger inte att man behöver eller över huvud taget ska ta över varandras arbetsuppgifter, men bara något så enkelt som att sitta i samma kontorslandskap skulle göra otroligt stor skillnad. Förutom den informella kommunikationen i att ha personer lätt till hands för att ställa frågor, stämma av saker med, snabbt visa eller demonstrera något, så är det mycket information som flyger genom luften som går att snappa upp. Det är denna informationsmängd sammantaget som bygger upp kunskapen, medvetet eller omedvetet.

Som en bonus kan man tänka sig att de som arbetar främst med IT-utveckling kan känna en större tillhörighet till bolaget i stort, när man är närmare bolagets kärnverksamhet, det bolaget ”egentligen gör”.

IT kommer framöver troligtvis bli en allt större del av de flestas arbeten, och med det en förhoppning hos mig att den traditionella IT-avdelningen är dödsdömd. Jag vill uppmana alla som jobbar inom IT att sträva efter en tätare kommunikation med verksamheten, inte bara för att komma närmare detta mål utan för att jag tror det hjälper oss i våra arbeten. Låt oss bara hoppas att vi slipper kommunicera via runstenar eller röksignaler – eller för den delen ett stelbent ärendehanteringsprogram.

/Gabriel Johansson

Kravanalytiker, test manager och lärare

Gabriel Johansson är utbildad interaktionsdesigner på Malmö Högskola och har idag mer än tio års erfarenhet inom test och kravhantering i agila projekt, testautomatisering och usability testing. Erfarenheten sträcker sig över en rad branscher som telekom, logistik, industri, bank och finans samt detaljhandel. 

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

Läs mer

Är kravhantering elefanten i rummet? Här är stegen för att komma igång.

Krav. Smaka på det ordet. Enligt Svenska Akademins Ordbok är krav:

• Handlingen att kräva/fordra något av någon
• Muntligt eller skriftligt framställd begäran att få en penningfordran betald

Krav kopplas inte sällan ihop med tunga och tråkiga dokument, gärna i kontraktsammanhang, som vid uppfyllnad levererar en belöning i form av en pengapåse. Krav ses därför ofta något nödvändigt ont för att få tag i den där hägrande pengapåsen.

Enligt mig handlar krav om innovation och kreativitet, att få ned en vision på papper så att alla inblandade kan delta i diskussionen kring visionen. Krav handlar om att skapa och realisera nya system som kan hjälpa, förbättra eller till och med revolutionera teknik så som vi ser den idag. Men dålig kravhantering kan lika lätt stjälpa och i stället orsaka skada, ekonomisk förlust, stagnation samt akut huvudvärk. Inte mindre än 56%* av alla projekt som aldrig når i mål fallerar till följd av otillräcklig kravhantering.

Krav känns helt enkelt inte särskilt sexigt. Området är stort, oöverskådligt, förknippat med många frågetecken och grå byråkrati. Krav är svårt, men behöver inte vara elefanten i rummet som ingen vill prata om. Så hur äter man då en elefant? En bit i taget! Här presenteras tre munsbitar att börja med:

• Granska kraven
• Rita ett kontextdiagram
• Skapa mock-up:s

Att granska kraven för att öka deras kvalitet borde inte vara någon revolutionerande tanke, men är ett moment som av olika anledningar till exempel ekonomiska, tidsmässiga eller ren okunskap, hoppas över. Involvera kund, test, utveckling och slutanvändare tidigt för att säkerställa att alla är med på banan. Och att kraven är på banan.

I ett kontextdiagram identifieras i vilken miljö systemet kommer leva, samt systemets omfattning. Det blir snabbt tydligt hur lätt det är att missa vilka integrationspunkter eller användare ett system har eller vad som faktiskt ska utvecklas och ingå i projektet.

En bild säger mer än tusen ord och detta ska inte underskattas när det kommer till krav. Ett GUI blir genast betydligt mer överskådligt och greppbart om kraven kompletteras med enkla bilder som illustrerar disposition och flöden. Men mock-up:s behöver inte stanna vid endast GUI:n. Att ha något konkret att diskutera krav kring underlättar för kund som leverantör att med större exakthet identifiera fallgropar och missförstånd.

Om ovan smakade bra finns det många fler munsbitar att hämta i form av kurser inom kravhantering. Och jag kan lova – det är mycket mer spännande än det vid första anblicken verkar.

* Källa: J. Martin

// Karolina Mileros
Test Manager med specialistkompetens kravhantering

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

Läs mer

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

Varför certifiera sig inom krav och test?

Varje dag lägger vi våra öden i händerna på mer eller mindre okända människor. Vi åker t.ex. buss, tunnelbana och tåg medan vissa tar flyget till mer avlägsna platser. Vi litar på att de personer som framför dessa fordon kan sitt arbete och besitter nödvändig kunskap och utbildning som krävs. I väldigt få fall inträffar något oönskat då dessa personer vet hur man skall tänka och agera i specifika situationer för att eliminera riskerna för icke önskvärda effekter. Det finns också mer privata situationer i våra liv då det krävs någon form av certifikat, t.ex. om man önskar följa med på en dykutflykt eller för att kunna visa att man kan hantera en kitesurfutrustning.

I vår profession ställs inte alltid samma krav på att vara certifierad även om det blir mer och mer vanligt. Det som dock efterfrågas är mjukvara och system med hög kvalitet. För att kunna leverera med hög kvalitet ställs det krav på att alla artefakter som produceras håller hög kvalitet och ingen kedja är starkare än dess svagaste länk. Även om alla delar av utvecklingsprocessen är viktiga spelar ändå kravhantering och testning speciella roller. Är kravbilden inte heltäckande eller om kraven inte håller tillräckligt hög kvalitet kommer detta att påverka hela utvecklingen. Detta oavsett om man arbetar enligt en rigid eller lättrörlig  utvecklingsprocess. Test i sin tur behöver vara med från början för att säkra kvaliteten genom hela utvecklingsprocessen för det går inte att testa in kvalitet i slutet av ett projekt.

Eftersom krav och test har sådana viktiga roller i ett projekt ställs indirekt också höga krav på de personer som arbetar med dessa bitar. Det krävs utbildning, kunskap och erfarenhet för att kunna ta sig an dessa arbetsuppgifter. Men hur kan man säkra att personerna som skall ingå i projektet besitter rätt kompetens? Ett första steg är att se till att de personer som skall arbeta med dessa bitar är utbildade och innehar de certifikat som speglar den kunskap de besitter. Men som nämnts tidigare säger inte certifikatet allt utan man måste praktisera sina färdigheter också för att det skall vara relevant. Man kan jämföra det med att även om man har ett flygcertifikat måste man ha ett visst antal flygtimmar varje år.

Det man också bör beakta är att det finns olika roller inom både krav och test som kräver olika mycket kunskap och erfarenhet. Därför gäller det att titta efter rätt nivå på certifikaten så kraven inte blir för höga. Inom krav (REQB) och test (ISTQB) finns olika certifieringsnivåer som man skulle kunna jämföra med, just det, olika typer av flygcertifikat.

• Foundation – Det grundläggande certifikatet för att visa på att man besitter de basala kunskaper som krävs, dvs. grundläggande flygcertifikat för sportflyg.
• Advanced – Visar på att man har mer djupgående kunskaper inom mer än ett eller flera specifika områden som t.ex. testledning, dvs. certifikat för passagerar- eller fraktflyg.
• Expert – Besitter mycket djupgående kunskaper inom området och har dokumenterad erfarenhet av t.ex. processförbättring, dvs. man är redo att genomföra konst- och uppvisningsflyg.

Väljer du flyga med någon som har 10 000 flygtimmar men inget certifikat eller någon med betydligt färre timmar men som innehar certifikat för instrumentflygning? Valet är upp till dig! När tog du ett certifikat senast?

/Magnus C Ohlson
Quality Assurance Specialist 
Test Line Manager

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

Läs mer

Vi ska bli bäst på Krav & Test!

Att göra en noggrann kravinsamling kan låta självklart. Men i förvånansvärt många projekt brister det för att man är för angelägen att sätta igång arbetet. Informators kurs inom kravhantering erbjuder en gedigen verktygslåda för alla som arbetar med krav för IT-system. För dig som testar systemet erbjuder vi även kurser inom testmetodik som ger dig metoder, verktyg och modeller för att utföra testarbetet. Samtliga utbildningar är lämpliga för såväl beställare som leverantörer.
Våra samarbetspartners i området är:
QA
Edument

Läs mer