Nu börjar det dra ihop sig till leverans! Imorgon ska allt vara klart och igår hade vi kodfrys. Detta innebär att vi slutar checka in ny funktionalitet och istället fokuserar på att bekräfta att den existerande funktionaliteten fungerar som den ska. Hela teamet, inklusive projektledare, kravare och utvecklare ägnar sig åt manuell testning, och kodfixar får endast checkas in efter överenskommelse, för att minimera risken att nya buggar introduceras i det här sena stadiet.

Man hör ofta skräckhistorier om hur utvecklingsteam får jobba långa veckor och sena kvällar just innan leverans för att hinna med att möta sin deadline, men så har inte fallet varit på det här projektet. Visst har det varit någon enstaka kväll här och där, men överlag är det business as usual häromkring.

Mjukvara blir, generellt sett, aldrig färdig. Det finns alltid mer användbar funktionalitet att implementera, fler buggar att fixa, stabiliteten och prestandan kan alltid förbättras, osv. Eftersom tiden ändock är begränsad uppstår behovet av att prioritera bland de många vägar man kan gå. Detta är speciellt sant precis innan en leverans. Målet är att leverera så mycket som möjligt, men det är omöjligt att hinna med allt, och då krävs att man identifierar det som är kritiskt för att projektet ska betraktas som framgångsrikt från kundens perspektiv och det som är acceptabelt att förskjutas till en senare patch. Vi har dock hunnit med den stora majoriteten av det som planerats, så det är god stämning och vi förväntar oss en nöjd kund.

Hörs igen snart!

Nu har det automattestats i några veckor och det har varit riktigt kul, så jag tänkte relatera lite grann av vad jag lärt mig  om att skriva automattester den senaste tiden.

Automattestning skiljer sig åt från manuell testning på några nyckelpunkter. Den stora fördelen med automattester är naturligtvis att det inte krävs en mänsklig testare för att exekvera testerna, och att det därmed går betydligt snabbare. Detta innebär att man kan sätta upp automattester som körs varje gång ny kod blir incheckad och kan upplysa teamet om potentiella problem med förändringen tidigt. Tar det för lång tid att köra igenom den totala testuppsättningen kan man välja ut nyckeltester som körs kontinuerligt och enbart köra alla tester över natten eller på ännu längre sikt. Dessutom garanterar automattester att de körs exakt enligt specifikationen varje gång, medan en människa lätt kan glömma att testa vissa detaljer.

Automattester har dock svagheter, och den sista punkten är båda en styrka och en svaghet. Nackdelen med att ha ett test som följer specifikationen exakt är att det inte lämnas något utrymme för variation och kreativitet i testprocessen. Testet garanterar att funktionaliteten som testet täcker fungerar, men existerar en bugg som triggas av att man varierar indatan lite grann kommer testet inte detektera den. En mänsklig testare skulle å andra sidan kanske naturligt variera indatan varje gång, och därmed ha större chans att trigga problemet. Manuell testning tillåter dessutom större flexibilitet, testaren är medveten om vilka förändringar som introducerats till systemet över tid och kan ta hänsyn till det i testproceduren. Ett automattest kan däremot snabbt bli obsolet, och i bästa fall innebär det att testet fallerar trots att systemet fungerar och i värsta fall passerar det och döljer faktiska problem. Tillsammans med den relativt höga tidskostnaden för att skriva testerna till att börja med kan utveckling och underhållning av automattester ta betydligt mer tid än de är värda, såvida testerna inte har hög “impact”, dvs att de har stor chans att detektera buggar om de uppstår.

Detta gör uppgiften att skriva bra automattester både utmanande och rolig. Att fundera ut vilka typer av tester man ska investera sin dyrbara tid i att skriva är en i allra högsta grad kreativ process. Det kräver att man är både djupt insatt i hur produkten man bygger är tänkt att fungera och att man har förståelse för vilka tekniska faktorer som tenderar att leda till felkällor.

Vi hörs!

Hej!

Jag heter Lucas Lindström och är ny trainee här på Cinnober. Jag är född och uppvuxen här i Umeå där jag läst på civilingenjörsprogrammet i teknisk datavetenskap. Jag tog examen vid nyår och har varit projektanställd som utvecklare under de första åtta månaderna av 2014. Jag hörde talas om Cinnober och cinCube av en kompis från universitetet, Oskar Janson, som också var trainee. Det verkade som en intressant och utmanande arbetsplats i en industri jag inte visste så mycket om men kände mig driven att lära mig mer om.

