Marit Wester

Nästan rätt kan vara good enough!

2017-01-26 Artikelbanken Redefining Quality Läst 496 gånger

”Nästan rätt är också fel” var Konsultbolag1s slogan under några år tidigare. Jag gillar orden. Det är en slagkraftig mening, underfundig, med en bra betydelse och den blir rolig, men präktig. Det sägs ibland att 1 + 1 = 3, vilket rent matematiskt förstås är fel men som i sammanhanget betyder att helheten är större än delarna var för sig. Delarna tillsammans tillför ytterligare en dimension till helheten.

Beroende av kontexten behöver alltså 1 + 1 = 3 inte nödvändigtvis vara fel.

I den här artikeln tar jag upp vikten av att kunna göra medvetna val och fatta välgrundade beslut och samtidigt påtalar jag behovet av att fastställa vilken nivå av kvalitet som är ”good enough” i just din kontext. Kontexten eller sammanhanget är en viktig orsak som bör ligga till grund för ett beslut.

Artikeln består mer av övergripande reflektioner och slutsatser om vikten av att uppnå en grundsyn på kvalitet i din organisation, snarare än detaljer kring metoder eller tillvägagångssätt. Målgruppen är alla personer med anledning att identifiera rätt nivå av kvalitet i en viss kontext. Det kan vara personer inom IT men just den här artikeln är troligen mer riktad till personer i ledande befattningar på verksamhetssidan eller affärssidan som nyttjar IT-stöd som verktyg i sin verksamhet för att uppnå vissa mål. Jag räknar med att artikeln väcker tankar hos alla som läser den.

Sedan hösten 2016 är Konsultbolag1s nya slogan Redefining Quality där vi vill förmedla att begreppet kvalitet har förändrats över tid. Vi har valt att dela in Redefining Quality i tre huvudsakliga delar; Kontext, Samspel och Ansvar. Den här artikeln tar upp Kontext. Kvalitet är precis som IT inget självändamål och saknar ett eget värde och båda bör istället ses som verktyg för att uppnå andra mål, affärsnyttor. Inte minst uppstår kvalitet i samband med användning och därmed är användarens upplevda kvalitet en viktig komponent.

Quality is in the eyes of the beholder.

Kontext

Vi som arbetar med test och kvalitetssäkring utgår ifrån syftet att med begränsad tid och resurser, skaffa oss information om hur en produkt beter sig. Med hjälp av denna information ska berörda parter sedan bedöma om det är tillräckligt bra. Vi behöver säkerställa att vi har rätt referensramar för det som ska utföras. Berörda parter behöver säkerställa att de får rätt och nödvändig information.

Kvalitet är godtyckligt. Tillräckligt bra, eller ”good enough” är en viktig och självklar del för oss som vi lägger i begreppet kontext. Beroende på omgivningen och den givna situationen skall kvalitet inte gå till överdrift och vi måste veta när det är nog, när något är tillräckligt bra och passar in i sin omgivning, det vill säga när den fyller sitt syfte, eller på engelska när den är ”fit for purpose”. Det är en ständig balans och kräver att vi har kunskap om vilken nivå som är tillräcklig, vad som ska uppnås och vad som kan lämnas, uteslutas. Då behöver nästan rätt inte heller vara fel, utan kanske är det absolut rätta i det läget. Vi har gått ifrån att 1 + 1 = 2 är det enda rätta till att 1 + 1 = 3 också kan vara rätt i vissa sammanhang.

Medvetna val

För mig handlar kvalitet i grund och botten om att kunna göra medvetna val. Vi bör testa för att bli medvetna om riskerna med att ta ett IT-system i drift. Är man omedveten om riskerna och om vilka konsekvenser ett visst skeende får är det omöjligt att ta ett välgrundat beslut.

Tänk dig själv att ta beslut om att driftsätta eller inte utifrån ett beslutsunderlag som säger att 95% av testerna är godkända. Det låter bra. Eller? Vilka är de 5% som uppenbarligen inte blivit godkända, och vilka tester har vi inte gjort överhuvudtaget? Hur ser kvaliteten ut i själva testunderlaget för de 95% som är godkända? Är testerna relevanta? Vad är otestat och därmed outforskad mark? Vilka konsekvenser kan ett eventuellt fel eller brister i denna del få?

