Context driven test

Morgondagens testmetodik

Karlstad kontor kontorslandskap
Vi som människor har allt tyckt om enkla lösningar – men när det kommer till mjukvarutest är det inte en fälla man bör falla i. När vi utvecklar mjukvara måste vi ta hänsyn till att inget projekt är det andra likt. I detta blogginlägg går Magnus, ansvarig för vårt affärsområde Test & Quality Management, igenom metodiken Context Driven Test som berör just detta faktum och hur vi bör förhålla oss till det.

Föreställ dig en värld där alla nycklar inte passar i alla lås, eller där alla lådor inte är fyrkantiga. Det borde inte vara så svårt, för det är ju den värld vi redan lever i. Vår omvärld, eller vår kontext om man så vill kalla den det, är inte en svartvit värld – inte binär, utan ytterst analog och färgrik.

När vi utvecklar mjukvara måste vi förhålla oss till detta analoga faktum, i en annars ytterst binär mjukvaruvärld. Inga projekt är varandra lika, för om de hade varit det så hade de inte drivits i projektform. Hela essensen i projekt är att de inte är likadana som något vi gjort tidigare. Det innebär att det alltid kommer finnas fler vägar som når till samma mål.

Vi som människor har alltid tyckt om enkla lösningar, men vi får inte falla i den fällan när det gäller mjukvarutest. Det finns de som utger sig för att kunna servera en enda enkel lösning för mjukvarutest i form av certifieringar, exempelvis ISTQB, och standarder, som ISO29119, för hur testarbete ska genomföras. ISTQB och ISO29119 försöker standardisera något som inte är svart eller vitt. Det finns inte en nyckel som låser upp alla lås – man måste ha en hel nyckelknippa med olika nycklar och dyrkar för att få upp alla lås.

Context Driven Test är en metodik, eller snarare ett synsätt gällande test, som tar ett steg tillbaka och sammanfattar projekt- och testarbete i sju punkter. Ursprunget för dessa punkter kommer från Cem Kaner och James Basch. Jag har översatt och dessa 7 grundprinciper i Context Driven Test:

1. Ett arbetssätts värde beror på i vilket sammanhang det används.

På samma sätt som en vass skalpell är ett utmärkt instrument för en kirurg, så är det ett dåligt instrument för den som vill äta en god middag. Båda använder sig av en kniv, men man förväntar sig olika saker av kniven

2. Det finns ofta goda exempel från tidigare erfarenheter, men det finns inte något som är ”best practices”.

Man ska alltid lära sig av historien, men att gå så långt att säga att det finns ett sätt som är det bästa sättet är att inte förstå historien.

3. Människorna som arbetar tillsammans är den absolut viktigaste faktorn som påverkar produkten.

I alla projekt som jag jobbat i under årens gång – och det har hunnit bli ett gäng vid det här laget – så finns det inget som har påverkat projektet så mycket som alla de människor som är involverade i det på ett eller annat sätt. Oavsett om det är projektledare, beställare, kravare, testare eller kund. Vi är alla med i projektet på något sätt.

4. Projekt utvecklas över tid, ibland på sätt som man inte kan förutse eller önskar.

Om det är något vi kan vara säkra på i början av ett projekt så är det att det inte kommer bli som vi tänkt oss. Det är inte nödvändigtvis av ondo, men vi behöver vara öppna och förstående inför att vår värld är föränderlig.

5. Produkten är lösningen. Om produkten inte löser problemet så fungerar inte produkten.

Det spelar ingen roll hur snygg kod man skrivit, hur häftigt GUI man designat eller hur många funktioner en mjukvara har om den inte löser grundproblemet.

6. Bra mjukvarutest är en intellektuellt utmanande process.

Alldeles för ofta märker jag att man tror att man kan ta vem som helst för att göra tester. Oerfarna testare hittar få fel, och ”fel” fel. Mjukvarutestare är proffs och de bygger upp en kunskapsbank över tid som inte är lätt att ersätta.

7. Bara genom att testa produkten genom hela projektets livscykel, kan vi göra rätt sak vid rätt tillfälle, för att säkerställa att vi testar produkten på ett bra sätt.

Mjukvara måste testas genom hela utvecklingsprocessen – om man bara testar i slutet så blir det både dyrt och dåligt. En kombination som ingen gillar.

När jag en gång i tiden började jobba med test, så verkade allt så enkelt. Sen, när jag lärde mig mer, så var test och krav stort, avancerat och svårförstått. Nu när jag tror mig faktiskt förstå vad test och krav handlar om, så är det inte så komplicerat. Låt er inte luras till av standarder och certifieringar som inte bidrar med något faktiskt kvalitetshöjande, tänk själva för vi är alla intelligenta människor. Fundera över vad som just här och nu, i den här kontexten är en bra testmetod.

Vill ni borra er djupare ner i detta spännande ämne? Hör gärna av er till oss!

Considlogga på glasdörrar på Consids kontor i Stockholm

Vill du veta mer? 

Lämna dina uppgifter så hör vi av oss.

Integritetspolicy

Ta del av fler blogginlägg