Nästan fyra veckor har gått sen jag började och det har varit full fart från dag ett. Det är alltid en utmaning att börja på ett nytt ställe och lära sig alla rutiner och processer, och även om jag hunnit arbeta på några olika ställen under och efter utbildningen är jag fortfarande väldigt ny på arbetsmarknaden. Cinnober är dessutom den största organisation jag arbetat hos hittills med ganska stor marginal, men trots det tycker jag att det varit en väldigt mjuk landning hittills. Större delen av första veckan bestod i en intensivkurs i allt från företagets historia och verksamhet i stora drag till systemarkitektur och arbetsmetodik i de olika projekten. Detta gjorde det mycket lättare att komma igång och förstå hur min roll passar in i den större bilden. En annan sak som gjort det så mycket lättare att komma in i tänket är den öppna och vänliga sociala atmosfären på företaget. Folk är alltid beredda att hjälpa till och svara på frågor när man kör fast eller inte förstår någonting.

De första tre månaderna av traineeprogrammet består av det så kallade testblocket, där man får pröva på rollen som mjukvarutestare. Att lära mig mer om test och kvalitetssäkring är något jag sett fram emot, eftersom det känns som nyttig erfarenhet oavsett vilken roll i utvecklingsprocessen man har, och något som jag saknat från universitetet.  Arbetet har hittills bestått framförallt i manuell testning av den grafiska klienten till LME Select (börsmotorn till London Metal Exchange, Cinnobers äldsta kund), blandat med halvdagskurser i mjukvarutest på Cinnober och i allmänhet. Det har gått snabbt att komma igång och kunna bidra till projektet och det känns mycket motiverande. Det är dessutom ett utmärkt sätt att bekanta sig med produkten och kundens förväntningar, liksom finansiell IT i allmänhet, vilket jag kan föreställa mig är viktigt även i andra roller. Nästa vecka ska jag börja skriva automatiserade tester, och det känns riktigt kul också.

Förhoppningsvis kommer den här bloggen ge insikt i hur cinCube-programmet fungerar och hur det är att börja arbeta på Cinnober, och jag är alltid öppen för frågor. Vi ses!

På måndag ska LMEClear go live. Nästa vecka är vi på kontoret från kl 7 fm till 1 fm. Vi är uppdelade i 3 grupper: AM skift 7-17, PM skift 15-1 och och de som jobbar under vanliga arbetstider och är On Call dagen runt. Jag jobbar PM skift. Det kommer bli spännande och jag får sova till typ 12 i en hel vecka! 😀

På måndag kommer LMEClear, deras medlemmar och regulatorer bestämma sig tillsammans om vi skulle Go live eller inte, det är ett Go-No Go möte. Men efter att ha testat systemet på olika nivåer då är vi säkra att vi går live utan stora problem!

Vi har den här skärmen på kontoret som räknar ner hur lång tid är kvar till Go-Live!

Cheerios!

Nu är jag och Oskar i moderskeppet! Vi kommer att jobba på Stockholms kontoret i en vecka på Service Desk. På Service-Desk erbjuder vi våra kunder en professionell support som optimerar deras TRADExpress upplevelse.

Beroende på vad kunden har beställt så kan vi erbjuda support. Det kan vara dygnet runt som i MarkitServ projektet. De som jobbar på Service Desk jobbar i olika skift. Planen är att vi provar alla olika skift under en vecka. Det ska bli spännande. Vi har träffat många av våra medarbetare på Service-Desk och de förklarar för oss hur allting funkar. På Service-Desk är det fokus på alla servrar som vi övervakar. Vi har också checklistor för övervakning av vissa system.

Vi kan se status för alla system på stora skärmar som finns här. På bilden ser ni Oskar och Claudio.

En spännade grej med våra ovanliga arbetstider är att man måste vara försiktig för att inte sätta igång larmet. Alla grinder på kontoret stängs kl 22 och larmet är på från kl 24. Om man går runt någonstans på kontoret förutom Service-Desk det kan bli problematiskt!!

Cheerios!

Hej!

Snart är det go-live för vår projekt, LMEClear (London Metal Exchange). Under den här perioden måste alla testa och fixa buggar. Vi jobbar med JIRA, vilket är en produkt för ärendehantering inom mjukvaruutveckling. Kunden testar vår produkt samtidigt som vi och om de hittar en bugg eller ett problem så skapar de ett ärende i JIRA. Den här typen av ärende kallas för Support jira. Sen testarna på Cinnober försöker att återskapa buggen och sen verifierar Support jiran som en valid bugg eller issue.

Vi skapar då en Development jira för varje verifierad Support jira som utvecklarna sedan kan börjar jobba på. Testledare och projektledare bestämmer hur viktigt varje bugg är och prioterar vilka som ska fixas först!

Så är det! Idag är det kodfrys, så nu ska jag fortsätta jobba och testa jiror! Det innebär att alla viktiga fixar måste checkas in idag för att nästa vecka så har vi en testvecka då vi testar befintlig funktionalitet utan att introducera ny kod som kan påverka. Det finns ingen utrymme för buggar i finansiella produkter!

