Kontextdriven test och kravhantering

2014-12-15 Artikelbanken Test Läst 6287 gånger

Under en paus på en kurs i kravhantering kommer deltagaren Peter fram till mig. Han är projektledare och ställer följande fråga om sitt företags process för projektledning:

"När i vår process anser du att vi ska genomföra vår workshop för kravinsamling?"

Då uppstår en för mig välbekant moment 22-situation. Jag vill inte svara projektledaren Peter att "det beror på" men sanningen är att det faktiskt beror på.

Innan jag kom i kontakt med "kontextdriven" hade jag ställt några snabba kontrollfrågor och svarat i stil med "baserat på din situation, skulle jag utifrån min erfarenhet rekommendera att ni genomför kravinsamlingsworkshoppen direkt efter [eller innan] ...". Tur för Peter och för mig, så är jag utrustad med budskapen från "kontextdriven" och istället inleder jag mitt svar med följande motfråga:

"Varför väljer ni just en workshop för kravinsamling?"

Jag fortsätter med några fler kontrollfrågor innan jag kommer med ett svar.

Mina sätt att svara innan och efter jag kom i kontakt med den kontextdrivna skolan är ganska lika. Den avgörande lilla skillnaden ligger i vad jag tagit för givet eller inte tagit för givet, i detta fall att det ska ske en workshop överhuvudtaget.

Tekniken workshop är en av ett tiotal tekniker som kan användas för kravinsamling. Samtliga tekniker har sina för- och nackdelar som gör dem mer eller mindre lämpliga beroende på sammanhang. Att bestämma i förtid vilken eller vilka tekniker som ska användas är att förutsätta att varje projekt är en kopia av det föregående projektet. När var du med om det senast?

I denna artikel vänder jag (Chris) och min kollega Ola oss primärt till dig som upplever att konceptet kontextdriven testning är relativt nytt. Det finns gott om diskussionsforum för de redan invigda om du känner behov av att gå mer på djupet. Vi sammanfattar konceptet, eller ”skolan” som den heter, och lyfter vad som kan vara både bra och mindre bra med det. Som både rubriken på denna artikel antyder och anekdoten ovan illustrerar så kommer vi inte begränsa oss till testning utan dessutom introducera ”kontextdriven” som användbart även i kravhantering.

De sju underliggande principerna

Definitionen av kontextdriven testning ligger i skolans sju grundläggande principer. Principerna togs fram under 2000-talet av James Bach, Brian Marick, Bret Petticord och Cem Kaner. Dessa principer utgör kärnan och förklaringen till vad kontextdriven är, på samma effektfulla sätt som de kanske mer välkända värderingarna som är centrala inom agil utveckling (agilemanifesto.org). Vi översätter här till svenska och kommer därefter gå igenom varje princip för sig. Mer kringliggande information samt den engelska källan hittar du på context-driven-testing.com.

 

  1. Värdet av ett arbetssätt är beroende av sin kontext.
  2. Det finns inga bästa arbetssätt (best practices), utan bara bra arbetssätt i en kontext.
  3. I projektkontexten är människor och deras samarbete den viktigaste delen.
  4. Hur ett projekt utvecklas är ofta oförutsägbart.
  5. Produkten är en lösning. Produkten fungerar inte om inte problemet är löst.
  6. Bra testning är en process som är intellektuellt utmanande.
  7. Bara genom bra omdöme och färdighet, utövade tillsammans under hela projektet, kan vi göra rätt sak i rätt tid för att testa våra produkter på ett effektivt sätt.


Det beror på

Princip 1 - Värdet av ett arbetssätt är beroende av sin kontext

Ett syfte med test är att, med begränsad tid och begränsade resurser, skaffa oss information om hur produkten beter sig. Den informationen ger vi till de berörda parterna så de kan bedöma om det är tillräckligt bra. För att uppfylla detta syfte finns det olika tekniker som kan tillämpas som är olika bra beroende på kontext.

Som exempel börjar vi med försäkringsprodukter som omfattar en mängd olika parametrar. Här är det viktigt att alla möjliga kombinationer av parametrarna testas. Användning av checklistor, klassificeringsträd eller enkla matriser ger både den struktur och täckning som krävs för att vara säker på att jobbet är gjort.

Om samma försäkringsbolag skulle lansera en app som erbjuder några enklare funktioner, till exempel att bara visa standardförsäkringsvillkor, så har vi ett annat sammanhang. Med en app kan känslan vara viktigare än funktionen - hur snabb den är, hur attraktiv den är, hur intuitiv den är. Funktionen är viktig men "look and feel" är avgörande. Då är klassificeringsträd mindre lämplig, näst intill värdelös som teknik att identifiera om de viktigaste behoven är uppfyllda. I detta sammanhang skulle en mer öppen form av testning ge bättre resultat, till exempel utforskande test i kombination med användningstester.

