Vi jobbar hårt varje dag med att leverera våra system till kunder men någon gång nu och då roar vi oss med lite fest. Igår hade vi den årliga sommarfesten här i Umeå. Det började kl 14 med att vi gick till i20-skogen med Umeå sport och motion och hade lite samarbetsövningar. Det var roligt att umgås med kollegor och speciellt roligt var att mitt lag vann!

Efter roligheterna i i20-skogen var det middag på köksbaren i Umeå. Dom bjöd på otroligt god mat, vin och tilltugg.

I övrigt så går det ganska bra för mitt projekt just nu (LME Clear). Idag är sista utvecklingsdagen på denna sprint och hela nästa vecka har vi testvecka innan vi levererar denna release till kund. Det verkar som vi har lyckats täppa till ganska många buggar så jag hoppas att kunden blir riktigt nöjd med versionen vi levererar till dom nu.

Det var allt från mig för denna gång, ha en trevlig helg!

Nu närmar sig utvecklingsblocket med stormsteg för oss som började Cinnobers traineeprogram i våras. Det betyder alltså att det är dags att börja skriva kod som ska användas i London Metal Exchanges nya clearinghus, LME Clear.

Jag har börjat förbereda mig genom att läsa Effective Java och Optimal Trading Strategies. Den senare har egentligen ingenting att göra med att programmera, men eftersom det är just ett clearinghus som koden ska in i, så är det jättebra att veta hur handel fungerar. Här på Cinnober är det stort fokus på att kunna både tekniken och handeln, och eftersom jag inte direkt är insatt i finansvärlden sedan innan så tar jag tillfället i akt att lära mig allt jag kan för att bli en bra utvecklare redan nu!

Hittills har vi smygstartat utvecklingsblocket med en kurs i testdriven utveckling. Testdriven utveckling är väldigt populärt här på Cinnober och syftar till att skriva vältestad, testbar kod – man skriver helt enkelt test för koden innan man skriver själva koden. På det viset måste man skriva kod som går att testa och man har alltid test för den funktionalitet man vill ha.

Jag har satt ihop en liten önskelista med förväntningar till Cinnobertomten inför utvecklingsblocket:

• Testdriven utveckling vill jag jobba mer med – jag hoppas att vi får fler kurser på temat.
• Varierade arbetsuppgifter i många olika delar av systemet!
• Nya intressanta böcker till bokcirklarna!
• Sist men inte minst så förväntar jag mig kurser och workshops i hur man ska designa sin kod – hur ska den skrivas för att vara effektiv och lättläst?

Jag återkommer om några veckor med hur det går!

Hej,

Hoppas ni har det bra idag! Arbetet som trainee i MarkitSERV-projektet fortsätter, nu i rollen som ”kravare”. Officiellt är det i alla fall vad jag arbetar med, i verkligheten behöver man se till projektets behov och anpassa sig. Det kan leda till väldigt spännande kombinationer, speciellt då man är trainee och redan, utöver kravrollen, har erfarenhet utav rollerna testare och utvecklare. Då kan man hoppa in och hjälpa till med nästan vilka problem som helst!

För att ta ett exempel så börjar vi närma oss nästa release till vår kund. Av den anledningen har många övergått till att i huvudsak testa och omtesta buggfixar, däribland jag. Tänk att du hittar en bugg som testare och precis vet hur man som utvecklare ska göra för att fixa den. Just nu är jag i rollen som testare så jag skriver först en buggrapport men får höra att de andra utvecklarna har fullt upp för tillfället.

För att avlasta utvecklarna plockar istället jag upp buggrapporten, nu i utvecklarrollen, för att rätta till problemet. Under tiden inser jag att de dokument som beskriver hur funktionaliteten som buggen påverkar ska bete sig inte är tillräckligt tydliga. Innan jag kan gå vidare behöver jag konsultera en kravare som är kunnigare än mig i området, så jag gör det. Kravaren i fråga har dock väldigt mycket annat på bordet, en release närmar sig trots allt och att sätta sig in i något nytt kanske inte är lockande. Från kravaren får jag förtydligandet jag behöver för att fortsätta med min buggfix men han/hon hinner inte med att uppdatera dokumentationen. Det kan däremot jag göra, jag har området som ändringen gäller i färskt minne och behöver inte sätta mig in i så mycket nytt för att göra de nödvändiga ändringarna.