Som trainee är det så trevligt att man får låna en lastbil hem över en kväll eller helg. Det passade jag på att utnyttja i helgen! Riktigt maffig känsla att rulla ut genom grindarna ensam i en lastbil för första gången kan jag säga. Till en början var jag inte helt cool, jag är ju allt annat än en erfaren trucker. Men ganska snabbt kom jag in i det och känslan av att jag faktiskt manövrerade runt det där stora fordonet var riktigt häftig!

Hälsade på min pojkväns föräldrar och både svärmor och svärfar ville givetvis ha sig en åktur. Men höjspunkten var nog min pojkväns 5-åriga kusinbarn som inte ville sluta åka och skrattade högt när vi provade vad de 730 hästkrafterna kunde göra 🙂

Jag kom just från ett samlingsmöte för outbound, alltså våra leveranser från produktionsenheterna till våra kunder. Det händer mycket på det här området just nu med nya upphandlingar och processförändringar. Väldigt intressant att träffa ansvariga från  Zwolle i Holland och Angers i Frankrike och även processutvecklare och ansvariga på orderkontoret på huvudkontoret.

Vi pratade en hel del om processen för avvikelsehantering. Den har varit väldigt bristfällig tidigare och våra leverantörer behöver hjälp att förstå syftet med rotorsaksanalyser och att lyfta fram avvikelser för att kunna jobba med dem. Tyvärr är insikten om detta relativt begränsad hos transportföretagen som är våra leverantörer i det här fallet. Så här finns mycket att göra! På “den andra sidan” när det gäller leveranser in till Scania och vår egen produktion har vi kommit mycket längre med att jobba med våra avvikelser internt. När det gäller outbound är det inte på samma nivå och vi behöver jobba med våra processer internt för att kunna ställa kraven på våra leverantörer.

Det är lite blandade känslor när jag förstå på vilken nivå vi och våra leverantörer befinner sig i det här området. Dels negativt såklart för att vi har mycket att jobba med som idag resulterar i kvalitetsproblem och slöserier. Dels positivt för att jag känner att jag kan bidra och att det jag lärt mig i skolan om 5 varför och fiskbensdiagram faktiskt kan göra väldigt stor skillnad. Dessutom ser jag ju verkligen svårigheten med att ändra mindset och kultur i ett så stort företag.

Nu kom precis en kollega förbi och gav mig en ny uppgift. Jag ska göra en upphandling av båttransport från en leverantör i Turkiet till vårt reservdelslager i Belgien. Här händer det grejer 🙂

Hej! Jag fick den stora äran att göra ett gästinlägg här på Emmas blogg. Ett erbjudande man helt enkelt inte kan tacka nej till! Jag heter Erik Hultgren och är Trainee på Scania IT. Jag tänkte berätta lite om vad jag pysslar med och vilka möjligheter det finns inom IT på Scania. Först och främst är IT stort även på ett industritungt företag som Scania. Enligt senaste rapporten är vi cirka 800 personer på Scania IT! 630 personer är placerade i Sverige medans resterande finns i övriga länder.

Min tid hittills som Trainee visar lite på den spännbredd som finns inom IT. Många tänker nog att vi sitter med huvudet nere och programmerar samt dricker Jolt cola, för att sedan åka hem för att fortsätta med att nöta kod eller spela spel. Den möjligheten finns självklart med om man är intresserad av det, men IT kan innebära mycket mer än så. I min första period arbetade jag i ett Agilt IT-projekt vilket bland annat innebär att man delar upp leveranser för att säkerhetsställa kundnyttan. Mitt uppdrag gick ut på att identifiera kopplingen mellan kunden och projektet för att säkerhetsställa att vi levererar nytta för kunden och inte bara ytterligare ett IT-system. Detta innebar en hel del processmodellering men även kontakt med verksamheten.

Idag sitter jag på en helt annan avdelningen och arbetar med incident- och problemhantering. Det kan vara allt från att produktion står stilla på grund av något IT relaterat fel eller att någon applikation för ekonomiavdelningen inte fungerar som den ska. Då skapas en incident för att ordna en snabb workaround så verksamheten kan återgå till arbetet. Nästa steg i processen är att identifiera rotorsaken så att samma incident inte händer igen. Detta är en utmanade men samtidigt väldig rolig uppgift då det kan hända saker när som.

Om cirka en timme börjar en puls som vi kör varje vecka för att sprida information om incidenter och problem. Samtliga siter från världen ringer även in för att vi ska kunna få en förståelse om hur olika problem och incidenter påverkar verksamheten. Ett av mina uppdrag är att titta på hur vi kan förbättra och effektivisera denna puls.

Nej, nu ska jag iväg och köpa en Jolt cola för att sedan återgå till arbetet!

//Erik Hultgren