Oracles senaste giv med att de gör hela sin närmast oöverblickbart omfattande produktflora av integrerade system tillgängliga färdiginstallerade och färdigintegrerade i molnet har spunnit igång IT-branschen i förvånansvärt ringa omfattning.
Man kan ju börja undra: Vad händer med testprofessionen om/när så gott som alla system ligger i molnet?
Det är ingen tvekan om att leverantörernas system blir allt mer komplexa och svåra att drifta. Att låta leverantören själv hosta dessa, sköta integrationerna och se till att allt fungerar blir allt mer lockande för många.
Om man sätter sig och leker med tanken på att IT-Sverige om åtta år består av IT-avdelningar vars insatser, förutom rena upphandlings- och omförhandlingsförfaranden, består av att till stor del består i att själva omkonfigurera (eller beställer konfigurationsändringar av) standardsystem i molnet. Testarbetet består då allt mer i att stämma av att dessa förändringar ger avsedd effekt, och att de inte förstör någon funktion eller förtar användarupplevelsen genom att ge usla prestanda eller göra GUI ointuitivt eller arbetsflödet knixigt.
Skillnaden är därmed inte så stor gentemot nuvarande kvalitetssäkringsarbete. Den stora skillnaden ligger nog i att testmiljön också kommer att ligga i molnet, och att medarbetarna i implementationsprojektet är väsentligt färre än idag.
Flera organisationer kommer nog inledningsvis att lita till att det är tillräckligt att den person som genomför förändringen/anpassningen även testar - men de kommer att märka att förankringsarbetet i organisationen, avstämningsarbetet mot verksamheten och testnoggrannheten ökar väsentligt med professionella testare - och vi kommer att ha en marknad kvar att genomföra vårt kall.
I rationaliseringens anda betyder det väl också att man låter förvaltningsorganisationens förvaltningsledare till applikationen driva förändringsarbetet och själv göra allt från insamling av önskemål från verksamheten, prioritering av dessa, implementationen av förändringarna samt leda kvalitetskontrollen av att systemet levererar sin nytta även efter förändringen.
Det innebär att vi kommer att se en hel del nuvarande projektledare som går över och måste utbildas inom test och kvalitetssäkring för de mindre organisationerna/systemen.
För större förändringar, och större system kommer det alltjämt att behövas regelrätta testledare.
Jag tror att det krävs att några dussin "om", i uppradningen av förutsättningarna ovan, slår in för att detta scenario ska uppstå. Sannolikheten är nog trots all större än många tror.
Jag reagerar på att utvecklare och konstruktionsledare nu diskuterar test livligt och entusiastiskt på allehanda forum på ett sätt de aldrig tidigare gjort. Jag upplever att de nu är i diskussionen ungefär där vi testare var för ungefär 10 år sedan. De är dock många och de jobbar snabbt och engagerat, och kommer förmodligen att vara ikapp våra egna slutsatser om effektiv test inom kort.
Självklart kommer det att påverka oss att en armé av kreativa och driftiga svenska utvecklare börjar engagera sig i testfrågor, och kanske finns det farhågor om vad som kommer att hända med oss professionella testare.
Jag tror att denna diskussion är nödvändig för att vi ska bibehålla konkurrenskraft i svensk mjukvaruutveckling. Jag tror inte att detta relativt nyväckta engagemang är av ondo för oss system- och acceptanstestare, men det kommer förmodligen att svänga om branschen en hel del.
Dels kommer hype-kurvan att göra att ett antal projekt misslyckas när utvecklare tror att de själva lärt sig tillräckligt mycket för att själva kunna testa systemet gott nog. Dels kommer det att bli lättare att prata test med kunderna eftersom det missioneras om det på bredare front.
Vi har den uppenbara fördelen av att ha vår långa erfarenhet, vår förmåga till helikopterseende i systemutvecklingen och vår vana att brottas med testproblematiken. Chansen är att vår tillvaro blir mycket lättare ju fler i projektet som har insikter om varför det är viktigt med kommunikation, testdata och testmiljöer.
Risken är dock att vi kommer att få vänja om vår begreppsvärld då kodande utvecklare gärna hittar på egna begrepp för att göra upptäckterna till sina - och för att få in dem i sin tankesfär. De testbegrepp vi använder har ju uppkommit eftersom vi ofta hamnar i gränslandet mellan utveckling och verksamhet. Ser man på begreppsvärlden som kodande utvecklare använder är den sällan anpassad till att vara förståelig för lekmannen. Är det bara tillräckligt många som använder de nya begreppen kommer det inte att dröja många år innan de ligger hemtamt även i kontakten med vår kunder.
Jag tror på test, och på den ljusnande framtid. Amen.
Jag måste erkänna att jag älskar små användbara webbtjänster. De kompromoterar inte testmiljön och de kan ändå göra skillnad i arbetet.
Här följer några exempel på sådana webbtjänster:
http://www.quickdiff.com
Jämför dokument, på längden och tvären.
http://vecka.nu
Mer tydligt och användarvänligt än så blir det knappt. Ett föredöme.
http://www.klockren.nu
Prova. Självförklarande.
http://pastebin.com
Underlättar all form av kod-, logg-fils, xml-filshantering o.s.v. Underbar. Som en Notepad++ men på webben (notepad++ finns även som oinstallerad portable-version som körs direkt från en oinstallerad fil).
Bidra gärna med dina egna länktips, så kan vi skapa en länksamling så småningom! :)
Visst, syftet med kvalitetssäkring är ju att man ska lägga ner tillräckliga ansträngningar för att säkra att systemet tas väl emot av alla grupper av intressenter. Det är en av huvuduppgifterna för det vi gör. Det inkluderar att kontrollera att systemet funkar som det är tänkt, att man tänkt rätt när man tänkt ut hur det ska funka, att det fungerar konsekvent och stabilt, att det arbetar undan tillräckligt snabbt o.s.v.
De senaste dagarna har jag suttit med i olika projekt och felsökt för att analysera fram felorsaker där avsevärda problem trots allt har uppstått i produktionsmiljöer. Det är naturligtvis fullständigt kasst att behöva sitta med sådant ur ett testhänseende. Det är bara ett problem... ett litet sådant... ett litet sådant som ändå besvärar mig... Jag tycker nämligen det är oroväckande stimulerande och kul att analysera felorsaker. Allra helst i produktion. Även om jag är en testare är jag ändå inte så sadistisk att jag njuter av folks olycka i produktion. Nej, jag ser ju testargärningen som en altruistisk martyrgärning - att man tar på sig att försöka finna systembrister för att alla andra ska slippa.
Nej, orsaken till att jag ändå blir upprymd vid felsökning i produktion har med stämningen att göra. Vid sådana här tillfällen är det alltid speciella omständigheter: Det känns som att röda mattan då är utrullad. Cheferna hämtar ivrigt och villigt kaffe åt alla i den task force som ofta upprättas. Det är en påtaglig stämning i luften; där finns förväntan, förtroende, snara beslutsvägar, tidigare omöjliga genvägar öppnas i organisationen. Alla inblandade slits känslomässigt mellan förvirring, kreativa utbrott, ivrig förhoppning, håglös uppgivenhet, falska insikter, aha-upplevelser och - till slut - en djup tillfredsställelse när allt fungerar som det ska igen.
Det är märkligt, men det knyts ett särskilt band mellan deltagarna i sådana här grupper som suttit tillsammans i några dagar. Det händer att jag snubblar in i folk som jag suttit i sådana här crunches med flera år senare, och man har fortfarande kvar någon form av underförstått samförstånd - man har delat en extraordinär upplevelse. Lite som brothers-in-arms på något sätt.
Ibland undrar jag om det inte finns projektledare som lever för dessa stunder så mycket att de slarvar med testerna - halvt omedvetet av sin undermedvetna önskan att få en chans att känna sig vibrerande levande i hetluften vid en incident.
Personligen önskar jag snarare att all systemutveckling skulle ske under dessa former av intensivt målinriktat samförstånd, där alla är beredda att offra sig för teamet, där organisationen curlar för projektet och där syfte, mål och mening med det man gör livligt uppfyller alla och envar. Då skulle man kunna åstadkomma mirakler.
Det är min utopi.
För något år sedan köpte Oracle testverktygföretaget Empirix. Empirix försökte slå sig in på den svenska marknaden i runt millennieskiftet och är mest kända för sitt verktyg för att prestandatesta webbapplikationer.
Nu har Oracle själva skaffat ett nytt verktyg som kallas för Oracle Real Application Testing. Tanken är ganska genial, men har ändå sina brister. Idén är att man helt enkelt spelar in all kommunikation till databasen. All kommunikation. ALL!
Man spelar alltså inte, som i andra lasttester, in vad en enskild användare gör och parameteriserar den kommunikationen så att den går att mångfaldiga. Med traditionella prestandatestverktyg skapas script för varje identifierat relevant scenario till dess att man kan få en simulering av användarbeteendet man litar på och kan spela upp.
Fördelen med ORAT är ju att man får en verklig distribution i både användarbeteende och datavariation. Det låter ju fantastiskt, men är ändå tyvärr förknippat med några brister.
För det första måste man vara noga med att backa sitt data till rätt ställe. Nu är det Oracle-databaser, och med dem kan man ta ett snapshot/duplicering vid ett visst läge och fortsätta arbetet som vanligt, vilket gör den proceduren relativt enkel. En viktigare aspekt då är att varje transaktion till en Oracle-databas tidsstämplas, vilket gör att man även måste ställa tillbaka klockan. Det är egentligen inte heller något stort hinder eftersom det är Oracles egna klocka det gäller, och den kan ställas med offset till systemtiden.
Den stora farhågan jag har är att man invaggas i falsk trygghet i att applikationen är prestandatestad bara genom att man kört på lasten på databasen. Moderna systembyggen är flerskiktade lösningar. Tack vare att DBA:erna har fått mycket bättre arbetsverktyg och bättre gehör för sina design-idéer de senaste åren upplever i vart fall jag att det numera är vanligare med prestandaproblem i andra lager än databasen (om man inte räknar enkla missade indexeringar). Verktyget är ändå så pass dyrt att jag tror att en del skulle hävda att man gjort en tillräcklig prestandatestinsats för att kunna driftsätta (ja, det stämmer. Den logiska kopplingen mellan pris och insats är verkligen mycket klenare än den mentala kopplingen dem emellan).
En annan aspekt är att verktyget heller inte verifierar data. Transaktionerna kan ju gå igenom så att DBMS inte protesterar, men det ändå inte blir rätt. Sådant kontrolleras lättare med andra verktyg (men även där måste man komma ihåg att kolla det, vilket ibland är prestandapåverkande).
Verktyget kan nog ha en plats i att verifiera att OS-patchning eller liknande inte påverkat prestanda nämnvärt negativt, men det testar bara databasen, och bara på Oracle, och bara svarstider.
Ni som har hängt med denna blogg ett tag vet att jag tidigare provat verktyget Pivotal Tracker för personlig ärendehantering. Det funkar OK, även om det har sina avigsidor. Nu har jag under några månader använt ett parallellt stöd i form av en variant av kanban/scrumtavla på mitt skrivbord. Det har funkat klockrent, så jag känner att jag gott kan dela med mig av tipset.
En del av mitt skrivbord är nu vigt till denna planering. Där sitter en del post-it-lappar enligt systemet nedan.
"Tavlan" är inte en regelrätt scrumboard eftersom jag inte delar in mitt uppgifter i iterationer. Det är heller inte några kanban-behållare eftersom det skulle kännas konstlat att ha någon gräns för hur många lappar det kan vara i varje kollumn. Det funkar ändå så bra att mina skrivbordsgrannar infört liknande system.
En besökare kom till mig och berättade att han hade ett likanande system hemma. Han hade dock en kanban-gräns av max en lapp i varje "låda", utom för Ice-box-kollumnen (längst till vänster i min bild). Han föreslog en kompletterande grej av att sätta ett streck på varje lapp varje morgon så att man visuellt snabbt ser när något blivit liggande länge, eller som stöd för minnet om en lapp åker bakåt i flödet (vilket händer). Ännu har inte det behövts, men jag kan se finessen med det.
En kort förklaring av kollumnerna:
Jag har valt att spara Done-lapparna istället för att slänga dem. Det är inte bara bra som arkiv (ofta står det telefonnummer, servernamn och liknande på lapparna) utan även för att jag visuellt kan se att jag faktiskt utför arbete - vilket är överraskande givande i vår abstrakta värld av mjukvaruutveckling.
Dela gärna med er av era bästa tips för att strukturera upp er vardag!
Som många andra har jag lockats av smidigheten med pairwise testing. Det är en teknik som gör att man välja ut relevanta testset när man har massor av kombinationer. Ansatsen är att felen är systematiska och uppträder vid parameterkombinationer (t.ex. ikryssad checkbox samtidigt som man har ett visst värde i en drop-down).
Om man t.ex. har tio olika varierande parametrar antar man att en defekt alltid märks vid en viss kombination av två olika parametrar. Om man hade haft tio parametrar med fem värden på varje hade det normalt blivit nästan 10 000 000 olika kombinationer att testa (5**10), men med någon av algoritmerna för pairwise testing får man istället ett testset bestående av ynka 50 testfall - och ändå ska man då kunna testa alla systematiska beroenden (i denna uträkning, med kombinationen av två olika parametrar. Med hänsyn till kombinationen av tre olika parametrar blir det 313 testfall o.s.v.).
Självklart vill man göra pairwise testing med verktyg - och även jag har slitit mitt hår med verktyg som AllPairs (James Bachs verktyg) och PICT (en förfinad variant som läckt ut från Microsofts utvecklingsavdelning) och ett par tre olika med GUI som jag testat.
Det är dock först nu jag funnit ett jag verkligen gillar! Jag fick nys om en Rick Kuhn på National Institute of Standards & Technology i USA och ett verktyg som han tagit fram och som kallades ACTS. Jag mailade honom och fick en inloggning till att ladda hem programmet. Det visade sig vara precis vad jag letat efter. Man anger enkelt parametrar/varianser samt beroenden dem emellan - och låter programmet bygga en tydlig och lättläst tabell över testfall! Imponerande.
Om någon är sugen på att prova - kontakta mig. Ett litet trösterikt meddelande till: Och om någon verkligen är sugen på att köra det från kommandotolken går även det - liksom från telefonen eller liknande eftersom det är skrivet i Java (men rätt ok ändå).
En helt ny, men lätt förutsägbar, trend har uppstått: Programvaruföretag som betalar för inrapporterade buggar under beta-testning. Exempel på detta är: http://techworld.idg.se/2.2524/1.336503/tjana-en-hacka--hacka-posten och häromdagen hade en av våra stora dagstidningar en artikel om fenomenet.
Egentligen är det väntat. Det finns fantastiska möjligheter att hitta arbetskraft när nu Internet suddat ut avstånden mellan människor. Varubytarsajter som Blocket, tjänstebytarsajter som Grannar och skryt-/skvallerbytarsajter som Facebook var bara början.
Att låta närmast anonyma slutanvändare hitta buggarna är genialt. Det är billigt och smidigt, men bara så länge det rör sig om masskonsumentsystem på webben och det inte är för många som försöker sig på tricket (eftersom antalet personer som har tid, ork och engagemang inte är oändligt).
När det rör sig om verksamheter som är mer specifika och icke-konsumentinriktade kan det bli svårare. De specialister som faktiskt kan se om ett framräknat värde i systemet är korrekt är också de som redan har ett yrke inom verksamhetsområdet - eller en professionell testare som läst på och är redo.
En fördel med distribuerade testteam är ju att man kan programmera på dagen och låta det bli testat under natten av Internetanvändare i en annan tidszon.
I Open Source-rörelsen har de ju en ytterligare fördel. Eftersom även källkoden är tillgänglig, så de kan även tillåta publik white-box-testning, när andra är hänvisade till ren black-box-testning i ordets mesta mening.
Hos en tidigare arbetsgivare hade vi en systerstudio som gjorde en liknande grej och lät betatestare rapportera buggar och få betalt för att minska på beroendet till betalda professionella testare. Det slutade dock med att de fick dock extraanställa personal ändå, men av ett annat slag. Det kom in så oerhört många felrapporter (varav nästan alla alltid var dubbletter för fel som redan var rapporterade) att hanteringen av alla dessa blev så omfattande att den krävde en handfull projektanställda administratörer istället. Till nästa release tog de därför till en annan lösning och jag misstänker att vi om några år har nått samma lösningen som de kom fram. Där anlitade man nämligen istället ett kollektiv av särskilt skickliga slutanvändare för dylika tester. Det var en färdig grupp löst kopplade människor som fick kollektivt betalt per testobjektsåtagande och som hade vana av denna typ av tester och som skötte sin egen defektrapportshantering - och det vore ju en framtidsutveckling som skulle passa ett konsultbolag som Knowit (som funderar lite på hur vi kan ta på oss åtaganden inom test) som handen i handsken.
=)
Det behövs inte mycken fantasi för att föreställa sig hur många slaganfall som orsakats av testmiljöhantering. Testmiljöhantering är jättesvårt. Miljöerna bör motsvara produktionsmiljöerna i alla relevanta aspekter, men ofta vill man vänta med att skaffa produktionsmiljöerna till så sent som möjligt. Dels vill man se hur systemet blir innan man vill dimensionera hårdvaran och dels gäller ännu Moores lag vilket gör hårdvaruprestanda billigare varje månad. Lägg till det att många är ovilliga till att investera i en dyr produktionslik testmiljö när den kommer att gå på tomgång 99% av tiden.
En attitydsfråga är också hanteringen av testdata och behörigheter. Jag har stött på företag som är jättenoga med säkerhet och integritet i sina produktionsdata, men kopierar dem regelbundet till en publikt åtkomlig testmiljö med löjligt lätta lösenord på testkonton som alltid är desamma (och av automatiseringsskäl är undantagna vanliga lösenordspolicys).
Jag minns ett internationellt storföretag som lade ut alla sina hemliga detaljerade inköpsdata för hela globala koncernen på detta sätt till dess vi testare påpekade det. Jag minns även en mycket hemlighetsmakande myndighet där det i prestandatesterna visade sig att efter den rigorösa lösenordsautentiseringen gjordes en ny klartextinloggning mot de egentliga systemen bakom från klienten. Det var dock att hänföra till arkitekturellt feltänk snarare än testmiljöhantering.
En liknande situation har de organisationer där script och resultat från prestandatester arkiveras som zip-arkiv på lättåtkomliga nätverksenheter. Bundlat med scripten ligger ofta användarnamn och lösenord, samt kanske annat känsligt data, i ren klartext - som vem som helst kan använda. Ofta är detta dock som väl är begränsat till konton till testmiljön (inte för att det gör det helt säkert ändå). Detsamma gäller självklart testfallsbeskrivningar med inloggningsdata, eller felrapporter med sådan information.
Ibland förundras jag över att felrapporteringssystemen är så öppna som de är. Deras syfte är att hantera detaljerad information om svagheter i systemen och hur man triggar dem. Många organisationer är försiktiga med den informationen, men långt ifrån alla.
Det jag tycker mig kunna sluta mig till är att de organisationer eller projekt som tycks ha koll på sina miljöer generellt är de som i vart fall jag uppfattar som mogna i sitt testande. Det är dock mycket möjligt att det är mina referensramar som är måttstocken snarare än denna företeelse...
Min uppmaning skulle ändå bli att tänka sig för hur testmiljöer, testdata och testkonton hanteras - för det har chansen att ge potentiella vinster långt utöver ren testeffektivitet.
Bilden av en PC som det som står på skrivbordet är redan död. På skrivbordet sker numera ofta minimalt med bearbetning. Detta är delvis sprunget ur att nätverksprestanda utvecklats mycket fortare än beräkningskraften hos datorerna vilket gjort att detta numera sällan utgör en flaskhals.
Trots marknadsföring under flera år lyfte den goda idén Tablet PC aldrig innan iPad och touch-plattorna nu kommer. Det är dock bara början. Med mer logik centralt i nätet, mer uppkopplade system, allt mindre hårdvara och allt smidigare sätt att interagera med datorerna kommer den typ av system som vi vuxit upp med inte längre att vara lika intressanta. Det är förmodligen en av anledningarna till att det satsas så mycket på lättare operativsystem (mobiltelefonoperativ). Android, Bada, iOS, Wave, Maemo, Moblin o.s.v. är alla försök till etableringar för att finnas som bas i denna framtid.
Med mindre enheter blir det svårare att kommunicera med dem. Att få datorer att förstå talat språk är svårt. Mycket svårt. Röstlägen, lokala språk, dialekter, slang, talfel, slarvigt språk, sinnesstämningar, talesätt, ironi och liknande är bara några av utmaningarna för forskarna. Maskin-till-maskin-kommunikation (M2M) däremot är relativt lätt, så länge det finns någon form av beständig standard att luta sig mot.
Räddningen är kanske gest-baserad kommunikation? Nintendo var först ut med ett embryo i sin Wii, men Microsoft och Sony kommer starkt och med lösningar som verkar mycket kompetentare. Dessa, tillsammans med positionering, eye-tracking-system som ser vad man tittar på, samt systemens historiskt ihopsamlade information om just Dig (och alla andra) kommer att ge helt andra förutsättningar för att gissa sig till vad du avser även med otydliga instruktioner (speciellt med de icke-binära processorer som börjar funka i labben nu).
Detta kan ge system som är mer intuitiva att använda, men kräver också en systemsamordning och centralt lagrad integritetskänslig information om var individ (varje system i sig ska ju inte behöva ha en ordlista över vad du menar med vissa uttryck, eller vad du har för intresseområden).
Allt detta kommer även att ge nya tydliga risker att verifiera. Gränssnitts- och format-tester (aka Samverkanstester), acceptanstester, referensgruppstester, prestandatester in the large, och ett ökat fokus på säkerhetstester osv.
Det känns kanske som ett möjligt, men aningen skrämmande, scenario. Det kanske bara är som jag inbillar mig, men när jag ser på vad vännerna skriver på Facebook - och hur publikt de lägger ut sina intresseområden (går med i olika grupper o.s.v.) kanske detta istället kommer att hamna på plats automatiskt och frivilligt, sprunget ur ett mänskligt behov av att definiera sig själv som individ i en grupp - och väcka andras intresse för det man själv brinner för? Förutsättningarna för ett George Orwell-liknande samhälle skapas ju enklast utifrån våra egna basala drifter. Det tycks just nu som avv vi frivillligt och ivrigt att valla in oss själva i det..
Efter många timmar i ett testsystem fullt av Lorem ipsum-texter blev jag så nyfiken att jag faktiskt kollade upp vad Lorem ipsum egentligen är för rappakalja.
Det visade sig ha en spännande historia och det är ett textstycke som använts som nonsens-text från 1500-talet (coolt att man behövde nonsenstexter redan då) !
Texten i sig är mycket äldre än så. Den är 2055 år gammal och skrevs av självaste Cicero (Titeln är ungefär "Ytterligheterna av godhet och ondska").
Standardstycket behandlar balansen mellan obehag och njutning - hur mycket möda är man beredd att genomgå för att vinna en viss njutning, eller vilket obehag är man redo att ta sig an för en viss njutnings skull.
Se där. Ännu ett stycke värdelöst vetande, men med chans till stor prestiege i t.ex. Trivial Persuit en vacker dag... :)
Anslaget 11:12 av Jörgen Damberg | Kategori: Jörgen Damberg; Kuriosa och skvaller | Unik webbadress |Skicka det här inlägget med e-post | Kommentarer (3)
Igår var jag och hälsade på vår namnkunnige kollega Henrik Emilsson på Knowit Karlstad. De har en tid arbetat med en kund som heter Compare TestLabs.
Det är en stiftelse som investerat 120 000 000 kr i ett systemtestlabb. Det är en intressant satsning, med problemet att de ännu inte når sista biten ut till kunderna. Imponerande 1000 kvadratmeter toppmoderna datorhallar, vigda för testverksamhet (primärt inte för drift eller utveckling) står redo för en kundanstormning som dessvärre tycks kunna utvecklas.
Vi hade en givande workshop med dem och definierade upp ett antal tjänster som kan antas locka testare mer än bara en datorhall. Det var spännande och kul, och jag hoppas att Knowit kommer att spela en stor roll i införandet av stödet för dessa tjänster.
De har även en del kopplingar till universitetet i Karlstad. Karlstad är en stad som satsar mycket på testning. Det är de som både arbetar med att ta fram en högskoleutbildning för mjukvarutestare och ett gymnasialt yrkesprogram för mjukvarutestare. Dessutom har universitetet där tagit fram en del akademiskt krångliga, men spännande testrelaterade verktyg (t.ex. ett för nätverksemulering).
Det ska bli spännande att se om de kan få denna verksamhet att lyckas - och över huvud taget följa Karlstads jakt på en proffesur inom mjukvarutestning - som nog skulle vara den första sådana i världen! :)
Om just du, i ditt projekt, känner att du är i behov av en flexibel extra testmiljö - kontakta gärna Henrik på Knowit Karlstad.
Det pratas ibland om testfabriker.
Några sådana har vi ju redan kommit i kontakt med. I Karlstad finns ett politiskt stöttat sådant initiativ som ska bli spännande att följa (där är bland annat Knowits egen Henrik Emilsson aktiv).
De testbänkar för prestandatest som många Knowitare har suttit i kan väl också räknas till sådana fabriker (som viktiga för dessa skulle jag nog kunna räkna upp samtliga Knowits prestandatestkunniga, utom mig själv eftersom jag aldrig suttit i en sådan).
Även inom TV-spelstestning finns det många stora specialiserade testcenter (olika center för t.ex. lokala anpassningar och språktester, plattforms-compliance, funktionella tester, juridisk granskning och hårdvaruvariationstester).
Den enda gång jag själv kommit till att jobba i något som liknade en testfabrik var nog på ett uppdrag där jag jobbade under Knowits Lisbeth Beijners (då på annat bolag) ledning i en svensk storbank. Uppdraget var att byta ut 36 standardarbetsplatser (resultatet av många uppköp) mot en enda. I detta arbete ingick även att porta alla applikationer samt att sätta en ny organisation i hela verksamheten.
VI hade inventerat hissnande 97 000 unika applikationer inom banken, oräknat alla de olika Excel-makron som används i verksamheten. Under några månader skapade och testade vi i storleksordningen 50 applikationer (så att de fungerade och inte störde andra viktiga applikationer) i veckan och landade med att ha testat ungefär 1 500 applikationspaket. För att klara den uppgiften fick vi applicera ett fabrikstänk.
Eftersom många organisationer är nyfikna på att själva skapa testcenter är det naturligt att man återigen försöker anbringa ett fabrikstänk på mjukvaruutvecklingen, och då blir kvalitetskontroll ånyo aktuellt ur ett fabrikstänk ("Test-on-tap", någon?).
Svårigheterna med att applicera ett fabrikstänk på mjukvaruutveckling är att det bara fungerar bättre ju mer lika varje produkt är, och att för att kvalitetssäkringen ska kunna genomsyra verksamheten bör det systematiseras in. Väldigt många svenska företag har egna IT-avdelningar som ombesörjer IT-stödet till verksamheten. Eftersom det rimligen blir en bred flora av system är det svårt att få till fabrikstänket på annat än små delar i taget (t.ex. en del av Driftavdelningens uppgifter).
För produktutvecklande bolag är det lättare - vilket gör att skiftet till molnet faktiskt talar för testcenter-tanken och fabrikstanken i stort. När produktbolagen har externt åtkomliga miljöer som kommer i likartade versioner bör det innebära en utmärkt grund för testfabrikers tjänster.
I kvalitetskontrollen i mekanisk industi sker testning utifrån statistiska metoder. Genom att testa en bråkdel av alla enheter kan man ändå snabbt få ett konfidensintervall om 97-99%. Detta är naturligtvis ett tankesätt som är tilltalande för regressionstester - och som vi kanske närmar oss förutsättningarna för? Det kräver både tydliga gränser mellan leverantör och beställares ansvar samt dokumenterade huvudflöden och datavariationer, men när det är på plats hoppas jag att regressionstester utifrån statistiska metoder visar sig vara mycket givande.
-"O den lysande framtid är vår! HURRA!"
Äntligen börjar det dyka upp integrerade och fungerande sammanhängande byggmiljöer.
När man fått ihop en fungerande infrastruktur för bygg- och deploy är halva QA-kampen i projektet vanligen över.
När vi repeterbart kan deploya utvalda systemförändringar (med känd påverkan) till valfri miljö, och mata dessa miljöer med "rätt" data är testarbetet så mycket lättare än om alla dessa steg måste ske manuellt.
Ofta tar det lång tid att få till detta eftersom versionshanteringssystem, byggservrar, kopieringsscript, automatiserade enhetstester, ETL-motorer och utvecklartänk måste komma samman för att detta ska funka.
Fler och fler företag satsar nu på att få ihop hela kakan. ThoughtWorks Studios Cruise 2.0, Microsoft Visual Studio Team Foundation Studio och många fler är på väg att försöka få till detta.
En utmaning med verktygsstödet i sammanhanget är såklart att sättet vi utvecklar mjukvara på också är föränderligt. Till exempel skulle ett versionshanteringssystem som GIT hade inte varit alls lika kraftfullt för tio år sedan, bara på grund av att distribuerad versionshantering inte var så aktuell då.
Jag tror ändå att detta är ett viktigt steg framåt, och hoppas bara att det inte sker på bekostnad av att det begränsar modulariseringen i verktygsuppsättningen.
Idag braskas det i nyheterna på stort om community-döden bland tonårssajterna. Lunarstorm och Playahead har lagt ner. Hamsterpaj och Apberget för en tynande tillvaro. Analyserna tycks bestå i att problemet är att stelbenta mediabolag tagit över dem och de självdött på grund av dålig anpassning för förändrade krav. Jag tror att förklaringen delvis stämmer, men att en stor del av problemet är att finna någon annanstans.
Jag är sannerligen ingen expert på mänskligt tänkande och agerande, men jag inbillar mig att när en grupp individer når tonåren är de i färd med att bevisa för sig själva och omvärlden att de nu blivit stora nog att själva förmå leva sitt liv. Detta tycks göras lättast och tydligast genom att bryta sig loss från de instutioner de känner till. Redan summerierna och de gamla grekerna klagade över ungdomarnas stöddiga attityd och att de försökte fjärma sig från det invanda, vilket upplevdes som provocerande redan då.
En sajt inriktad på tonåringar kan nog inte räkna med att hålla mer än några år, oavsett hur bra den är. När mediabolagen hostade upp belopp i 100 000 000 kronorsklassen byggde det nog på en felanalys. Anledningen att det är svårt att få det att funka är helt enkelt att det är lätt hänt att de som en gång gått med i en community trivs och blir kvar så att hela communuityn med tiden åldras - vilket i sig bromsar utvecklingen eftersom lojala återbesökare premieras. När en ny grupp ungdomar söker sin unika identitet kommer de aldrig att vända sig till en community som funnits i många år, oavsett hur perfekt anpassad den råkar vara - helt enkelt för att den i deras horisont funnits för alltid och därför per definition är en fossiliserad relik.
Undantagen som bekräftar regeln tycks dock finnas IRL. Fryshuset och alla kvartersgårdar har alltid lyckats locka ungdommar genom åren. En gissning är att det beror på personlig kontakt med de som driver stället, och jag gissar att de virtuella världarna ännu har en bit kvar innan de är bra nog för att kunna genomföra trevande tonårshångel i på ett sätt som känns rätt.
Analysen bygger också på att ungdomarna flyttat till Facebook, vilket nog stämmer. Facebook har såklart insett att ungdomarna snart kommer att tröttna på att skräna på samma virtuella torg som sina föräldrar och småsyskon och nu tycks jobba stenhårt med att få till användarnas möjlighet att välja vem som ska få se vad av det som uttrycks (det de så finurligt säljande kallar för integritetsåtstramningar). Kanske kan det rädda kvar användarna, men mer troligt är att Facebook nu närmar sig sin topp och att något annat Internet-fenomen snart bubblar upp - som bara genom att det är nytt kommer att locka över användarna att spendera sin tid där istället.
Alla insikter om användarbeteende tycks på det hela taget ha ett kortare bäst-före-datum än man tror. För några år sedan var chattande jättestort. Det är idag nästan dött. I Korea (som alltid varit ett föregångsland vad gäller social IT) gick användandet av mail ner otroligt mycket för några år sedan, för att kommunikationen flyttade över till chatt. Idag är det sociala nätverk som gäller där, men inte Facebook och liknande. Istället används massor av små specialiserade communitys inom massor av subkulturer - så att alla alltid finner likasinnade att umgås med online. Chansen är stor att även den trenden kommer hit (med alla aspekter det för med sig för samhället när det alltid går att finna ställen där alla tycker som en själv).
Jag, och flera med mig, hävdar att testare framgent kommer att behöva vara mångfacetterade renässansmänniskor med kunskaper i teknik, systemarkitektur, grupp-psykologi, användbarhet o.s.v. för att kunna göra vårt jobb väl. Det är en utmaning som idag ter sig större och svårare än någonsin. Teknikens framsteg gör att vi inte riktigt kan veta hur användarna kommer att använda systemen över tid.
På engelska finns begreppet The Last Mile. Det syftar på när någonting inte riktigt når hela vägen fram utan stupar på mållinjen. Vi har så mycket bra teknik, så många goda tankar och idéer, så mycket kunskap - och ändå når det inte riktigt hela vägen ut till att detta ska sammanföras till att börja användas på bred front.
Exempel på detta är t.ex. testverktyg och testdesigntekniker. Det finns massor av bra testverktyg, men ändå sitter många organisationer och testar på måfå eller med testinformationen hanterade i Office-produkterna. Om man analyserar bakomliggande faktorer ser man att det ofta är småsaker som stjälper. Man kanske inte törs välja. Man är orolig att verktygskompetensen försvinner. Man vill inte springa före en företagsvid satsning o.s.v.
I höstas startades ett projekt som kallas TestTooler, och som syftar till att råda bot på detta. Om man minskar uppstartssträckan till att bli minimal är det kanske till slut bara The Last Meter kvar istället - och det är ju plötsligt inom räckhåll.
Jag tror att detta kommer att komma starkt och på flera områden. Molntjänster är ett utmärkt exempel på att man kortar uppstartssträckan och minimerar påverkan. Genom att inköpsbeslut förenklas, förvaltningsförfarandet (administrativt) förenklas, driftsituationen förenklas o.s.v.
Många företag har dock integritets- och säkerhetsaspekter på att ladda upp data i molnet, speciellt för krav, testfall och defektrapporter eftersom de innehåller detaljerad infomation både om de algoritmer som ger företagen konkurrensfördelar samt om kända brister i systemen, och om dessas status.
Den som lyckas sammanföra och få igång en fungerande användning av befintlig teknik har stor chans att bli hjälte och vinnare, mer än den som tar fram ett aldrig så bra koncept. Här kan vi, som konsulter, ge värdefull input till våra kunder. Även om arbetsmarknaden går mot mycket kortare anställningar och mer runtflyttande är ofta ändå vi konsulter än mer vittberesta i branschen och mellan branscher - och kommer med nya intryck och idéer. Speciellt effektivt blir detta med utväxlingen av en fungerande erfarenhets- och kompetensöverföring mellan konsulter. Det bör vi aktivt förvalta och bidra med till våra kunder, självklart utan att för den skull åsidosätta den tystnadsplikt vi ofta bär med oss från tidigare uppdrag.
I flera organisationer tycker jag mig nu nu ha sett liknande mönster: Man upplever att man får på tok för många fel i produktion och initierar därför handlingskraftigt ett arbete med att se över testandet. Snart uppenbaras att test genomförs på väsentligt olika vis i olika delar av organisationen och man initierar därför ett projekt för testprocessutveckling och -ensning. Efter ytterligare analys inser man dock att testarbetets variationer ser olika ut för att utvecklingsarbetet sker på högst olika sätt i organisationen.
Testyrket har alltid varit en väldigt reaktiv syssla. Vi försöker påverka förutsättningarna till att genomföra effektiva tester, men i slutändan måste vi ta vad vi får och göra det bästa av det, vanligen utifrån ett riskperspektiv.
Utvecklingsprocessen är bara en av många saker som påverkar hur vi genomför test. När man börjar dra i testprocessen märker man därför snart att man även måste dra i att se över och ensa utvecklingsmodeller och förvaltningsmodeller - och kanske även omforma hela projektstyrningsmodellen.
Detta tar ganska lång tid, och involverar ganska många människor för feedback och förankring. Under tiden har testprocessarbetet avstannat av osäkerheten, och testorganisationen får syssla med annat ett tag. Det har dock, vid de tillfällen jag känner till, ändå slutat med att man med förvånansvärt små förändringar enkelt kan lyfta in den redan framtagna testprocessen i de senare framtagna utvecklingsmodellerna och förvaltningsmodellerna. Det beror nog inte bara på att effektiv testning är pragmatisk testning, utan även på att testarna brukar få vara med i framtagandet av utvecklingsmodellen, och testarna är ju de som har ett försprång genom att det är de som redan tänkt mest på processer och metoder vid det laget - och alltså har en tydlig världsbild och slipade argument. Go, test Go! Återigen visar sig test vara en föregångare, även i process- och metodarbetet. :)
Ur ett Tayloristiskt perspektiv kan det dessutom synas vara helt rätt att börja se på vad man vill få ut ur IT-fabriken (kod, och fläckfria testrapporter) och därefter fundera på hur man ska kunna åstadkomma det. Ur ett modernare sätt att se på processutvecklingen bör man nog snarare utgå från att definiera lämpliga sätt att hantera interaktionen mellan IT-organisationen och verksamheten och därefter fokusera på hur man ska få till kugghjulen i IT-utvecklandet. Det tycks dock som att det sätt jag beskriver överst en hyggligt fungerande kompromiss av de tu!
Till synes paradoxalt är ett av förslagen för att skydda en organisation mot överlastningsattacker att ha nätverkskomponeter från flera olika leverantörer, och med olika system på. Det kan tyckas att man då ökar attackytan, men det är också så att många attacker riktar sig mot en viss plattform och att man då alltid har tillräcklig kapacitet för att inte verksamheten ska slås ut medan man reparerar miljön.
Detta är ett sätt att tänka som man kanske bör ha i åtanke även inom andra områden? De senaste åren har många företag satsat på att standardisera IT-miljön, men får även allt större problem med att vidmakthålla detta då medarbetarna vant sig vid en flora av olika telefoner, och att t.ex. kunna plocka med sig sin privata iPod och ladda den i datorn på jobbet. Dessutom initierades denna standardiseringsiver utifrån ett behov av kostnadsbesparingar och kontroll - vilket delvis är en vandring på nya stigar i dagens molnvärld. Vill en medarbetare skulle denne lätt kunna ladda upp information till filtjänster i molnet, eller sända mail med hemliga dokument ändå. VIsserligen håller möjligen många organisationer ändå en viss nivå på övervakningen av trafiken ut från lokalerna, men med ökade möjligheter till distansarbete blir kontrollen över informationen svagare. Lösningen har för många företag varit att istället gå mot centraliserade applikationsarkitekturer. Mainframes terminalsystem och Citrix-applikationer är etablerat sedan länge, liksom webbapplikationer. Nu skrivs det mycket om att de virtualiserade skrivbordsmiljöerna är på väg att göra ett återtåg på företagen (Terminal Server-liknande lösningar). Kanske är det ett litet steg till mot kontroll över informationen, men den som vill kan nog behandla den mindre respektfullt/lojalt om de vill ändå. (Den som själv vill testa privata virtualiserade skrivbord kan lätt köra Dropbox med portable apps, eller en webtop som t.ex. iCloud.)
Det stora skiftet är inriktningen är kanske på att skydda information från att slippa ut, inte hämtas ut. Den tidigare fokuseringen på externa hot skiftar mot interna sådana.
Kanske ligger det något i det gamla talesättet att Information wants to be free? Information är viktigt, men det viktigaste är ändå vad man gör med den information man har tillgång till.
Möjligen lite Off-Topic, men det handlar ändå om funderingar om vad som sker i vår bransch.
För något decennium sedan stämdes Microsoft för att de sände med webbläsaren Internet Explorer med Windows, vilket ansågs hämma konkurrensen. I dagarna har Apple vuxit om Microsoft i värde och stänger ute konkurrensen genom att hävda sin rätt att bestämma vilken mjukvara som ska köras på deras hårdvara. Det tas fram bättre alternativ till de Apple-appar som bundlas med telefonen, men de hålls effektivt ute från telefonen av Apple, som ändå klarar sig utan rättsliga efterspel.
Någonting har hänt med tidsandan.
På samma sätt gick det förr att installera Linux på sin PS3, men det stödet togs bort i senaste uppdateringen för systemet - vilket orsakade ramaskri bland alla de forskare osv som använder den snabba programmerbara processorn och minnet i maskinen till att bygga kluster med stordatorprestanda av dem.
Var går egentligen gränsen för en tillverkares rätt att bestämma vad man gör med den produkt man redan köpt och äger? Om jag köper en brödrost (som ju innehåller mjukvara), vad får jag göra med den jämfört med om jag köper en TV (Samsung ändrade förresten nyligen så att man inte längre ska kunna köra egen mjukvara på deras TV-apparater). Vad om jag köper en telefon, som ju ständigt är uppkopplad så att leverantören kan puscha ut mjukvara till den? Apple har en mekanism för att både uppdatera OS och ta bort appar remote på telefoner, och förmodligen finns liknande i Windows Phone 7 och i Android (i vart fall finns sådana företagsbaserade lösningar, som dock måste installeras separat på telefonen).
Kanske har jag ett flummigt hippie-hjärta med teknik-geek touch, men jag tycker ofta att det är moddarna och hackarna som utgör den kreativa tekniska framkanten. Dessa hämmas av att de inte tillåts fippla med de apparater de köpt och äger.
Ett exempel: Det finns gott om PS2-emulatorer för PC. Problemet med att köra PS2-spel på PC är att DVD-skivorna läses lite annorlunda än på en PC (De hoppar över några missvisande block här och där som en del i kopieringsskyddet). Kreativa själar har skapat ny firmware till vissa PC-DVD-spelare så att de kan känna igen PS2-skivor och läsa dem - vilket gör att emulatorerna funkar med alla de skivor med PS2-spel som du äger, och inte bara med nedladdade spel. Äger Sony rätt att ha åsikter om vilken firmware du har i din dators DVD-läsare? De anser sig i vilket fall ha det för den dator som kallas för PS3. Var går egentligen gränsen?
Jag upplever ibland att vi går mot en allt mer sluten och proprietär IT-värld. Alla tillverkare sneglar på iTunes och Apple och bygger egna programbutiker. Windows, OsX, linuxdistributioner och tillämpade opertivsystemen Android, och möjligen Maemo och Chrome OS, får ännu stå som motpol till inlåsningen. Nästa slag kommer då att stå mot att kontrollera vilka webbapplikationer som kan köras på hårdvaran eftersom fler och fler applikationer finns på webben och mer och mer tekniker tas fram för att göra webbupplevelsen mindre webblik (som vi vant oss vid) och kraftfullare.
Från ett användarperpektiv, och ansvarskännande produktutvecklingsperspektiv, kan det möjligen motiveras. Ingen tillverkare vill bli förknippad med dåliga applitationer och trilskande upplevelser. Sony och Nintendo kollar så att spelen som släpps till deras konsoler inte är för dåliga eller buggiga. Apple kollar att apparna håller en tillräcklig nivå på samma sätt som Volvo tillhandahåller Originalreservdelar till sina bilar, med den skillnaden att du inte kan installera andra än godkända detaljer i din telefon.
Jag är innerligt glad att jag aldrig slog mig på banan som jurist... ;)
P.S. Med IPv6 och spridningen av de framtagna standarderna för M2M-kommunikation i hemmet dröjer det inte länge innan brödrosten faktiskt kan, och kommer att, uppdateras och funktionsändras på distans. D.S.
Jag erkänner direkt: Jag har missbrukat Pivotal Tracker några veckor nu. Egentligen är det ett snyggt samarbetsverktyg för agila projekt, men jag har använt det för högst personligt bruk. På mitt skrivbord hos kunden har jag en yta med fysiska post-it-lappar med aktiviteter, inordnade i någon slags kategorier baserat på flöde (i mitt fall "Avvaktar till senare (Obrådis)", "Att göra strax", "Pågående", "Väntar på andra" och "Done"). Eftersom detta system har begränsningen att det bara funkar när jag är på plats, och jag även har uppgifter som inte har med uppdraget att hålla reda på provade jag Pivotal Tracker eftersom många på mailinglistan Agile Sweden tycks förorda det.
Pivotal Tracker är snyggt, gratis och tydligt. Lite som en light-variant av verktygen Mingle eller Target Process. Man kan vara med i många projekt och lätt skapa egna.
Det är åtkomligt via webbläsaren, eller iPhone-appar (finns flera, dock samtliga från 3dje part). Härigenom kan jag på ett agil-projekt-inspirerat sätt hålla reda på uppgifter att utföra inom ramen för Knowit, familjen, husrenovering osv. Just nu har jag fem olika projekt i Pivotal Tracker och det funkar ganska bra. Vyerna över uppgifterna är anpassningsbara och grundläggande rapporter för uppföljning av progress (velocity osv) ingår.
Problemet för mig är att jag personligen sällan löser uppgifter i sprintar eller som en del i större projekt, utan bara betar av dem. Därför överväger jag nu att porta informationen i detta verktyg till vanliga ärendehanteringsverktyg. Jag har dock vant mig vid smidigheten och lärt mig överse med sprintindelningen vilket gör mig något avog till att genomföra skiftet.
På det hela taget är det ett smidigt litet verktyg, som nog kan ersätta många gula-lappar-tavlor, speciellt i projekt som är geografiskt spridda.
Idag tycks det vanligaste sättet att sprida idéer och erfarenheter i grupp vara 40- eller 50-minuterspresentationer på konferenser, frukostseminarier eller kvällsträffar.
Fördelen med detta sätt är att mottagarna inte behöver förbereda sig, och att det blir en chans att komma ifrån vardagsjobbet en aning vilket ger sina randeffekter. Nackdelen är dock att det är svårt att hinna med att få några djupare insikter på detta sätt, och att - om det visar sig att presentationen inte motsvarar förväntningarna - det inte går att styra den mot mer intressanta områden. För föreläsaren själv är dock detta både en trygghet i att man vet vad man ska säga och kan vara förberedd inom det delområde som presentationen handlar om. Det har dock nackdelen att man riskerar prata om ett ämne, när åhörarna egentligen hade tänkt sig något annat.
De enda alternativ jag kan komma på är Round-table-diskussioner (peer-conferenses) där en person kort presenterar en erfarenhet, och därefter blir utfrågad av deltagarna. Det ger en helt annan dynamik.
Ett annat alternativ är korta presentationer (Pecha Kucha eller Lightning Talks) i där den som presenterar koncentrerar sig på en praktisk nytta i en relativt kort presentation, typiskt runt 8 minuter. Det ger mindre flum och utfyllnad, och mer matnyttiga idéer.
Den senaste tiden har jag haft i bakhuvudet att det allra effektivaste sättet ändå kanske vore en workshop tillsammans med personer med gemensamt intresse. Ämnet borde vara abstrakt nog att göra så att alla kan vara med, men kräva att man diskuterar praktikaliteter. Typ: "Bästa sättet att mäta resursnyttjande vid prestandatest" eller "Metoder för testdatahantering vid testautomatisering". Min tanke är då att alla tvingas skapa rimlig samsyn innan man når ett resultat - och den diskussion som måste till blir utvecklande för alla.
Risken med denna form är att jantelag, tystnadsplikt eller prestiege kan komma emellan om det är främlingar som samlas. Det grundläggande problemet är dock att ju mer givande en kompetensutveckling i grupp ska vara, desto mer medverkan måste till av deltagarna/åhörarna, och människan tycks av naturen vara lat och gärna gå på konferenser för att mingla och få sig lite tid borta från vardagsjobbet snarare än att orka anstränga sig till att ödmjukt använda sina samlade likar för att bli mer insiktsfull.
Erkännande: Normalt börjar jag skriva rapporten innan jag genomför ett test. Det hjälper mig att strukturera tankarna och fokusera på det som är viktigt, samtidigt som det faktiskt tycks underlätta analysen. Under testerna fyller jag normalt i både protokoll och relevanta delar av rapporten parallellt, vilket brukar funka ganska bra. Nackdelen är ju att jag ofta får gå igenom rapporten i efterhand och ta bort överflödig information, men det är jag gärna villig att göra.
Denna gång hade dock testerna mer formen av felsökning via trial-and-error och ingen rapport upprättades under tiden vi provade våra teorier (mer än att vi strukturerade och strök i våra teorimatriser på en whiteboard).
Jag hade faktiskt hunnit glömma hur oääändligt mycket tråkigare och svårare det är att skriva en rapport i efterhand än att föra anteckningar i rapportform under tiden, och hur mycket sämre resultatet blir.
Nu lovar jag mig själv att nästa gång ska jag minsann göra som vanligt igen, även om den lilla fundamentalistiska skärvan av den annars ganska liberala processmänniskan i mig skriker i vånda över detta övertramp på naturlig arbetsgång.
Läste följande intressanta blogginlägg om Apples framtidsvisioner: http://www.antipope.org/charlie/blog-static/2010/04/why-steve-jobs-hates-flash.html
Intressant läsning, men jag undrar varför han inte tar upp att Google och tusentals andra företag i branschen jobbar hårt på att bygga bra webbapplikationer, och att det genomförs enorma arbeten på att få till webbtekniker för att köra klientsidesapplikationer som startas över webben (Java webstart, Google Gears, Microsoft Silverlight osv är bara början). Oavsett hur hårt Apple försöker låsa in oss kommer de samlade insatserna av alla som jobbar med att möjliggöra kraftfulla webblösningar att väga tyngre och Apple även om Apple ännu törs installera förvalda egna lösninga kommer de inte att kunna hålla borta alla andra - allra minst när Microsofts jurister ännu brottas med stämningen för att Microsoft förinstallerat Internet Explorer.
En annan grej jag reagerade på i artikeln är antagandet att ökad bandbredd automatiskt öppnar upp nya möjligheter. Ännu har QoS och trafikprioritering över Internet inte slagit i tillräcklig omfattning. Om operatörerna lyckas övertala världen att snabbt växla om till IPv6 sker detta lättare, men det finns ännu några fällor kvar. Även om bandbredden ökat mångfallt mer än datorprestanda i övrigt de senaste decennierna har denna ökade bandbredd snabbt ätits upp av nya tjänster och större datamängder att överföra. När 4 milliarder människor ska se streamad HD-upplöst film On-Demand över internet räcker inte ens de mest visionära framtidsdrömmarna om bandbredd till.
En tredje grej är att virus och andra hot inte försvinner för att data och applikationer ligger i molnet - de hamnar bara utanför ens egen räckvidd och ansvarsområde.
Men, det var ändå en tankeväckande artikel. Läs den gärna!
Agilitet i all ära. Jag är ändå ganska trött på den kodcentrering de flesta projekt tycks få numera. För tio år sedan var projektledaren kung och hade högsta status i projektet, men idag tycks de kodande utvecklarna på något sätt fått den rollen. Egentligen borde det kanske vara verksamhetsrepresentanterna som är kungar, men det ser man allt för sällan. I många projekt är det testledaren som hamnar på tronen mot slutet av projektet.
I mitt senaste projekt skapade vi efter några sprintar en KLAR-definition för varje delfunktion/user story i systemet.
Kodad
Levererad
Accepterad
Redovisad (=dokumenterad)
De kodande utvecklarna var helt nöjda med denna, och likaså konstruktionsledarna och verksamhetsrepresentanterna. Vi fick kämpa märkvärdigt länge för att för att få till akronymen KLART istället för KLAR:
Kodad
Levererad (till testmiljö)
Avstämd (det som tidigare kallades för Accepterad=överlämning till test och avstämning med beställaren så att man fattat rätt)
Redovisad (=dokumenterad)
Testad
Lägg märke till att även A i denna nu fått en annan betydelse när vi lyckades övertala dem att man inte vinner något på att acceptera (aom i acceptanstestgodkänna) varje sprint även om den inte ska produktionssättas.
Detta är möjligen en förbättring, men är ändå en grav halvmessyr eftersom Testad här inbegriper alla statusarna: Testad->fel funna->rättad->omtestad->regressionstest genomförd->eventuell testautomatisering implementerad->Återlämning till verksamheten->Acceptanstestad->Accepterad.
Sent omsider insåg alla i projektet att detta inte är idealt, men det fungerar märkvärdigt nog ändå hyggligt.
Det tog faktiskt även verksamheten lång tid att förstå att de antingen får dokumentera sina förväntningar noga, eller själva delta aktivt både i överlämningar/avstämningar och i själva testarbetet. Annars kan ingen veta om det faktiskt funkar som det är tänkt.
Några omgångar av partestning med systemtestare och verksamhetsmänniskor planerades in för att öppna deras ögon för kreativ och strukturerad testning, men tyvärr gick det om intet.
Trots allt gick allt till slut som vanligt: Ett väl riskavvägt beslut om driftsättning av ett system när tillräckligt mycket funktionalitet var testad (=en smärre försening på någon vecka) följt av en succéartad driftsättning.
På Agile Swedens mailinglista diskuterades olika verktyg för artt följa upp en produktbacklogg. Excel och/eller lappar på en tavla torde vara det vanligaste, följt av GreenHopper+Jira och möjligen Mingle (och det finns tydligen ett verktyg som heter Telerik om man kör TFS?).
Ett tips i diskussionen var dock samarbetsverktyget Pivotal Tracker, som jag kände att jag ville kolla upp. Det visade sig vara en mycket trevlig bekantskap. Verktyget är grafiskt elegant och intuitivt att använda. Verktyget hjälper till att genom historisk sprint velocity hålla koll på vad som bör få rum i en sprint och inte, samt för att hjälpa till att planera demos osv.
Utan att ha haft advokater till att granska licenstexten så tycks det vara gratis att använda även för projekt i företag (och enligt deras svar på olika forum verkar de ha den attityden också). Verktyget finns dock bara som molntjänst, så man måste känna sig bekväm med att ha sitt data externt. Det går visserligen att manuellt exportera sitt data till CSV-filer (läsbara i Excel) om man känner att man vill ha en inhemsk backup av data.
På det hela taget upplever jag det som ett imponerande trevligt och användbart verktyg, men ännu har jag inte fått chansen att prova det skarpt i ett projekt (ännu).
Anslaget 10:04 av Jörgen Damberg | Kategori: Testledning ; Verktyg och hjälpmedel; Arbetsplanering |Unik webbadress | Skicka det här inlägget med e-post | Kommentarer (0)
I mitt projekt använder vi Selenium för automatiserade tester i GUI. För enhetstester används Visual Studio.
Anledningen till att vi valde Selenium är flera:
Man kan välja att få ut koden i C# (vilket passar våra utvecklare) samt att vi enkelt kan versionshantera våra script tillsammans med koden. Detta gör att vi i framtiden kan branscha koden utan att vi därigenom gör automatiseringslösningen obrukbar på ena delen av koden. Detta behövs t.ex. vid snabba patchar i applikationen eller vidareutveckling av tyngre funktionalitet.
Ett annat skäl till valet av Selenium är att man med Selenium RC (Remote Control) kan använda samma script i olika webbläsare. Detta gör att vi i samband med byggprocessen (eller egentligen i deployprocessen till testmiljön) snabbt kan köra igenom ett antal testfall för att se så att systemet är testbart.
Det är två delar av Selenium-sviten som vi provat, men valt bort. Den ena är Selenium Grid. Det är en komponent för att distribuera ut tester till olika maskiner så att de körs parallellt. Fördelen är att man kan testa olika mot olika operativsystem och konfigurationer. Vi har dock inget lämpligt labb för detta, så vi lät bli den komponenten.
Den andra komponenten som vi låtit bli är det snygga GUI:t Bromine som används för att beskriva krav och sätta upp testkörningar för att verifiera dessa. Verktyget är snyggt och intuitivt - och gör Grid enkel att använda. Det är dock så begränsat så att det ger väldigt lite extra.
På det hela taget är vi nöjda med Selenium. Ambitionen för automatiseringen är ganska låg, utan verktyget används mest för att köra igenom några dussin smoke-tests som avser bekräfta att vi har vår testkonfiguration korrekt.
Provade Visual Studio 2010 i ett prestandatest på mitt uppdrag. Jag använder redan LoadRunner för att lasta det externa gränssnittet och Open STA för att lasta det interna gränssnittet, men ville gärna jämföra med Visual Studio 2010 från insidan också.
På enklaste sätt: Plockade hem betan och installerade. Provade att skapa testfall och parameterisera. Det fungerade smidigt, och även om GUI var lite segt i verktyget (kräver nog egentligen mer prestandaoptimeringar eller kraftfullare hårdvara) var upplevelsen intuitiv och smidig - faktiskt riktigt trevlig!
Tyvärr lyckades jag inte utföra några tester med verktyget. Det berodde på en bugg i verktyget som gjorde det inkompatibelt med vår säkerhetslösning. Förmodligen har det att göra med hur HTTP headern formatteras. Verktyget gick direkt mot webbplatsens IP-adress oavsett vilken url jag skrev in.
Eftersom detta verktyg vid testtillfället befann sig i tidig beta (det har kommit senare versioner - release candidates - sedan dess) så kan jag förlåta denna miss, och ser fram emot nya försök med verktyget lite senare.
Är på hemväg efter att ha varit i Oslo och hållit ett halvdagsseminarium om Open Source-verktyg. Som alltid är det lärorikt att diskutera test med andra testare, och det är något jag försöker uppmuntra.
En notering om en förnyad insikt denna gång: Även om jag träffat några få svenskar som använder verktyget Cucumber, men många som använder Selenium verkar man i Norge ha fastnat mer för Cucumber.
Med tanke på hur open source-verktyg brukat kunna finna sin väg in på företag (baserat på enskilda projektmedlemmar tidigare erfarenheter) är det kanske inte förvånande att olika verktyg får olika geografisk spridning, men urvalsmetoderna vid verktygsinföranden borde gå att förfina något.
I enskilda projekt kan det fungera bra med sådant urval, men efter projektets slut riskerar man stå utan verktygskompetens att vidmakthålla testautomatiseringen - och det finns enorma vinster på att kunna hålla automatiseringen igång i produktens förvaltningsfas.
Det tycks vara så att de flesta automatiseringssatsningar som räknas som misslyckade verkar bli misslyckade just för att överlämningen från utvecklingsprojektet till förvaltning misslyckas. Några misslyckas såklart även på grund av att uppdateringen av automatiseringen prioriteras ner tillfälligt vid någon release och att man därefter aldrig mer kommer ikapp, och automatiseringslösningen degenererar snabbt och blir värdelös. Själva värdet i automatiseringen handlar ofta om mycket mer än bara den insparade testtiden. Det stora värdet ligger i att man någorlunda tryggt törs refaktorera koden även sent i projektet och därigenom faktiskt minskar risken att buggar uppstår (tack vare att det är tydligare vad
koden gör) och får på köpet en mer förvaltningsbar kod.
Några andra nyvunna lärdomar: Jag fick lära mig om verktyget Cubic i Eclipse-ramverket (som jag ska prova vid tillfälle), samt hade en givande diskussion om den stora kostnaden för frekventa och dåligt koordinerade uppdateringar av testverktyg, uppdateringar som även drar med sig stora risker. Det ÄR sannerligen jättegivande att hålla seminarier!
Note to future self 1: Fyra timmar om samma ämne är något för länge för min stämma och energi (Heja Pablo, you rock).
Note to future self 2: Norge är exotiskt: Annorlunda mat, prisbild, "servicekänsla", arkitektur, alfabete, språk (norska är ett sagospråk), väder och lynne - och så kan man såklart handla tackschfree, även om prisskillnaden mot Systembolaget är mycket ringa...
Note to self 3: Glöm inte kontakta Se&Hör om att sälja bilderna på Leif Pagrotsky där han flirtar med damerna från Tele2 ombord på planet hem från Oslo.
Tänkte bara stämma av några av de erfarenheter jag har mot er samlade gedigna förståelse för utveckling. En tanke som grott länge i mig är att varje projekt går igenom ett par olika faser, som i sig innehåller olika utmaningar för test. Traditionellt brukar det fungera med en enkel process, men i en agil miljö får de gamla testutmaningarna nya effekter. I de typ tio scrumprojekt jag jobbat i tycker jag mig skönja ett ganska tydligt mönster. Har ni liknande erfarenheter, eller annorlunda dito?
I början av projektet gäller det för alla att förstå scopet i uppgiften och att få till en tillförlitlig initial Product Backlogg. Detta ger scrum/kanban/lean/dsdm osv ganska liten hjälp med (detsamma gäller de flesta andra metoder/tekniker). Tiden går åt till att lära känna de andra medlemmarnas förmågor och förväntningarna på projektet.
Stöd av scrum: Begränsat - även om samarbetet mellan verksamhet och utvecklare etableras och är värdefullt (men inte unikt för scrum).
Längd: 1-2 sprintar
Nästa fas innebär oftast att man ska bygga en grundplatta att implementera sitt system på. I denna fas ska man även vanligen mejsla fram sina initiala försök till process- och verktygsval. Det gäller att nöta in byggprocesser, förändringsprocesser, miljöer osv. En stor del av utvecklingen sker mot dåligt dokumenterade Tech Stories (kämpa fram ett databaslager, en första version på ett accesslager) snarare än mot User Stories för funktionalitet. Miljöer är sparsamma och teamen börjar lära sig att arbeta tillsammans. Mycket prestandatester på komponentnivå (för att testa arkitekturella begränsningar osv) och en hel del enhets- och komponenttester.
Stöd av scrum: Scrum Demo är snudd på värdelösa, men retrospective väldigt givande. Testning är extremt krånglig att få till. Underlagen är svaga, processerna och miljöerna inte riktigt på plats och testobjektet svåråtkomligt.
Längd: 1-5 sprintar beroende på typ av system (standardsystem, inköpta system osv)
Tredje fasen handlar mycket om produktion av funktionalitet. Arkitekturen har nu fallit på plats, och så mycket av systemets grundläggande komponenter är på plats att vertikal funktionalitet börjar skönjas allt mer. Det går lätt att testa, men mycket tid går ännu åt till att dokumentera runt testerna och att hantera testdata.
Stöd av scrum: Scrum Demo börjar äntligen vara riktigt givande. Scrum board funkar bra. Estimaten till backloggen börjar stämma. I denna fas gör sig scrum klart bäst!
Längd: 3-5 sprintar
I den fjärde fasen sätts scrum lite ur spel. Inga stora lättplannerade utvecklingsaktiviteter finns kvar, och det är många potentiella störningsmoment att hantera; med produktionssättningsplanering, utbildningar, marknadsföringsåtgärder osv. Även om väldigt lite faktiskt fungerar är det mesta av funktionaliteten nu utvecklad, och man ska bara få den att fungera klanderfritt (enskilt och i samspel med annan funktionalitet). Det handlar mycket om buggrättningar och miljökonfigureringar. Mycket högnivåtester, systemintegrationstester, systemtester osv.
Stöd av scrum: Demo börjar vara upprepning. Scrumboard halvkaotisk. Avstämningarna med kund är jättebra!
Längd: 1-4 sprintar
Summa summarum: Scrum funkar rätt bra i en halva i mitten av projektet. RUP tillkom ju med ansatsen att minska uppstartstiden i fas 1 och 2 genom att fördefiniera hur alla borde jobba för att det ska funka från början. Det upplevdes dock som för mastigt för de allra flesta att ta till sig och nu råder istället den agila, självinsvängande, mentaliteten i de flesta projekt och organisationer. Tyvärr tycks kunskapsåtervinningen ofta minimal mellan projekt (annat än förvaltningssituationer), annars hade det kanske funkat ännu mycket bättre.
Retrospective of retrospectives med scrum of scrums, någon?
Nyfiken på hur detta låter jämfört mer er erfarenhet?
Sitter i ett projekt i en koncern med väldigt isolerade enheter inom driftorganisationen. Nätverksgänget snackar inte med Windowsgruppen. Databasmänniskorna snackar inte med Storage. Övervakning inte med förvaltnings- elelr utvecklingsprojekten osv. Situationen är känd från många stora företag, och i viss mån funkar det ofta ändå hyggligt tack vare olika plattformsstandardiseringar, tvingande processer och ärendehanteringssystem för service-ordrar. I en diffus felsökningssituation är det dock väldigt suboptimalt.
På två arbetsdagar denna vecka har vi i denna organisation ändå åstadkommit prestanda- och stabilitetsförbättringar som annars skulle tagit många veckor att få till!
Metoden är beprövad: att samla en ”task force” av representanter från alla berörda parter i ett rum lokaliserat nära de som inte kunde delta fullt ut. Med representant från utvecklingsprojektet (där jag ingår), centrala DB, övervakning/larm, Windows-gruppen i ett konferensrum nära nätverksgruppen och storage har vi i ett enda svep lastat systemet, provat olika felsituationer, hittat och åtgärdat dessa – utan väntetider eller administration i ärendehanteringssystem!
En av framgångsfaktorerna var att vi visade klientupplevelsen via graferna från lasttestverktyget på stor-TV som alla kunde se samtidigt som vi gjorde våra förändringar och alla kunde spåra påverkan i sina respektive delområden via egna verktyg.
Efter viss inledande försiktigt revirpinkande med blame-game-varning blev det redan efter någon timme en riktig laginsats av alla. Efter den första dagen behövde vi en dag av miljöåtgärder och deploy av nytt applikationsbygge innan vi tog en dag till med omtester och ytterligare filande på flaskhalsarna i systemet.
Resultatet av dessa två dagar är att prestanda nu är 30 ggr bättre än innan och att larm och fail-over-situationerna funkar. Det visade det sig att de inte hade gjort annars. Innan hade vi ett tjog produktionshindrande fel som berodde på prestanda och miljö. Nu har vi istället "bara" alla kända fel och otestade områden att bekymra oss om....
Tyvärr har detta arbete dock skett på bekostnad av att jag inte hunnit engagera sig i de andra projekt som åligger mig. Det får dock bli nästa veckas samvete.