Dags att hoppa in i kravrollen! Jag gör de nödvändiga ändringarna i dokumentationen och förtydligar där det behövs. Som utvecklare kan jag nu slutföra mitt arbete och checka in buggfixen i vår kodbas, great success!

Där tar mitt arbete på bugfixen slut. Om ni har läst Johans utmärkta inlägg om hur man hanterar en bugrapport på ett professionellt sätt vet ni att någon måste testa min buggfix för att försäkra sig om att den faktiskt fungerar. Den personen är dock inte jag, man ska inte testa sitt eget utvecklingsarbete (förutom genom att skriva unit-tester) om det inte är ett nödfall.

Man skulle kunna kritisera arbetssättet ovan för att inget utav momenten, då de utförs utav mig och inte en specialist, går lika snabbt som de annars hade gjort. Det finns också en stor fördel i att olika ögon granskar ett problem och ifall man själv bär bugfixen genom tre fjärdedelar utav bugghanteringsflödet går man miste om den effekten. Vad man istället vinner är att övergången mellan de olika faserna i flödet sker smidigt. Man är redan insatt i problemet och det blir färre pauser för att introducera andra till buggen.

Jag tycker att scenariot beskriver den flexibilitet man får utav att genomgå trainee-utbildningen. Det är en väldigt häftig känsla att veta att man kan prata med testare som en testare, utvecklare som en utvecklare och kravare som en kravare. Det är en bredd man som nyanställd och icke-trainee kanske aldrig kommer att få. Då man börjar som specialist från dag ett kan det efter ett tag vara svårt att bredda sig i samma grad eftersom att man kanske blivit en av företagets experter på ett specifikt område och fortfarande behövs där. Då känns det istället bättre att börja väldigt brett och få testa på nästan alla roller som finns innan man går vidare och specialiserar sig.

Alla dagar ser knappast ut som den jag beskrev men någon dag i veckan den senaste månaden har jag arbetat i alla tre områden. Varje gång det händer känns det så oerhört coolt att man faktiskt väldigt flytande kan hoppa in i olika arbetsuppgifter.

Det var allt jag hade att säga för den här gången! Till er studenter som pluggar inför de sista tentorna innan sommaren vill jag säga lycka till! Om du är i slutet av utbildningen och skriver på exjobbsrapporten i rasande takt vill jag också tipsa om att vi fortfarande tar in ansökningar till nästa omgång utav traineeprogrammet. Så titta upp från skrivandet ett tag och skicka in en ansökan, utbildningen är grym och branschen är högintressant. Sista ansökningsdag är 30:e maj så tveka inte!

En av Cinnobers största projekt LMEClear (London Metal Exchange) närmar sig sitt slut. Så efter projektets behov har jag jobbat med testning dom senaste veckorna. Kvalitet är väldigt viktigt i finansiella system så systemet måste testas ordentligt. Så vi har lagt kraven på is för tillfället och passar på att uttnytja vår lärdom under testkurserna. Jag skriver autotester i LMEClear och det känns bra att se att jag kan skriva ganska good looking tester!

Snart är det dags att flytta till vårt nya kontor i centrala Umeå. I torsdags hade vi en vernissage på kontoret som gav oss information om den kommande flytten. Flytten sker under juni..bara en månad kvar!

Anledningen till flytten är att vi har blivit många anställda och behöver mer utrymme. Det nya kontoret har plats för 100 personer vilket nästan blir en fördubbling mot det nuvarande. Läget på det nya kontoret är perfekt och det är väldigt modernt och stort och det ger oss möjligheten att expandera framöver.

Det här är vernissagen vi hade. Det visar hur kontoret och flytten är planerade. : )

Här på Cinnober jobbar vi med en agil utvecklingsmetod som heter Scrum. Agila utvecklingsmetoder har fått en bred spridning i mjukvaruutvecklingsbranschen dom senaste åren. Med scrum så delar vi in arbetet i så kallade sprintar som är i normala fall är 2-5 veckor långa och avslutas med en leverans till kunden i projektet. Arbetet i sprinten delas upp i tickets som innehåller en mängd arbete, detta kan vara vad som helst ifrån en bugrapport till nyutveckling av funktionalitet till interna kom-ihåg-lappar för allt möjligt som behövs göras i projektet. Vi använder ett verktyg som kallas Jira för att hantera detta. I mitt fall på kundprojektet LME Clear sitter det ganska många testare i London som testar våran senaste leverans och när dom upptäckt en potentiell bug så skriver dom en Jira och skickar till oss. Vi får in denna Jira på en tavla där vi samlar alla Jiror som kommer in från kund.

