Innan vi ens tar det första spadtaget till vad som ska bli en färgrikt blomstrande rabatt eller skriver den första kodraden till en självkörande bil, har vi format någon slags mental bild av vad vi försöker åstadkomma och vad slutmålet är. Till en början är bilden ofullständig och suddig men för varje spadtag och kodrad brukar bilden klarna allt mer. Detaljer tillkommer längs vägen, nya perspektiv läggs till och kanske har den ursprungliga bilden ändrats fullständigt efter att vi genomfört några iterationer och dragit nya lärdomar av dessa.
I vår egen trädgård utgör denna typ av förändringar sällan något större problem, men ifall vi är dussintals eller hundratals människor som tillsammans ska bygga ett sofistikerat mjukvarusystem blir det fort väldigt komplicerat och riskfyllt när våra gemensamma modeller behöver ändras. Risken är uppenbar att det uppstår missförstånd och motstridiga uppfattningar om hur slutmålet egentligen ser ut.
Men i en agil utvecklingsmodell behöver vi vara snabbfotade och kunna ändra saker längs vägen. Hur kan jag då vara säker på att du har samma modell som jag, ifall våra modeller bara finns inom oss? Är du med mig även ifall jag i modellen byter ut tulpanerna i rabatten mot ett citronträd?
Vad är modellbaserad testning?
Även om modeller kan existera i en abstrakt tankevärld så använder man i modellbaserad testning vanligen en modell i grafisk form (t.ex. ett flödesschema i BPMN-notation) som beskriver ett eller flera önskvärda beteenden hos målsystemet. Ur den valda modellen härleds ett antal testscenarier, t.ex. ett urval av alla tänkbara sätt att vandra genom ett flödesschema från start till slut. Scenarierna kan därefter användas antingen som manus vid t.ex. manuell funktionstestning, eller så kan de kompletteras med testdata och automation och då resultera i regressionstestfall som exekveras automatiskt i ett CI/CD-flöde.
En tydlig fördel med modellbaserad testning är att den utgår från en visuell modell som ofta är mer lättsmält än många andra typer av dokumentation (t.ex., skrivna kravdokument). Innehållet i modellen går därför lättare att resonera kring och även personer som inte är tekniskt insatta kan ta till sig informationen och via modellen få insikt i vilken testning som utförs. Det glapp som ofta finns mellan domänexperter och tekniska experter kan överbryggas. En domänexpert kan t.ex. påpeka att det finns specialfall som behöver tas hänsyn till och föreslå var/hur dessa påverkar modellen, vilket i sin tur direkt påverkar de testscenarier som härleds ur denna.
Många verktyg inom modellbaserad testning bibehåller en stark koppling mellan modellen och testscenarierna. Detta förhindrar att testerna blir utdaterade så snart modellen ändras, något som annars är en risk när kravdokumentation behöver uppdateras.
Vilka begränsningar och risker finns med modellbaserad testning?
Liksom med alla former av verktyg vi använder finns det en risk att kompetensen kring dessa inte når en ”kritisk massa” när det kommer till spridning inom organisationen. Om den enda personen som förstår hur verktyget funkar lämnar teamet brukar resultatet bli att verktyget faller i glömska och all kod etc. som finns för detta förfaller.
Genom att modellbaserad testning vanligen utgår från en beskrivning av önskade beteenden/funktioner så lämpar den sig mindre bra för att testa icke-funktionella krav (prestanda, användbarhet, säkerhet etc.). För icke-funktionella krav bör andra kompletterande testmetoder övervägas.
Kontakta oss för konsultation eller frågor rörande Test och QA
Har du frågor eller behöver hjälp med dina projekt inom test och QA? Tveka inte att höra av dig till oss. Fyll i formuläret så återkommer vi till dig inom kort. Vi finns här för att hjälpa dig att ta nästa steg i din digitala utveckling.