Om vi applicerar "kontextdriven" i vår testplanering så fångar vi upp dessa skillnader och applicerar de olika arbetssätten i de olika sammanhangen. Om vi istället hade applicerat antingen skriptad testning eller utforskande testning rakt igenom så skulle vi misslyckats med vår uppgift att testa på ett effektivt sätt.

Fördelen med denna princip är att den utmanar oss att tänka på sammanhang och inte köra blint enligt teori eller utifrån det som har fungerat i andra sammanhang. En möjlig risk med principen är att vi för aggressivt nedvärderar planering och tillhörande dokument som testplan och teststrategi med motivering att vi inte kan förutse sammanhanget och därmed inte kan planera i förtid vad som ska testas och vilka arbetssätt som ska tillämpas.


Bästa arbetssätt - finns de?

Princip 2. Det finns inga bästa arbetssätt (best practices), utan bara bra arbetssätt i en kontext.

Denna princip är både onödigt och provocerande, även om det säkert fanns en bra poäng med den från början. Skolans grundare påstår att det inte finns några bästa arbetssätt (best practices). Inbyggt i principen är ett antagande att vi inte tar hänsyn till sammanhang i vår definition av bästa arbetssätt idag. Formuleringen av principen är provocerande men den fångar samtidigt intresse med sin provokation. Egentligen finns det ingen skillnad mellan denna princip och föregående princip. Värdet av ett arbetssätt är beroende av sitt sammanhang. Men för mig har det alltid varit en del av själva definitionen av bästa arbetssätt. Våra förslag avseende princip 2 är följande:

  1. Formulera om principen till ”Värdet av ett arbetssätt är beroende av sin kontext
  2. Kasta principen eftersom den är en kopia av första principen ovan.

Det handlar mer om människor än om IT

Princip 3. I projektkontexten är människor och deras samarbete den viktigaste delen.

Vi tror att det vi sysslar med handlar om IT och IT-system men det handlar också om människor. När man inser att testning och kravhantering handlar minst lika mycket om mänsklig kommunikation som det handlar om hantverk och teknik så har vi nyckeln till framgång. Bara för att vi är medvetna om hur beroende vi är av människor i vårt sammanhang betyder det inte att vi kan göra någonting åt det. Ibland kan vi åstadkomma en ändring genom utbildning, teambuilding, eller någon betydelsefull processförbättring. Vårt budskap i detta område är att bekanta dig med de människor och de organisationer som du har att göra med. Bekanta dig med deras styrkor och svagheter. Identifiera möjligheter och hinder. Du kommer sannolikt inte kunna ändra på så mycket, men med rätt insikt så kan du navigera så att ert arbete tillsammans blir så värdefull som möjligt.

Vi kan inte säga det bättre än följande, som går att hitta på context-driven-testing.com:

Ultimately, context-driven testing is about doing the best we can with what we get.

Produktutveckling är en upptäcktsresa

Princip 4. Hur ett projekt utvecklas är ofta oförutsägbart.

En av de viktigaste anledningarna att ta fram en projektplan, en testplan eller en kravplan är för att lättare kunna göra justeringar när projektet fortlöper på ett oväntat sätt. Inget projekt är helt förutsägbart, men vi har ofta någon erfarenhet från tidigare, liknande projekt som vi kan utgå ifrån. Utmaningen är att hitta balansen mellan planering och flexibilitet. Det som är viktigt ur ett kontextdrivet perspektiv är att kunna fånga upp och reagera på våra upptäckter medan produktutveckling fortlöper, oavsett hur oförutsägbart projektet är.

Problem och lösningar

Princip 5. Produkten är en lösning. Produkten fungerar inte om inte problemet är löst.

Kravhantering handlar om att fånga upp behoven, fatta beslut om vilka vi ska lösa, och sedan bygga lösningar med tillräckligt bra kvalité. I klassisk kravhantering kallas behoven för problem. Det mer vardagliga och positiva begreppet ”behov” är att föredra framför ”problem”. Oavsett vad vi kallar det för är det otroligt viktigt att fånga upp och beskriva problemet innan vi drar igång med en lösning. Vi använder ett kundexempel för att illustrera vad som händer när vi missar detta.

Vad kunden behövde
För att minimera tiden som krävdes för kundtjänst att felsöka problem kom kunden fram till att vissa transaktioner behövde registreras i en logg.

Hur kravet kommunicerades till leverantören
”Det skall finnas en loggfil där transaktioner av typ X loggas”

Resultat

När kunden tog emot leveransen av loggfunktionen kom första frågan ”Men, hur får handläggarna tillgång till loggfilen?” Enligt leverantören var kravet uppfyllt eftersom loggen fanns, precis som specificerat. Enligt kunden var kravet inte uppfyllt eftersom en uppenbar och avgörande del saknades.

