Genom att arbeta mer kontextdrivet och utforskande kan du hitta problem tidigare, frigöra resurser och få en effektivare resursfördelning och testning. Men för att inte missa något behöver du också anpassa processer och rutiner för ditt arbete.
Kontextdriven testning på fler nivåer
Att testa kontextdrivet utifrån produkten, teamet och individerna kanske i sig inte är så nytt, men vi måste även bryta ner detta på iterationsnivå inför varje iteration. Det innebär att du vid varje implementation måste välja rätt nivå för ditt kvalitetsarbete. Ett sätt att göra det är att utgå från riskklasser och kvalitetstekniker, som jag vid flera tillfällen har infört på mina uppdrag. Så här går det till:
Riskklasser och kvalitetstekniker
- Börja med att se över och lista vilken typ av kvalitetstekniker ni använder/vill använda, till exempel Granskningar, Unittester, Scriptade tester.
- För varje riskklass, låg, medel och hög, anger du sedan den eller de kvalitetstekniker som du anser behöver genomföras för att uppnå de krav som har definierats. Dessa klassar du som M=Mandatory. Med O=Optional mernas att du lämnar möjligheten öppen för att fatta ett senare beslut utifrån varje given situation.
- Viktigast av allt: ”kill your darlings” och skippa vissa saker. Dessa är angivna som n/a i exemplet nedan.
Riskbedömning av nya funktioner och förändringar
Om ni inför en ny funktion behöver ni göra en bedömning av vilken riskklass/prioritet den har i systemet. Låg, medel, hög? Klassning görs utifrån på två olika kriterier: Användarnytta respektive Funktionalitet viktas på en risk/prioriteringsskala 1-4:
Användarnytta:
- Funktionen används sällan och ger inget större mervärde.
- Den genomsnittlige användaren kommer kanske aldrig att se funktionen.
- De flesta användare kommer använda denna funktion, men kanske inte varje gång.
- De flesta användare kommer att använda denna funktion varje gång. Funktionen skapar mervärde.
Funktion och funktionalitet:
- En funktion som inte har uppdaterats, eller har liten påverkan på helhetsintrycket.
- Funktionaliteten är av mindre betydelse, eller innebär mindre ändringar.
- Funktionen är ny eller ändrad. Den har stor påverkan på det dagliga arbetet, men alternativt arbetssätt finns.
- Huvudfunktion i systemet som är ändrad eller ny. Vid avsaknad av funktion får det stor påverkan för slutanvändaren. Finns inget alternativt arbetssätt.
Varje funktion/förändring som införs behöver också mappas mot ett huvudområde i systemet, exempelvis en startsida, ett login eller konto som i bilden nedan.
Två tekniker för utforskande testning
Vad är utforskande testning? Som ordet säger så utforskar du området du tänkte testa och här finns självklart olika tekniker, men även olika ”inställningsnivåer” för varje teknik. För att begränsa oss går vi här in på två tekniker som utgår från samma ”inställningsnivåer”.
Med ”inställningsnivåer” menar vi vilken hatt du har på dig när du testar.
Tänk dig att du sitter i en bil: Är du ute på en provtur och sitter mest bakom ratten och provar de olika funktionerna du ser? Eller är målet att hitta alla dolda förvaringsutrymmen, kunna koppla in startkablar och fylla på spolarvätska? Eller har du som mål att kunna byta ut växellådan, kolvringar och bränsletankens nivågivare?
När du väl vet vilken ”hatt” du har på inför kommande test har jag två kraftfulla tekniker att rekommendera, SBTM respektive TBTM.
Detta är SBTM
SBTM innebär i korthet att man tidsbegränsar sina utforskande tester till korta sessioner. Varje session innehåller en kort period testdesign och en större andel av tiden läggs på testutförande. En session består av tre delar:
- Testdesign
- Testutförande
- Utvärdering genom PROOF (Past, Results, Obstacles, Outlook, Feelings)
SBTM är ett bra sätt att få struktur och spårbarhet, utan att förlora syftet med utforskande tester.
Detta är TBTM
Syftet med TBTM är att vidareutveckla sina testidéer med hjälp av effektiva anteckningsmetoder, testtrådar och minneskartor, snarare än med mer traditionella mallar eller stadgar. Enkelheten i TBTM består i att de enskilda testtrådarna saknar etablerade kriterium för när de anses ”klara”. I TBTM innebär ”klar” att du fullföljt din testidé. En ytterligare fördel är att du kan testa flera idéer samtidigt.
Ta dina första steg mot en förändring
Börja med att ta små steg. Se över riskklasser och lista kvalitetstekniker i samband med en sprintplanering. Utgå från de kvalitetstekniker ni redan har och bygg sedan på med mera kontextdrivna så som TBTM och SBTM.
Kategori:Teknik
Guide om xBTM
En vanlig kritik mot utforskande test är att det är för dålig spårbarhet och för lite dokumentation. Denna kritik bottnar i okunskap om vad utforskande test innebär, eftersom sättet att testa i sig inte på något sätt omöjliggör koppling mellan krav och test, eller förhindrar dokumentation. För att bemöta denna kritik, och för att sprida information om hur man kan tillämpa utforskande test, infördes xBTM. Ladda ner vår guide och få en introduktion och sammanfattning av metoden.
Vill du hitta möjliga vägar till att effektivisera och frigöra resurser för att bättre kunna uppfylla affärsmål och leveranskrav? Hör gärna av dig till mig eller någon av mina kollegor på QESTIT.