Hur kan vi kräva ett välgrundat beslut på ett styrgruppsmöte utifrån detta? Hur kan en styrgrupp ens göra en bedömning?

Ibland kopplas kvalitet till risker, i många år har man till exempel pratat om riskbaserad testning. Det går inte att testa allt men vi behöver vara medvetna om vad vi testar men också om vad vi inte testar och varför. Kort sammanfattat kan man säga att vi testar eller kvalitetssäkrar de viktigaste områdena av en produkt eller tjänst. De områden som är förknippade med de allvarligaste riskerna eller hoten. Det som gör mest ont. Hur man kommer fram till vilka delar det är beror delvis på kontexten, omgivningen och IT-systemet i sig. Man behöver också titta på vem som påverkas av risken. Det kan till exempel innebära en ekonomisk konsekvens för företaget eller för slutkunden, vilket i sin tur även kan skada varumärket. Här behöver vi bryta ner produkten eller tjänsten och titta på konsekvenserna av om något inträffar i olika delar. Man behöver prioritera. Man behöver kunskap om något som faktiskt är större än bara IT-systemet och tekniken i sig. Man behöver kunskap om verksamheten, om processerna och om marknaden. I det här läget kommer verksamhetsstödet in, eller beställningsstöd som jag väljer att kalla det, för att hjälpa organisationer att kartlägga nuläget, identifiera risker och tydliggöra behov. Utifrån behoven och kraven i den givna situationen kan vi föreslå alternativ och titta på olika former av IT-stöd och tekniker. Det viktigaste är inte tekniken utan nyttan! Alla behöver ställa sig frågan ”Varför?” och lägga fokus på att hitta svaren.

Om man är medveten om att något får en viss konsekvens kanske man ändå är villig att ta risken att det inträffar om fördelarna överstiger konsekvenserna. Kanske gör man bedömningen att 95% godkända tester är utmärkt, eftersom de 5% som inte blivit godkända är av mindre allvarlig art, det kanske finns workarounds och det går att leva med dessa fel eller brister. Kanske gör man bedömningen att 95% godkända tester är ohållbart, eftersom de 5% som inte blivit godkända eller kanske inte ens har hunnit testats kan ge väldigt allvarliga konsekvenser som i sin tur exempelvis kan skada varumärket. Då är det definitivt värt att skjuta på en driftsättning och lägga ner ytterligare tid till felrättning, test och utvärdering. Koppla därför alla tester till en eller flera risker och låt styrgruppen ta beslut om att driftsätta eller inte baserat på vilka risker som möjligtvis kvarstår.

Mitt favoritexempel är från en artikel på IDG om att spelkonsolen Xbox 360 från Microsoft inte testades särskilt noggrant i syfte att komma först ut på marknaden. Artikeln är från 2008 men jag tycker fortfarande att den är klockren för att förklara hur man bör arbeta med kvalitet. Att inte testa särskilt noggrant var ett medvetet val av Microsoft där konsekvenserna av att komma efter Sony eller PlayStation 3 ut på marknaden var större än riskerna för att stora andelar av produkten Xbox 360 skulle behöva ersättas. Man gjorde ett medvetet val om vad som var ”good enough” utifrån kontexten.

En anonym källa som jobbat med Xbox 360-projektet i många år avslöjar i en intervju varför så många av Microsofts spelkonsoler inte håller måttet. För att hinna före Sony och PlayStation 3 struntade man i noggranna kvalitetstester och räknade med att en stor andel skulle gå sönder.

Källa: Extreme idg 