Processen därefter är att någon på våran sida tar den inkomna Jiran (bugrapporten) och försöker verifiera den. Ibland visar det sig att kunden tror att det är en bug när det egentligen inte är det eller att deras system inte är korrekt installerat. När vi verifierat den som en riktig bug kommer den in på vår interna Jira tavla som ser ut ungefär så här.

I detta läget är buggen verifierad och en utvecklare tar på sig att fixa buggen. När utvecklaren tycker att buggen är rättad sätts Jiran i For Test hos oss internt där en testare hos oss testar av Jiran. Ibland hittar vi här att buggen inte är rättad eller att något corner case som utvecklaren inte tänkt på gör att buggen kommer upp igen. I detta fall flyttas Jiran till To Do och bollen hamnar hos utvecklaren igen. Om våra interna testare tycker att buggen är rättad så stängs den interna Jiran och motsvarande kundjira sätts till For Test by Customer, då kunden får testa av buggen igen när nästa release levereras.

Genom att jobba på detta vis testas defekterna av i flera steg och minst tre olika personer testar samma bug. Detta gör att vi kan hålla en hög kvalite i våra system och leverera mjukvara i världsklass till våra kunder

http://en.wikipedia.org/wiki/File:Design_Management_in_brief.jpg

Hej, här kommer en ny liten uppdatering från mig.

Då det kundprojekt jag jobbar i börjar närma sig ytterligare en viktig milstolpe på vägen till release så har jag på efterfrågan från projektledningen nu tillfälligt gått tillbaka till testrollen för att förstärka upp inom kvalitetssäkring av den funktionalitet vi bygger.
Det känns uppskattat att vi trainees är en värdefull resurs och det ska bli roligt att åter få användning av den kunskap inom testning och den produktkännedom jag hittils förvärvat mig.

Cinnober’s platta organisation där vi jobbar agilt i små kundprojekt ger korta beslutsvägar vilket underlättar förvånadsvärt mycket för projektledningen när det kommer till att omprioritera projektets resurser allt eftersom kundens behov ändras. Detta gör att man som anställd vid behov kan flyttas runt inom kundprojektet till ett annat prioriterat område för att effektivisera, men det kan också bli så att man får hoppa in i andra kundprojekt för att hjälpa till. Detta ser jag som en styrka då det bidrar till att man som individ snabbt kan förvärvar sig ny spännande kunskap.

Hallå allihopa!

Som ni som följer den här bloggen har förstått så antogs två traineer under senaste vändan. Då undrar ni förstås var den andra har tagit vägen – Johan presenterade ju sig själv för en och en halv månad sedan!

Ni behöver inte oroa er, för det är jag som är den andra traineen. Jag heter Rasmus Leijon och började för tre månader sedan (har det gått så länge redan?!) här på Cinnober, och sedan starten så har jag varit rejält upptagen med att arbeta som testare.

Jag har läst en master i matematik vid Umeå Universitet, men jag har lite blandade inslag i min utbildning av fysik och datavetenskap också. Man skulle kunna säga att jag har varit väldigt osäker på var jag egentligen skulle hamna – och hur jag nu skulle få använding av min djupa kunskap inom komplex analys på kalibrerade mångfalder i arbetslivet. Det visar sig att det inte är helt bortkastade kunskaper när man arbetar på Cinnober, finansiell teknologi är full av tillfällen att applicera analytiskt tänk!

Som testare så är det en hel del att göra; eftersom vi ställer så höga krav på att våra system ska vara felfria och pålitliga så krävs en hel del felsökning (hitta nya svagheter i systemet) och regressionstestning (se till att gamla fel inte kommit tillbaka). Inte desto mindre nu när vårt projekt går så sakteliga mot sitt slut.

Testningsblocket går nu mot sitt slut och vi har blivit färdiga testare, utrustade med all kunskap som man kan tänkas behöva inom testning! Vi har fått ta del av bland annat:

–       Bokcirklar med litteratur om testning, Experiences of Test Automation och Lessons Learned in Software Testing

–       Föreläsningar i teststrategi (hur ska man lägga upp själva testandet?)

–       Föreläsningar i presentationsteknik

–       Föreläsningar i performancetest (kvalitetstest – hur snabb är produkten? Frågor man oftast inte tänker på innan det är för sent om man inte har tagit med sådant i planen)

–       Föreläsningar i funktionella tester (hur man skriver automatiskatester)

–       Mycket mer!

