Perfect Storm in the Clouds

Typewriter-2

I helgen frågade min storasyster om det där Molnet! Storasystern är specialiserad på organiska och miljövänliga husisoleringstekniker och jag tyckte jag fick till en rimligt bra förklaring av grundläggande ”Vad, Hur och Varför” i ämnet.

Sedan kom hennes slutfråga: ”..men det låter ju inte så säkert! (tillgänglighetsmässigt)”

”Jora! Det är ju hela idén, eller bland annat i alla fall, till låg kostnad dessutom!” svarade jag och slängde ur mig en harrang om redundancy, virtualisering, mirroring och web services etc.

Lite pinsamt dagen efter så läser jag om hur “Amazon explains its cloud disaster” och deras “post-mortem assessment of the mess”

Förutom att skänka en snabb tanke till stackars drabbade företag så infann sig ju snart frågan:

Kunde det rimligen ha testats bort?

Om man orkar läsa hela Amazons förklaring så ser man att den perfekta stormen av följdeffekter startade med ett ”litet” misstag, en felrouting i samband med en uppgradering genomfört av AWS teamet på Amazon. Det var alltså inte någon kund som installerat nån skum programvara eller någon annan ”externt initierad dumhet”. Då funderar man ju kanske: Hur mycket, eller snarare kanske lite, testar vi ”baksidan” på våra system? Vi är säkert redan duktiga på att trycka in felaktiga värden på end-user sidan, klurar ut massa fiffig negativ testning, ”sabotagetestning” och kanske skjuter vi även in SQL-satser i inmatningsfält etc,

Men hur ser det ut med admingränssnitten?

”Där behöver vi inte testa, de som sitter där vet ju vad de gör!” tänker man kanske. Och så är det säkert till stora delar. Samtidigt är den potentiella effekten av en felaktig handling väldigt signifikant!

Hmm, jag har inga direkta svar i ämnet men tanken på att området kanske inte är helt genomlyst och exponerat sitter kvar i huvudet, Cloud eller inte!

 

 

Tankar om MBT och testdata

Typewriter-2

På mitt nuvarande uppdrag ska en befintlig webbapplikation ersättas med en ny för att förenkla underhållet. Funktionaliteten ska vara densamma och GUI behålls till största delen oförändrat.

Detta är alltså vad vi inom test ställs inför. Sedan tidigare finns ett stort antal automatiserade tester som är skapade mha Model Based Testing där huvudfokus varit att verifiera de viktigaste affärsflöderna.

Vi vet även att det är väldigt viktigt att kontrollera att alla beräkningar är korrekta i den nya webbapplikationen samt att rätt inmatningsfält populeras i alla formulär. Via ett administrations gränssnitt kan man styra vilka inmatningsfält som skall visas mha olika konfigurationsparametrar.

Vårt angreppssätt för att erhålla så heltäckande test som möjligt har varit att variera grunddata via administrationsgränssnittet och sedan ange olika indata i formulären. Eftersom vi antar att den befintliga applikationen räknar rätt är det lätt att spara undan resultatet och använda detta som facit i den nya applikationen.

Hur strukturera vårt testdata?

Det finns som vanligt flera lösningar på ett och samma problem. Man kan spara informationen i en databas eller lägga en del data i modellen. Vi har valt att spara data i Excel där önskad rad hämtas med hjälp av en iterator i modellen. Med Excel blir det också väldigt enkelt att snabbt få en överblick i resultatfilen och se vilka värden som erhålls i gamla och nya applikationen

Slutsats:

Det känns som vi hittat en väldigt effektiv lösning där man kunnat återanvända bef modeller och automatiseringsskript som efter mindre modifieringar stöder testdatahantering med Excel. Det är dessutom väldigt enkelt att bygga på med mer omfattande tester och även verifiera felfall. Här är det dock inte lika lätt att tolka resultatet eftersom just felhanteringen kommer att skilja sig mellan nya och gamla applikationen.