Grundtanke. Skapa en modell av ett användargränssnitt som trycker på alla knappar. Vi har vårt användargränssnitt, vårt GUI. Det är ett komplicerat GUI, så hur vi modellerar det på ett bra sätt både visuellt och funktionsmässigt.
Visuellt kändes mer och mer som viktigt då modellbaserad testning, MBT, fortfarande är i uppbyggnads- eller förstudiefasen inom företaget. Även om jag förespråkade MBT var det ju inte säkert att alla helt köpt idén, övertalning och förklaring krävs då och för att få så många som möjligt att förstå möjligheterna och kraftfullheten krävs visualisering.
Sättet jag valde, har jag förstått, kanske inte är helt enligt standardpraxis.
Valet blev att låta varje nod representera ett objekt/knapp på GUI’t och inte ett state, och varje edge representera vilka möjliga andra objekt man kan ta sig till.
Varje nod fick då namnet på det objekt som ska tryckas eller få tillträde till. Namnet i sig erhålls ju enkelt via GraphWalker.
Värt att nämna är också att vid tillfället då vi startade inte hade tillgång till det slutliga användargränssnittet. Approachen blev därför på en hög eller grundläggande nivå. Modellerna vi utformar riktar sig mot att stöta på problemen tidigt, hitta lösningar, utvärdera tänkt funktionalitet, prova våra idéer på hur modellen ska byggas upp och testas. Detta för att sedan kunna appliceras på ett mer moget GUI.
Modellen börjar nu formades på ett enligt mig fördelaktigt visuellt sätt. Och dessutom kan den enkelt och visuellt logiskt byggas ut med underliggande sub-modeller efter behov. Det naturliga blev att börja med att modellera huvudfönstret av GUI’t samt väl valda sub-modeller representerade av dom olika tabbarna i GUI’t.
Modellen för toppnivån av GUI’t innehåller samtliga tabbar överst i GUI’t. Från varje individuell tab skall man i sin tur kunna navigera till samtliga övriga tabbar inkl den tab man redan står på. Ett nyckelord lades också till innan objektnamnet för att definiera vilken slags objekt det är frågan om.
Bilderna 1 och 2 nedan illustrerar GUI’t samt modellen för toppnivån. Bild 1 är medvetet suddig, men tabbarna överst i GUI’t borde gå att urskilja.
Bild 1. Användargränssnitt, GUI
Bild 2. Modell av toppnivån
So far so good.
Nu hade vi en grund. En grundmodell att bygga vidare på.
Nu var det dags att lägga till tillämpningar och funktionalitet. Inställningar av värden kan ha givna intervall, knappar kan bete sig på särskilda sätt osv.
Definitionerna av detta vill man ur ovan nämnda visualiseringsskäl ha i modellen. Och tänker man så kändes det naturligt att lägga den informationen under respektive objekt.
Men varför begränsa sig där? Nu har du ett objekt. En inställningsmöjlighet med ett givet intervall.
Hur testar vi den inställningsmöjligheten? Eller kanske snarare hur väljer vi värde för inställningen?
Ytterligare information om hur vi ska välja värden för objektet lades därför till i noden. Och egentligen behöver man inte begränsa sig. All användbar information kan läggas i noden, men för mig är visualiseringsbiten viktig och då vill jag även undvika en ”plottrig” modell. Relevant information som gör modellen och testningen av modellen mer förståelig läggs in i noderna, men fortfarande kan mycket av logiken runt testmetoder implementeras i test scriptet.
I bild 3 visas ett förslag på hur det kan se ut i vårt fall.
Vi har typ av objekt. I det här fallet något som kallas spin buttons, dvs ”pil up” och ”pil ner” som används för att ställa in ett värde.
Vi har objektnamn.
Vi har information om inom vilket giltigt intervall inställningen är möjlig för objektet.
Och slutligen har vi information om vilken slags metod som vi vill använda för att testa av objektet.
Även i den här sub-modellen ska det vara möjligt att från vilket objekt som helst vilja vilket annat objekt som helst samt sig själv. Man måste då också kunna välja att gå tillbaka till huvudfönstret, i det här fallet genom att gå via tab-objektet.
Bild 3. Sub-modell med testinformation i noderna
Den metod som visas här är en slumpmässig metod. Den går ut på att ett värde slumpmässigt väljs inom giltigt intervall. Andra exempel på metoder är att ha ett fixt värde eller negativ testning.
Beroende på hur man i GraphWalker väljer att gå igenom modellen så kommer du kunna återkomma fler än en gång till noden och på så sätt även automatiskt testa vad som händer om man genomför fler ”knapptryckningar” för värdes inställningar än vad det godkända intervallet tillåter.
Det här är första stegen mot en modell som testar samtliga knapptryckningar på ett GUI. Fördelarna som jag ser det är: Funktionaliteten för godkända testintervall och dessutom vilken testmetod man använder finns inbyggd i modellen. Det medför att det är lätt att ändra inriktning av testningen av olika objekt genom att ändra i modellen, samt kanske mitt huvudsyfte att det ska bli lätt att förklara en funktionalitet i allt mer komplex modell för någon som kanske inte är fullt insatt uppbyggnad av modeller och modellbaserad testning.
Vad verifierar du med denna typ av modell?
Just den här modellen är tänkt att vara en sorts Exploratory Test som trycker på alla (eller ett urval av) knappar. På så sätt är det mera en fråga om slumpmässighet, att systemet inte ska krasha och att kunna täcka fler möjliga knappkombinationer osv. I förlängningen ser jag dock en klar möjlighet att lägga till kravinformation, kravID el dyl, i noderna och på så sätt koppla verifiering till modellen.
Förutom stabilitet (låt den köra över helgen kan hitta en liten minnesläcka), så kan man ju kika på resursförbrukningen under tiden, och se att det ser “bra” ut.
Nån form av prestanda kan man också undersöka med hjälp av detta.
Som språkpolis tycker jag inte det är helt lyckligt att säga att denna slumpmässighet är en sorts Exploratory Test. Läsaren kan tro att utforskande testning handlar om att trycka på massa knappar. Egentligen handlar ju det om att tänka, hela tiden.
Är också förundrad över valet “verifierar” i Johans fråga (“testar” hade passat bättre på testzonen?)
Testning handlar väl om verifiering, validering, allt däremellan, och mycket utanför?
Och alla metoder och verktyg får användas hur man vill?
Det var inte min mening att trampa någon på foten med min fråga. Det var mer utav nyfikenhet som jag undrade vilken typ av verifiering som var grundtanken bakom denna typ av modellstruktur. Själv är jag oftast mer fokuserad på kravkoppling till modellerna som jag skapar, så att jag kan få en omedelbar återkoppling till vad som verifieras.
Om jag förstår svaret korrekt så finns det endast validering av applikationen inbakad i modellen ovan. Vilket mycket väl kan vara tillräckligt för att hitta en hel uppsjö av problem i applikationen.