Ett annat exempel där konsekvenserna av ett beslut uppenbarligen inte varit kända är taget ur ledaren i tidningen IT Branschen (nr 7 november 2016) med rubriken ”Dyr miss för varumärket”. I artikeln beskrivs Samsungs nya toppmobil Samsung Galaxy Note 7 som bara någon månad efter försäljningsstarten i vissa länder hösten 2016 tvingades stoppa all försäljning efter ett antal rapporter om tekniska problem med telefonen. Bland annat hade telefonen exploderat och börjat brinna. Samsung utlovade en ny lösning och efter tre veckor levererades utbytesmobilerna men efter att dessa också drabbats av likande tekniska problem gav Samsung upp och lade ner produktlinjen helt. Strax efteråt har även amerikanska flygsäkerhetsmyndigheten och i stort sett alla större flygbolag i världen beslutat att varken besättningar eller passagerare får ta ombord Galaxy Note 7 på flygplan. De får inte ens transporteras avstängda i lastutrymmet.

En riktig katastrof för Samsungs varumärke! Jag tror inte att det var ett medvetet val och jag tror inte heller att beslutet att starta försäljningen var välgrundat. Jag är också väldigt nyfiken på hur de faktiskt testade telefonerna innan försäljningen startade? Att det som inte fick hända faktiskt hände och dessutom hände två gånger i följd borde överhuvudtaget inte kunna inträffa, särskilt inte om feltesterna hade varit välgjorda. Kanske fick tiden styra, kanske slarvade man därför med testerna den andra gången för att utbytesmobilerna skulle släppas snabbt?

Olika nivåer av kvalitet kan styras i en kvalitetspolicy

Enligt Wikipedia är en policy en avsiktsförklaring och riktlinjer för att styra beslut och uppnå önskade mål. Även om ordet policy låter väldigt formellt och tungt, väljer jag att i fortsättningen av denna artikel prata om kvalitetspolicy eftersom det förklarar vad jag menar.

Vilken kvalitetsnivå gäller för din organisation? Är den ens uttalad? Hur ska vi tänka gällande kvalitet i ett visst område? För ett visst system? Ofta är det här frågor som inte har några svar i en organisation utan som istället behöver beslutas vid en given specifik situation där tiden i värsta fall förhindrar att beslutet blir särskilt bra eller genomtänkt.

Jag tar ett exempel från vården som illustrerar principen att det finns olika kvalitetsnivåer. Ett intranät för vårdpersonalen behöver inte ha samma kvalitetskrav som ett journalsystem, trots att användarna kan vara desamma. Konsekvenserna av en risk blir större, det är allvarligare om ett fel inträffar i journalsystemet än i intranätet. Som testledare delar man dessutom in ett journalsystem i flera olika kategorier, där vissa områden viktas högre avseende kvalitetsnivå och exempelvis bör testas mer än andra. Någonstans bör ledningen ha fastställt övergripande riktlinjer för vilken kvalitet som gäller för de olika delarna, vilket testledaren är behjälpt av och kan bryta ner i sin teststrategi. Dessa riktlinjer kan finnas i en kvalitetspolicy.

Hur vi testar och hur vi delar in ett objekt är förstås inte så enkelt att det tydliggörs i en kvalitetspolicy. Det beror förstås på många flera saker. Release Notes är ett annat exempel på vad som också ligger till grund för testerna, men då kommer vi in på test och testledarens roll, vilket inte är syftet med den här artikeln.

Oftast har inte verksamheten någon befintlig policy för kvalitet utan det blir väldigt godtyckligt och impulsivt uttryckt i stunden. Vi som leder testerna saknar ett viktigt styrmedel.

Slutsats

Några lärdomar:

  1.   IT är inget självändamål utan bör ses som ett verktyg för att uppnå andra verksamhetsmål.
  2.   Alla behöver ställa sig frågan ”Varför?” och lägga fokus på att hitta svaren.
  3.   Koppla utvärderingen och alla tester till en eller flera risker och låt styrgruppen ta beslut baserat på vilka risker som möjligtvis kvarstår.
  4.   Tänk större än bara IT och teknik!
  5.   Vilken kvalitetsnivå gäller för din organisation? Är den ens uttalad? Ställ krav på att det åtminstone finns riktlinjer för kvalitet där du befinner dig om inte företaget kan skapa en övergripande kvalitetspolicy som gäller alla.
  6.   Nästan rätt behöver inte nödvändigtvis vara fel utan ”good enough”!

Dela artikeln