Tankar och tips kring förvaltningsbar webb

Typewriter-2

Var på ett föredrag för ett tag sen som var rätt intressant. Ämnet var om att bygga förvaltningsbar och säker webb.
Några viktiga saker som jag fick med mig är bland annat hur jobbigt det kan bli med underhållet av webb när man plockar in tredjeparts ramverk som behöver uppdateras och patchas. Betänk hur många siter som använder tekniker såsom JQuery, dojo, Spring MVC, Struts mm. En del av ramverken som används ute i webbläsaren kan man gå in och (ofta) läsa vilken version som används och vilka sårbarheter som kan tänkas finns som är patchat i en senare version av ramverket. Det är ganska enkelt att hitta vilka sårbarheter som har fått patchar i senare versioner av ramverken då dessa brukar publiseras när det finns rättningar. Måste motvilligt medge att jag kanske inte alltid tänkt hela varvet runt när det gäller att införa nya ramverk och versioner av ramverk vad det innebär i längden när det gäller att driva en site och underhålla koden.

Men den viktiga frågan du själv ska ställa dig!
Hur ser det ut med produkten/siten/mm som jag testar? vilka ramverk och versioner använder vi? har vi koll på patchnivåer? har våran drift/underhållsorganisation koll på vilka ramverk och versioner vi använder? Kan jag själv testa om vi infört de nödvändiga patcharna? Vet testarna i projektet/organisationen hur man testar möjliga problempunkter?

Hur gör man då för att kolla tex vilken version av JQuery som används? Det är ganska enkelt, om du använder IE så ta upp en valfri site och tryck F12, nu kan du läsa/söka i HTML’en och i många fall kan hitta tex vilken version av jquery som används. Kör du firefox så öppna webbutvecklar verktyg (eller firebug mm) och kolla källkoden. Med dessa enkla verktyg kan du även kolla css och script på sidan.

När man kommer till backend systemen så är det inte fullt lika enkelt att finna vilka versioner och ramverk som används så här är det enklaste att helt enkelt be någon utvecklare/driftstekniker gå igenom och kolla vad som används och tillsammans får man gå igenom potentiella svagheter.

För egen del så ingår numera denna bit som en naturlig del när jag börjar arbetet med en ny webbsite/app.
* Gå igenom vilka ramverk och versioner som används
* Kolla om några ramverk öppet visar vilken version som används
* Har vi någon policy för hur man får införa nya ramverk? Skapa en sådan om den saknas
* Utifrån vilka ramverk och versioner som används gå igenom om det kommit nyare version som täpper exempelvis säkerhetsluckor

Givetvis finns det mycket mer att tänka på men det här är en bra start :-)

 

 

Ta fram en testplan på 10 minuter!

Typewriter-2

2011-10-03 STARWest, Anaheim, CA, James Whittaker (Testchef på Google)

slänger upp en slide om att testplaner ska ta 10 minuter att ta fram!

Engagerat halvskriker han åt oss att sluta producera material som ingen ändå bryr sig om eller läser och en testplan som inte leder till testfall är slöseri med tid!

Utan att orda för mycket om processen för hur Google kom fram till sin metodik kan man i alla fallsäga att James provocerade sina testare att fokusera på det viktigaste, det som ger det faktiska resultatet, genom att tvinga fram det med en extrem tidsbrist, d.v.s. 10 minuter….

Så småningom utvecklade sig det hela till Googles nya standard för testplaner, ACC.

ACC står för Attributes, Components and Capabilities och hjälper till att identifiera ”testområden”  utifrån dessa tre synsätt ….

Attributes på ett system skulle kunna vara snabb, säker, användbar, stabil etc.

Components kan vara saker som en toolbar, en flik, en modul, etc. I stort de byggstenar som vårt system/applikation består av.

Capabilities är saker som att ladda webbsida, spara kundorder, verifiera användare m.m.

Ok, så det innebär att vi har en bas att ta fram testfall ifrån och därmed är testplanen klar!

Ingen text om bakgrund, miljöer, vilka verktyg som kommer användas etc. utan bara totalt fokus på vad som kommer testas! Enkelt i teorin och kanske en inspiration att försöka minska all administrationsoverhead vi ibland tenderar att (frivilligt?) lägga in i vårt testarbete!

 

 

Visualisera testerna (om testdesign, krav och modellbaserad test)

Typewriter-2

Jag har i några av mina tidigare uppdrag jobbat med att automatisera test och jobbat med modellbaserad test som testdesignteknik. Vad som slagit mig vid flera tillfällen är att jag med hjälp av att tillsammans med kravställare ta fram en modell av kravet (eller koncept) så har vi hittat potentiella fel eller onödigt komplexa scenarier (ökad utvecklingstid) redan innan utvecklarna hunnit börja koda. Sen förenklar den visuella designen möjligheterna att föra en diskussion kring testdesignen med både utvecklare, testare och kravställare. Som jag ser det ett bra komplement till/eller ersättning för scriptade manuella testfall.

Metoden att skapa modeller som testdesign kan även hjälpa till att på ett strukturerat sätt börja skapa testdesign tidigare i projektet. Ytterliggare en potentiell fördel är att även mindre erfarna testare får ett bra stöd i att skapa en väl överskådlig testdesign på ett strukturerat sätt. När man sen kommer till att underhålla testdesignen så är det ofta enklare att underhålla en modell än scriptade testfall. Med en approach att skapa modeller även för manuella test så vinner vi dessutom mycket när det kommer till att skapa en automatisering som i många fall kommer att kunna använda samma modeller.

 

 

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!