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!

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!