I scenariot ovan har både kunden och leverantören gjort ett grovt misstag. Kunden förklarade inte behovet, och leverantören krävde inte en förklaring av behovet från kunden.

Använd din hjärna

Princip 6. Bra testning är en process som är intellektuellt utmanande.

Denna princip utgår från att testare har hjärnor, och att dessa hjärnor ska utövas för att maximera effekten av testning. Vi börjar med en klassisk, något förenklad men alltför typisk illustrering av hur testning går till idag:

Krav: “Systemet ska skriva ut A om jag skriver B”

Testfall: “Skriv B, kontrollera att systemet skriver A”

Detta kan man inte beskriva som en utmanande process, även om den ger en viss effekt.

Koppla in hjärnan och det finns mängder med möjliga tester vi skulle kunna utföra, där urvalet nedan är bara en början.

Testidéer:

  • Skriv B
  • Skriv A
  • Skriv “ B” (en text med mellanrum)
  • Skriv “ABA” (text med B i)
  • Skriv 1 (tal)
  • Skriv #@ (tecken som finns i din encoding, men som kanske inte förväntas)
  • Ange en sträng som är 123123 tecken lång
  • Skriv text på kinesiska

Att komma på möjliga testidéer är utmanande, men den riktiga utmaning är att välja vilka av alla möjliga tester vi ska faktiskt utföra. För att återkoppla till vårt syfte med test enligt formuleringen under princip 1 i denna artikel, så har vi gått från att “testa för att se att det fungerar som det ska” till att “testa för att på kortast tid få så mycket information som möjligt”.

Principen riskerar att misstolkas som att testning alltid måste vara intellektuellt utmanande för att det ska vara bra. Testning som en process och som en samling aktiviteter kommer att innehålla moment som är mindre utmanande, som är repetitiva, och som kan vara rätt tråkiga. Detta måste vi också acceptera. För att testning ska vara framgångsrikt och ge ett värde så kommer testare naturligtvis använda sina hjärnor under delar av arbetet. Ju mer utmanande moment desto bättre för testning och för testare, men bara upp till en viss punkt. Intellektuellt utmanande arbete kan med fördel balanseras med paus från utmaning samt mindre utmanande aktiviteter emellanåt, aktiviteter som dessutom krävs för att ge struktur och bra grund för uppföljning.

One principle to rule them all

Princip 7. Bara genom bra omdöme och färdighet, utövade tillsammans under hela projektet, kan vi göra rätt sak i rätt tid för att testa våra produkter på ett effektivt sätt.

Denna princip knyter ihop de föregående principerna. Den kombinerar ett antal faktorer som är kritiska för vår framgång, om vår ambitionsnivå är att verkligen maximera effekten av vårt arbete:

  • färdigheter - allt vi lärt oss via erfarenheter och annan utveckling
  • bedömningsförmåga - att kunna läsa av situationer och reagera med rätt angreppsätt
  • samverkan mellan projektmedlemmar - det handlar om människor och deras interaktioner

Även om den målar upp en något utopisk vision så fungerar den som en positiv vägledning med alla viktiga ingredienser. Om vi är medvetna om varje komponent som ingår i principen, så har vi tagit ett första steg mot att kunna utnyttja och påverka kontexten som vi jobbar inom. Det kanske är orealistisk att förvänta sig att vi kommer att kunna göra helt rätt sak i helt rätt tid under hela projektet, men genom att försöka så kommer vi garanterat uppnå bättre effektivitet än om vi inte försöker.

Summering

Vi har alla nytta av budskapen från kontextdriven testning, även utanför testsfären till exempel inom kravhantering. Du genomför sannolikt redan ditt arbete enligt principerna till en viss grad. Bara att få namnet ”kontextdriven” som etikett kan vara till hjälp om du vill vidareutveckla dig själv eller påverka ditt sammanhang för att uppnå mer effekt av ditt arbete. Kontextdriven testning har sju grundläggande principer, men om du bara kommer ihåg den första så fångar den essensen av hela skolan: ”Värdet av ett arbetssätt är beroende av sin kontext.”

Nästa steg

Samtliga våra kurser är metodoberoende. Vi presenterar både verktyg och arbetssätt som är hämtade från olika sammanhang, från både traditionella till mera agila. Vi går igenom för- och nackdelar med allt så att du kan känna dig utrustad att plocka fram rätt sak i rätt tid. Här följer ett urval av rekommenderade nästa steg beroende på din egen utveckling hittills:

På följande länkar kan du läsa mer om de grundläggande principerna bakom både kontextdriven och agil utveckling:

I följande artiklar från Faktabanken kan du läsa mer om områden som tas upp i artikeln:

KONTAKTA OSS

Har du frågor? Vill du ha hjälp med områden inom kravhantering och test?
Hör av dig till oss! Vi hjälper dig gärna. 

Kontakt 

Dela artikeln