På det stora hela känns det som att man har kommit in i teamet som testare – och nu är det dags att byta till att själva utveckla systemet och bli tvungna att vara de som får rätta de fel som hittas. Det blir superkul.

Ajöss, vi höres under utvecklingsblocket om inte annat!

Nu är vi klara med utveckingsblocket. Igår började vi med kravblocket och hade en heldags introduktionskurs. Vi gick igenom koncept i kravhantering. Det finns många modeller och digram som används i kravhantering för att underlätta förståelsen av systemet och verksamheten. En av dom som jag tycker är intressant heter: Objectives Model. Denna modell visar systemets funktioner i helheten och ger en översikt om vad som måste göras.

Ett viktig koncept inom kravhantering är Value Chain. Value Chain länkar till Supply Chain och Business strategin. Det innebär att value chain visar aktivitier som resulterar i en värdeful produkt. Bilden nedan visar Cinnobers value chain:

Under kravblocket har vi kurslitteratur som vi måste läsa. Den första boken heter: ”The Business Analyst’s Handbook”.

Det är snart helg! Jag ska till Stockholm för att fira persiskt nytt år med mina kompisar!
Happy Nowruz!

Hej alla bloggläsare!

Johan Sundberg heter jag och har börjat som trainee här på Cinnober för sju veckor sedan nu. Jag har läst Civilingenjör, teknisk fysik vid Umeå Universitet och tog examen i januari. Traineeperioden på Cinnober är indelad i lite olika block och just nu är jag mitt uppe i testblocket som är 12 veckor långt. Blocket varvas med utbildning och praktiskt arbete i ett kundprojekt, jag tillsammans med min kompanjon Rasmus (den andra traineen som började samtidigt) är i projektet LME Clear (London Metal Exchange Clearing). LME är världens största börs för optioner och terminer för metaller och Cinnober levererar med det kundprojekt jag är med i mjukvaran till ett clearinghus som tillhör LME.

Testning som koncept var helt nytt för mig innan jag började jobba här, det jag kunde associera med testning innan var i princip kolla att din användare inte skriver in konstiga saker som input till ditt program, som är i princip så långt som mina kurser på universitetet tog detta. Området testning är väldigt stort men jag tänkte berätta lite kort om de tre huvudnivåer i systemet som man brukar dela in testningen i och vad jag har gjort senaste veckorna.

(Bild tagen från https://vinodkumaar.wordpress.com/tag/functional-test/)

Det finns många olika tankar kring hur man ska testa men ganska generellt kan man sammanfatta de olika testnivåerna i systemet som i bilden ovan. Unit tester är tester som utvecklare skriver och körs direkt mot källkoden, t.ex tester som körs mot individuella metoder i klasser. Integration/functional testning testar en eller flera moduler i systemet. UI/system/exploratory nivån är högsta nivån där man testar hela systemet. Tanken med uppdelningen är att man ska hitta buggar snabbt och på rätt nivå, då blir det mycket enklare att hitta och rätta buggar.

En stor del av tiden på Cinnober hittils förutom att lära sig alla nya begrepp och nya rutiner osv har gått åt till att lära mig FIX protokollet och skriva tester mot det. FIX är en standard inom finansbranschen för att skicka information om t.ex transaktioner och mycket annat. LME Clearing systemet som jag hjälper till att utveckla tar emot matchade ordrar från London metal exchange och ska sedan lägga in dom i clearingsystemet. I det lagret vill vi vara säkra på att inga konstigheter skickas i FIX-meddelandet som t.ex konstiga ascii-tecken, nullsträngar osv då det har hänt att vi har fått in buggar på detta.

Det har blivit en del programmering och utvecklande av automatiska tester som skickar in alla möjliga konstiga FIX-meddelanden med ogiltiga fält osv för att kolla vad våran mottagande server svarar med. Dessa tester kan klassas in i kategorin integration/functional test i pyramiden ovan. Det fina med att utveckla automattester är att vi lägger in dom i en byggplattform som kör testerna automatiskt flera gånger per dag mot senaste versionen av källkoden, detta gör att man snabbt kan se om systemet beter sig annorlunda om man ändrar i koden nånstans. Denna metod är väldigt effektiv när man utvecklar kritiska system som t.ex börser där man lägger stor vikt vid att det inte ska finnas buggar som kan sänka mjukvaran.

Det var allt från mig den här gången, ha en toppendag!

Hej!

Det börjar bli lite lugnare inom MarkitSERV-projektet nu, i tisdags tog vår sprint slut och vi hade release utav vår senaste version till kunden så innan dess var stämningen smått hektisk. Efter sprintens slut har vi hunnit med att ha retrospective (tillbakablick på sprinten som gått) och planerat nästa sprint som kommer att sträcka sig till mitten av mars. Min roll som utvecklare under den nya sprinten ligger fortsatt på att fixa buggar som testarna och kunden har hittat vilket är något jag trivs bra med. Det ger möjlighet att se många olika delar av systemet vilket är till stor nytta senare då man behöver lägga på ny funktionalitet. Men nog om det! Jag tänkte att det kunde vara av intresse att få inblick i hur en vanlig dag på Cinnober ser ut då man är trainee, så här är en sammanfattning utav min fredag:

8:45

Efter att ha åkt buss in till centrum anländer jag kring 8:45. Jag utför morgonritualen som är att läsa mail och uppdatera systemet till den senaste versionen samt kikar på hur de nattliga testerna gått.

9:00

Dags för Scrum-möte! Här går vi igenom varje område vi arbetar med i projektet och ger varandra uppdateringar om vad vi arbetar med. Fokus ligger på att vara snabb, konkret och att flagga för problem och svårigheter man stött på så att dessa snabbt kan tas om hand om. Mötena är bokade för en halvtimma men vi är vanligen klara efter 15 minuter.

9:30

Före allt annat arbete sker går jag och hämtar dagens första kopp kaffe. Eftersom att jag blev klar med en tidigare bugg dagen innan börjar jag leta efter nästa problem att ta mig an. Det är svårare än vad man kan tro! Eftersom att jag fortfarande är relativt ny på området vill jag välja sådana uppgifter där jag lär mig något nytt men som samtidigt inte ligger för högt ovan vad jag kan. Ibland kan det ta rätt lång tid att hitta något som är lämpligt, men idag får jag efter ett litet tag tips på en bugg som passar och jag börjar efter en kort introduktion arbeta på den. Själva buggen är att fel data visas i en kolumn i en tabell i GUI:t. Jag ska ändra så att rätt data visas. Det kan ju inte vara särskilt krångligt?

10:30

Det visar sig att sättet man vill rätta buggen på inte står beskrivet i buggrapporten eller i de kravdokument som rör området. Om jag bara följer det som står skrivet i rapporten slutar det med att två kolumner som har snarlika namn visar exakt samma data. Någon av kolumnerna är då onödig och borde tas bort. Men vilken? Det betyder att jag behöver konsultera kravanalytikerna för projektet. Lyckligtvis har vi sedan sommaren en ”kravare” i Umeå som arbetar i projektet så tillsammans resonerar vi oss fram till på vilket sätt jag ska lösa problemet.

11:30

Lunch!

12:15

Med kaffet i högsta hugg sätter jag mig ned och arbetar vidare. Det verkar som att den lösningen vi kom fram till har bredare konsekvenser än väntat. För att tabellen ska vara sammanhängande och förståelig behöver jag, om jag vill genomföra mina ändringar, byta namn på fler kolumner. I så fall behöver kravdokumenten ändras.. Ajdå. Det kanske är dags att backa lite?

14:00

Paus i arbetet för en väldigt kort avstämning för hur det går med trainee-programmet.

14:30

Fredagsfika inom projektet. Det finns ingen plats i köket eftersom att Sveriges hockeymatch mot Finland visas på projektorn. Vi lyckas hitta ett rum bredvid och avnjuter hembakta muffins. 😀

15:00

Äventyret med kolumnerna fortsätter. I samförstånd med projektets kravare bestämmer vi oss för att backa alla ändringar och ta bort den andra kolumnen. Allting går därefter som en dans och ett tag senare kan jag testa mina ändringar på mitt lokala system. Det fungerar och ser bra ut, men klockan börjar bli rätt mycket så jag väntar med att checka in tills efter helgen. Det finns få saker som är hemskare än att råka checka in kod som orsakar byggfel sent en fredag!

16:30

Det är inte särskilt lång tid kvar på dagen och kontoret börjar lugna ned sig lite så jag tar tillfället i akt att läsa lite trainee-litteratur! I detta fallet blev det att läsa några avsnitt i ”Working Effectively with Legacy Code”.

17:15

Dags att ta helg och möta upp med min älskling för att äta god mat och träffa några vänner i centrum.

Det var allt för den här gången! Ha en trevlig kväll. 🙂