Posts Tagged ‘agil_testning’

h1

Premiär för ny kurs på Crisp! Agil Testning och Den Agila Testaren, 14-15 April

söndag, 23 mars, 2014

Den 14-15 April ger jag och Crisp kollegan Alexander Tarnowski kursen “Agil Testning och Den Agila Testaren”. Strax över tre veckor kvar till premiären. Att det är preminär för mig och Alexander som publika kurslärare i Crisps lokaler gör det också extra skoj och spännande.

Vi har båda hållt kurser och föreläst om agil testning, testautomatisering, test driven utveckling, m.m. många gånger, men detta är första gången vi gör det tillsammans. Då vi kommer från olika bakgrunder och bär med oss olika vinklar har vi lyckats skapa ett grymt och dynamiskt innehåll. Det känns skoj att kunna diskutera både inifrån och ut, och tvärt om.

Att både kunna diskutera på bredd och djup tror jag gör att vi sticker ut om man jämför vad andra kurshållare kan erbjuda. Jag har kanske primärt jobbat med agil testning från ett team-, process- och coachperspektiv. Alexander skriver just nu på boken “Developer Testing”, en bok som vänder sig till utvecklaren och beskriver varför kodens testbarhet ska vara det viktigaste principen och hur utvecklandet ska anpassas därefter. (Boken finns redan nu på LeanPub: https://leanpub.com/developer_testing)

Kursens upplägg är deltagardrivet och upplevelsebaserat enligt tekniker och metoder från “Training from the Back of the Room”. Det ska bli riktigt skoj då sådana kurser alltid blir mera interaktiva, deltagarna mera engagerade och kursdeltagarna (inte lärarna) placeras i centrum.

.

Artikel på TestZonen.se

För att ge exempel på hur det kan se ut när ett helt team äger och tar ansvar för kvalitet rekommenderar jag denna blogg på TestZonen från Alexander (som publicerades under konferensen TZ14): http://www.testzonen.se/?p=5424.

20140320_120930

.

.
Agil Testning & Den Agila Testaren
14-15 April, Stockholm

Vill du veta mera om kursen, och anmäla dig? Klicka här:
http://www.crisp.se/kurser/agil-testning-och-den-agila-testaren-14-15-april-2014

Vi har Early Bird rabatt fram till och med 28:e mars. Än finns det platser kvar så det är bara att hugga 🙂
.

Annons
h1

Är du skrockfull? Ny blogg belyser myter kring agil testning

onsdag, 19 december, 2012

I fredags var det premiär för en ny blogg som bryter isär och reder ut myter kring agile; ”Agila Myter BUSTED (och några bekräftade)”.

Mer specifikt så kommer de första 25 inläggen handla om myter kring agil testning.

Agila Myter BUSTED har som syfte att pröva intressanta och provocerande myter inom agile för att
1) undersöka ursprunget och
2) utvärdera, utforska, analysera och eventuellt avslöja myterna som BUSTED, eller i vissa fall – APPROVED.

Jag är en av författarna och i första inlägget genomlyser vi myten ”Alla agila testare måste vara tekniska”. Är den myten BUSTED eller APPROVED? Läs och se om du håller med om vår slutsats! Debatten hittills har varit intensiv och spännande. Haka på!

Snart dissekerar vi myt nummer 2; ”Regressionstester hinns inte med” (när vi jobbar agilt som t.ex. i Scrum). Busted eller Approved? Följ redan nu diskussionen på Twitter #agilamyter.

h1

Q: Automatisera tester i samma sprint?

måndag, 2 april, 2012

Att det är kämpigt och utmanande att implementera A-TDD och TDD skriver jag gärna under på. Att göra resan från en process där testning handlar om att kritisera kod efter att den är skriven till att bli ett verktyg för teamet (där testerna primärt tjänar till att stötta utveckling under tiden utveckling sker) kan både var bökig och omtumlande.

Framför allt måste man skruva ner tempot innan man kan skörda hyperproduktivitetens frukter och detta är inte alltid så lätt när trycket är högt att leverera maximalt just denna sprint. Och sprinten efter. Och sprinten efter den.

För en tid sedan fick jag följande mail på ämnet…

.


Hej Jimmy

[…] Jag har på jobbet kommit i liten het diskussion om (Sprintlängd och autotester) […]. Dvs att man måste få tillverkat automatiserade tester i samma sprint som utveckling sker i eller åtminstonde sprinten efter. […] Och då menar jag tester som Test Avd. tillverkar. Unittester antar jag du menade dev gör i sprinten tillsammans med utv. arbetet?

Vilken typ av projekt har du varit involverad i? Det kanske är svårare att applicera detta i avancerade system med få utvecklare, oklara krav och dagliga byggen, än i ett system för en myndighet tex med väldigt klara krav?

Finns det någon bra bok man kan läsa om detta?

Mvh
#####

.


Hej #####,

Min egen starka personliga åsikt är att man ska utveckla automatiserade tester för det man utvecklar i samma sprint som arbetet sker. Det gäller både utvecklarnas enhetstester och testarnas/kravställarnas automatiserade funktions- och acceptanstester.

Jag gillar skarpt David Evans syn på test och kod som summeras i citatet ”[Acceptance] Testing slows down development just as passangers slows down the bus – the speed of the bus is not the point!”. Målet med sprinten är alltid att leverera fungerande värdefull testad mjukvara. Hinner man inte åstadkomma detta under en sprint har teamet tagit på sig för många, alternativt för stora, User Stories.

.

Blir dock lite förvirrad över en sak du skriver. Finns det en separat testavdelning? Ett starkt agilt team består av all kompetens som behövs för att gå från idé till leverans. Detta inkluderar då kompetens som täcker programmering, testning, verksamhet, gränssnittsdesign, databasdesign, teknisk dokumentation, osv.

Jag har erfarenhet från både små och riktigt stora projekt. Jag håller såklart med om att utmaningarna och förutsättningarna är olika men jag tycker ambitionen ska vara densamma. Om ni är få utvecklare och tampas med otydliga krav så kommer tydliga krav ”tvingas” fram om ni försöker skriva automatiserade acceptanstester i samma sprint som jobbet sker. Jag menar, utvecklarna lyckas ju uppenbart klura ut vad de ska programmera, då borde testarna (om det nu är olika personer som kodar respektive skriver de automatiserade testerna) klara av att klura ut hur det ska testas. Om inte så finns det uppenbart diskussioner och informationsloopar som testarna inte är med i.

Genom att skriva de automatiserade testerna först i sprinten efter tappar man halva poängen med dem som jag ser det. Visst, man bygger på en regressionstestsvit som är automatiserad och upprepbar, men styrkan med testautomatisering är att det möjliggör TDD! Att skriva testerna innan och samtidigt som koden (genom TDD) förkortar feedbacklopparna, förenklar koden, gör systemet testvänligt och spar tid totalt (för att räkna upp några fördelar).

.

Jag kan ge tre boktips. Det finns säkert fler bra böcker men dessa har jag läst och tycker är bra:

1) Agile Testing (Lisa Crispin and Janet Gregory) – En riktigt bra bok som berättar på en konkret och praktiskt sätt hur man bygger upp en bra agil test strategi.

2) Lean-Agile Acceptance Test-Driven Development (Ken Pugh) – Också riktigt bra. Den beskriver hur man går tillväga för att driva designen framåt i ett projekt genom testning (istället för genom krav).

3) Test Driven Development: By Example (Kent Beck) – Berättar på ett mer teknisk plan hur man går tillväga och kommer gång med TDD.

.

Hoppas detta svar gav några idéer och upplägg på hur ni går vidare i diskussionerna.

Med Vänlig Hälsning
/Jimmy

.

h1

Rapport från TestZonen 2012

tisdag, 20 mars, 2012

I helgen gick TestZonen 2012 av stapeln, en konferans där test stog i focus, arrangerat av gruppen bakom TestZonen.se.

Det blev en eftermiddag och en förmiddag sprängd till bredden med spännande diskussioner, mini-seminarier och debatter kring test, testaren, kvalitet och testautomatisering. Och mycket mera.

Här kommer en rapport och summering av vad som hände och sades. En ganska lång sådan…

.

Bakom arrangemanget stod Bengt Augustsson, Jonas Hermansson och Jagannath Tammeleth, grundarna och drivkrafterna bakom TestZonen.se. Deltagarna var skribenter och inbjudna inom test-branchen från hela Sverige. Konferensen hölls på Högberga Gård på Lidingö strax utanför Stockholm.

.

Välkomstdrink och lunch

Allt inleddes kl 11 med välkomstdrink innan lunchen. Jonas, Bengt och Jagge hälsar alla välkomna. Alla uppmanades twittra med hashtaggen #tz2012 om tankar och kommentarer kring det som pågick runtomkring. Detta ledde till att diskussionerna kring lunchen upptas med av diskussioner kring Twitter och Twitter-appen.

 

.

Invigning

Efter lunchen samlades vi i konferenssalen och TestZonen2012 invigdes med ett pampigt intro i Star Wars anda samt presentationen av eftermiddagens agenda. Deltagarna genomskådade dock ganska snabbt att agendapunkterna ”Mätplan”, ”Fontproblematik för testplaner” och ”Pivottabell = Agilt?!” var bluff.

  

.

Seminarie: Säkerhet ur ett testperspektiv

Första passet hölls av Viktor Laszlo (Prolore). Han berättade om sin erfarenhet av säkerhetstestning  från 4 år på Microsoft. Det kom att mest handla om Microsoft Security Development Lifecycle och STRIDE. Buskapet var att om man tar hänsyn till STRIDE (Spoofing, Tempering, Repudiation, Information Disclosure, Denial of Service och Elevation of Privilige) i sin hotbild behöver man inte förstå de individuella hoten, man har ett gott och tryggt säkerhetsskydd ändå. Det var mycket intressant, konkret och väckte nog mångas intresse och nyfikenhet kring säkerhetstestning.

.

Diskussion: Test i framtiden?

Efter Viktor seminarie var det dags för det första diskussionspasset. TestZonen 2012 kom att genomsyras av just bra, intressanta väldigt givande diskussioner! Första ämnet var: Test i framtiden? När grupperna summerade sina diskussioner tillsammans efter ca 30 minuter var det en ganska varierad framtidsbild som målades upp, även om vissa saker återkom.

Exempel på trender som togs upp: Testare och testyrket tas på allt större allvar. Allt fler tydliga expertis områden inom test växer fram. Marknaden efterfrågar testgenerallister allt mer. Agile ställer allt större tekniska krav på testaren i teamet. Testning kommer allt mer att handla om kvalitetscoachning.

  

.

Diskussion: Dropbox har problem.

Hade man tvivlat på att fokuset för TestZonen 2012 var just diskussion och nätverkande var alla tvivel som bortblåsta vid det här laget. Nästa övning bestod i att vi skulle planera upp testning kring Dropbox som kallat in oss (dvs. The Super Test Squad). Vi delades återigen upp i grupper om vardera fem personer. Jag och Martin Karsberg fann dock att vi var de enda två i vår grupp. Det började bra med en vårt eget förtydligande av uppdraget. Men eftersom vi bara var två kunde vi inte riktigt luta oss tillbaka på gruppens kollektiva intelligens (eller ansvarstagande). Resultatet blev trots det en fin färglagd serie (och varsin öl som belöning).

.

Seminarie: Spotify – How we do QA

Kristian Karl (testchef Spotify) höll i konferensens andra seminarie under vilket han berättade om hur Spotify arbetade med kvalitet. Eller nja… Det blev mest en beskrivning av Model-Based Testing. Mycket bra introduktion till MBT dock! Vidare hann Kristian diskutera testautomatiserare kontra testutvecklare, gorillan i rummet, m.m. Detta blev kanske inte den bästa summeringen av passet men det var mycket inspirerande och ryktet säger att Kristian fick demo MBT i baren långt in på kvällen.

.

Diskussion: Testledarens egenskaper

Första dagen avslutades med ytterligare en diskussion. Denna gång skulle vi klura över vilka de fem viktigaste egenskaperna hos en testledare var. För att jag själv skulle få rätsida på frågeställningen fick jag förenkla det i mitt eget huvud att handla om icke-agila projekt (då det i agila team inte finns någon testledare utan teamet tillsammans tar ansvar för test och kvalitet). Hur som helst, efter att grupperna presenterat sina resultat valdes fem finalister till egenskaper ut: Kommunikativ, Kunnig inom test, Strukturerad, Social kompetens, och på delad femte plats Lyhörd/Frågvis.

.

Middag och Mingel

Efter en energifull eftermiddag fick alla en välbehövd (om än kort) paus på rummet innan kvällen fortlöpte med fördrink, middag och barhäng. Jag hade en fantastisk trevlig kväll där dagens ämnen fortsatte diskuteras och jag många nya kontakter knöts.

.

Tipspromenad i morgondiset

Morgontrött som jag är hoppade jag över frukosten. Hörde dock från alla andra att den var fantastisk. Vad gör man inte för att få snooza…

Well well. Efter utcheckning var det dags för tipspromenad. Frågorna handlade på ett eller annat sätt om TestZonen. Tror Jonas, Bengt och Jagge fick med sig idéer på hur siten kan utökas och förbättras så att de har att göra lång tid framöver.

Efter promenaden fick vi en välförtjänt fika 🙂

  

.

Seminarie: Tolv feta klanterier från ett drygt decennium av testautomatisering

Sista kunskapspasset hölls av Jörgen Damberg (Claremont). Jag vet att Jörgen hållt mycket låda tidigare, och det märktes. Han fick skickligt med pulbiken i en lättsam och skämtsam dragning som ändå var sprängfylld med visdomar och erfarenheter.

Jörgen hade också helt klart den absolut snyggaste agenda-sliden jag sett, go C64!

Top 3 klanterier var hur som helst:

#1 Det är bara att spela in och spela upp
#2 Sänkta servrar på grund av fel fel fel
#3 Vi har tusentals tester automatiserade – det räcker väl?

.

.

Open Space

Näst sist ut på agenden var Open Space. Ämnen samlades och grupperna spred ut sig i konferensanläggningen. Själv föreslog jag ämnet ”Visualisering av testplaner/testscope inkl. progress och status”. Vi blev ett stort gäng som diskuterade Mind Maps, teamets behov kontra rapporter, och mycket mera. En superbra och inspirerande diskussion.

I pausen till andra Open Space passet var jag tyvärr själv tvungen att avvika men jag föreställer mig att andra passet innehöll lika många spännande parallella diskussioner som första.

.

Avrundning & Summering

Bengt, Jonas och Jagge avrundar konferensen och priser till TestZonens skribenter delades ut. Jag var som sagt inte kvar hela resan ut men det tog hela helgen att smälta alla intryck, idéer, tankar och diskussioner, och jag håller nog fortfarande på att reda ut en del tankar som far runt.

Super tack till arrangörerna och super tack till alla deltagare! Detta blev en riktig toppenkonferens och jag hoppas innerligen att Jagge, Jonas och Bengt finner tid och energi att göra om det. Jag vill tillbaka!

Vi ses på TestZonen.se!

.

.

.

Twittrandet

Just ja, det pågick stundtals febrilt twittrande också. Kommentarer, skämt, reflektioner och parallella diskussioner varvades om vartannat. Kan föreställa mig att det måste varit svårt att följa om man inte var där.

Några favoriter från flödet:

‏@BengtAugustsson: Vem faan tog allt varmvatten? Säkert en testledare!!! Blev en kalldusch efter en varm dag. #tz2012

‏@TedLundqvist: Samtliga förväntningar på konferensen är uppfyllda och då är inte ens middagen och puben avklarad. #tz2012

@KristianGMadsen: 4 st av alla testautomatiserare (ca 15?) i lokalen på #TZ2012 säger sig kunna försörja sig som programmerare => annat skillset! #sådeså

Här hittar du alla tweetsen med #tz2012:
https://twitter.com/#!/search/realtime/%23tz2012

.

h1

SAST Q2 – Tema Agil Testning

torsdag, 21 april, 2011

Förra veckan gick konferensen SAST av stapeln. Temat för Q2 mötet var Agil Testning och det lockade fullt hus. Seminarierna var på en kanske all-time-high nivå, och SASTs provskott på Open Space blev en succé!

Frukostmingel på SAST Q2 2011

.

SAST Q2 var slutsålt flera veckor i förväg och likaså högg sponsorerna som hajar på de tillgängliga monterplatserna. Tyvärr lyckades inte Sogeti norpa sig en plats denna gång vilket jag såklart tycker var olyckligt eftersom jag är teamchef för ett nytt team på Sogeti med konsulter som är experter inom just agil testing och test automatisering. Jag gjorde hursomhelst mitt bästa för att delta i diskussioner och hålla Sogeti fanan högt.

Som jag nämnde var kvalitén på seminarier bättre än någonsin denna gång. Dels berodde det såklart på duktiga talare, men jag tror också det nya konceptet med att begränsa varje presentation till 20 minuter också gjorde att varje talare ansträngde sig lite extra för att göra sitt budskap så tydligt och kompakt som möjligt. Arrangörerna hade gjort ett riktigt bra jobb med logistik, mat och planering och ska också ha en rejäl eloge för att de vågade prova konceptet Open Space på SAST. Jag återkommer till detta lite längre ned.

Närvarande arrangörer presenterar sig.

.

Mini-seminarierna

Nästan alla 20 minuters mini-seminarier höll riktigt hög kvalitet. Som alltid är det något man är mindre intresserad av men jag vill fokusera på några som fångade min uppmärksamhet till fullo.

Måns Sandberg (bild ovan) från Adaptiv öppnar med att berätta om de agila värderingarna, om vad det betyder att vara agil, om samarbete och om faran med dogmer. Han var också den första talare som provocerat påstod att det finns utrymme i vissa branscher att i några år till fortsätta jobba långsamt och icke-agilt men vill man vara en del av framtiden och kunna matcha konkurrenter måste man lära sig att bemästra agil utveckling och agil testning. Själv tycker jag inte det finns något kontroversiellt i detta men jag tror nog att det fanns en del personer i publiken som kanske kände sig en smula provocerade och kritiserade av ett sådant påstående.

Ola Sundin från Ongame berättade om hur de jobbat med Modellbaserad testning, ett nytt angreppssätt för min del. Mycket intressant att höra på hur de jobbade med att genom modeller automatgenerera testfall och hitta nya infallsvinklar till testscenarier.

David Evans från SQS Nordic (bild höger) höll dock den presentation som jag tyckte var självklart bäst, sprängfylld med skarpa observationer och spännande insikter. Rubriken var ”Agility & Risk Challenges for your Agile QA Strategy” vilket han gjorde ett fantastisk jobb att leverera på 20 minuter. Titta gärna på hela hans seminarie (se länk nedan), men det var framförallt en slide jag föll för speciellt, och som jag flitigt kommer citera framöver – ”Agile Acceptance Testing slows down deveploment just as passangers slows down the bus. The speed of the bus is not the point.” Tycker dock inte alls att man behöver begränsa sig till acceptanstestning utan denna liknelse borde genomsyra synsättet på test generellt!

.

Open Space

Med start klockan 14 och fram till och med dagen avslutades med utvärderingar (a lá Sprint Retrospectives) provad SAST för första gången Open Space konceptet. I sju diskussions hörnor utspridda i lokalen pågick diskussioner och debatter. Varje hörna hade sitt i förväg bestämda ämne. Det diskuterades Definition of DONE, agila testverktyg, testautomatisering, agil kravhantering och mycket mycket mera. Vissa diskussioner slutade någon helt annan stans än där de började, vilket såklart är en bra sak när man kör OpenSpace. Vidare uppmanades alla att följa ”de två fötternas lag”, dvs. tappar du intresset för en diskussion sök dig till någon annan som intresserar dig mera. Detta ledde ytterligare till att höja kvalitén och intensiteten på de debatter som pågick.

Open Space pågår för fullt.

Dessa avslutande timmar blev min höjdpunkt av dagen och jag kan bara hoppas att arrangörerna gör detta till en stående punkt i agendan och kanske t.o.m. kör konceptet fullt ut framöver, dvs. låter deltagarna själva forma innehåll och rubriker för diskussionspassen.

Allt som allt, en riktig toppendag 🙂

.

Twitter och video

Under SAST Q2 twittrades det flitigt.
Läs twitterflödet här: http://sastq2.blogspot.com/

Mini-seminarierna sändes även live över bambuser.
Se inspelningarna här: http://bambuser.com/channel/SAST

.

Glad Påsk!

.

h1

Exploratory Heat Map

onsdag, 2 februari, 2011

Exploratory Heat Map – Tänk om teamet i en och samma rapport kunde se en snapshot över systemets hälsa, hur tillförlitlig snapshoten är, samt ge er vägledning om var ni bör lägga testenergin härnäst.

Förra veckan hade jag förmånen att få ta del av en Open Space kring Exploratory Testing på Extenda i Stockholm. Det blev en väldigt lyckad tillställning med ca 20 agila testare från flera olika företag. Väldigt roligt att möta kollegor i branschen och väldigt spännande diskussioner uppstod. Tack Linda Haglund för arrangerandet!

På vägen därifrån, och dagarna som följde, samlade jag mina tankar och började fundera…

.

Tänk om:

  • Hela teamet spenderar varje torsdagseftermiddag åt Exploratory Testing (ET). Under denna eftermiddag är alla testare (inklusive utvecklare, designer, osv). Varje testare kör 2 stycken ET-Sessions (på vardera 2 timmar).
  • ET-Charters plockas från en prioriterad ET-Charter Backlog.
  • När ET-sessionen är över skapar testaren i vanlig ordning en session rapport, rapporterar eventuella buggar och ser till att nya uppslag för ET-Charters kommer in i ET-Charter Backloggen.
  • Session rapporten innehåller (bland annat) info om vilka delar av systemet som primärt utsattes för utforskande testning och lagras i en databas med hjälp av ett verktyg (t.ex. genom konfigurering av JIRA).
  • Kontinuerligt uppdateras en karta över systemet som visar hur många defekter just nu finns rapporterade i varje del samt hur mycket ET-tid systemets olika beståndsdelar utsatts för.

Denna karta, denna Exploratory Heat Map, skulle ge en fantastisk översikt. Bilden ovan är ett exempel på hur en Exploratory Heat Map skulle kunna se ut.

.

Exploratory Heat Map

Diagrammet i bakgrunden representerar systemets olika delar. Huruvida man delar upp systemet i funktionella delar, moduler eller komponenter tror jag är mindre viktigt. Det viktiga är Defekter och ET-Session rapporter använder samma meta-data för klassificering. (Namngivning av delarna saknas i bilden ovan.)

Cirklarnas storlek representerar hur mycket exploratory test tid som delen blivit utsatt för och färgen antalet just nu öppna rapporterade buggar.

Kartan berättar dels hur systemet mår just nu, men också hur vi ska prioritera Exploratory Testing Charter Backloggen inför nästa Exploratory Torsdag. Varje dag kommer kartan förändras. Allteftersom buggar fixas kommer de röda färgerna blekna. Beroende på vilka ET-Charters som körs kommer vissa cirklar krympa medans andra växer.

.

Verktygsstöd?

Självklart går en dylik karta inte att underhålla genom att manuellt uppdatera en powerpoint varje dag utan det behövs ett bra verktygsstöd. Antingen skriver man ett eget verktyg som integrerar med det befintligt defect tracking system, eller så bygger man en egen plug-in till det verktyg man redan använder, vilket t.ex. är möjligt man kör JIRA GreenHopper. Och då skulle det kanske kunna se ut såhär:

.

Skulle det funka?

Tankar och reflektioner? Hur värdefull och användbar vore en Exploratory Heat Map för er i ert team? Behövs återkommande ETT (Exploratory Testing Torsdagar) eller ”duger” något annat lika bra som bas för test täcknings input?

Är det någon som idag gör någonting liknande?

.

.

Är du intresserad av att jobba med agil testning som konsult Sogeti? I Stockholm finns sedan första januari ett nytt team – Team Agil Testning & Automatisering. Kolla in vår annons på monster.se!

h1

Press stopp: Nytt Sogeti-team – Agil testning och Testautomatisering

tisdag, 16 november, 2010

Från och med första januari 2011 finns ett nytt Sogeti-team i Stockholm: Agil testning och Testautomatisering. Undertecknad är tillförordnad teamchef. Känns sjukt spännande och utmanande, men också läskigt och nervöst.

Som en del i Sogeti Stockholms omorganisation har några nya team uppstått, ett av dem är teamet ”Agil testning och testautomatisering”. Vi (dvs. Sogeti) upplever ett starkt växande behov av skickliga testare som har erfarenhet av agila testekniker och testautomatisering hos våra kunder. Detta behov har bokstavligt talat exploderat den senaste tiden i takt med att allt fler går över till att driva projekt enligt Scrum, Kanban eller annan agil utvecklings- och leveransprocess. Något de flesta snart upplever är just stora utmaningar kring testning och kvalitet. Det är här Sogeti kan hjälpa till och bidra.

Teamet kommer inledningsvis att bestå av 15 till 25 stycken agila testare och testautomatiseringsexperter. Då det officiella startskottet för teamet är 1:a januari 2011 så kommer inte teamets medlemmar och storlek vara helt bestämt förrän om några veckor.

.

Sökes: Agila testare

Detta hindrar oss dock inte att redan nu söka efter dig som har en brinnande passion för agila utvecklingsmetoder och agil testning och är intresserad av att jobba som konsult i spännande och utmanande uppdrag med test och/eller testautomatisering.

Så om du har universitets- eller högskoleexamen och erfarenhet av agila testmetoder och agila testtekniker, eller test- automatisering, så kolla in jobbannonsen på monster eller www.sogeti.se!

.

Hjälp! Jag är chef…

Undertecknad kommer bli teamchef för detta nya team. Detta känns självklart superskoj att få förtroende och uppdraget att leda denna nya riktade satsning inom agil testning. Samtidigt känns det läskigt och lite nervöst då jag aldrig tidigare haft personalansvar eller resultatansvar för en enhet. Vidare, är branchen redo för en chef med mohikan och som gillar att blåsa i röda saxofoner?

Hur som helst, vissa möjligheter får man bara inte låta passera.

Vidare har jag en ambition att leda och driva teamet med de agila värderingarna som bas. Vad detta betyder konkret eller hur det realiseras har jag faktiskt ingen aning om i skrivande stund. Fast just det ser jag inte som något problem, snarare en möjlighet att praktisera ”Collective Ownership” och bjuda in hela teamet till att forma hur vi ska jobba tillsammans. Nu kommer ju teamet inte agera som ett tight Scrum team i ett och samma projekt, vi blir snarare en grupp individer som tillhör samma organisatoriska resultatenhet inom företaget. Med andra ord kommer inte alla agila principer vara betydelsefulla (eller meningsfull) i vårt kontext men som jag ser det måste man leva som man lär – förekommer ordet ”Agil” i teamets namn ska de agila värderingar också genomsyra hur teamet fungerar och arbetar!

.

2010 har varit mitt mest spännande år hittills genom min yrkeskarriär men nu börjar jag misstänka att 2011 kommer klå det med hästlängder. Jag har bara en sak att säga: Bring it on! 🙂

.

h1

En Scrumkurs-ledares reflektioner

torsdag, 4 november, 2010

Förra veckan var jag inbjuden till Sogeti Umeå för att leda en Scrum-kurs med speciellt fokus på agil testning. Jag vet inte varför men jag fick med mig hem långt fler idéer på hur jag kan ändra upplägg och anpassa innehållet än jag brukar. Riktigt skoj!

Kursen gick av stapeln på Folkets hus i Umeå. Riktigt bra lokaler! Enligt utsaga även prisbelönta. Fjärrkontrollen var bland det värsta jag sett, den kunde styra allt inom 20 meters radie. Gruppen var väldigt varierad på så sätt att hälften var Sogeti-kollegor och andra hälften var kunder. Detta, samt att tidigare erfarenheter av agila utvecklingsmetoder var väldigt olika, gjorde att diskussionerna och övningarna blev riktigt bra, intressanta, breda och djupa.

Dock antagligen för få och för korta till antalet…

Jag har nämligen ett problem – varje kurs eller seminarie jag håller så lyckas jag aldrig riktigt få tiden att räcka till. Alls. Jag vill hinna berätta allt jag upplever är viktigt. Jag vill hinna med vissa övningar som jag tycker är effektiva på att exemplifiera agila värdering. Vidare  tycker jag det är roligt att berätta om Scrum, XP, Lean, Agil testning, Continuous Integration, TDD, Defect Proofing, Technical Debt, storskaliga Scrum-projekt, osv. Samtidigt vill jag ju att alla ska få sina förväntningar uppfyllda, fått svar på sina frågor och tycker att innehållet är värdefullt.

Nu, x antal kurser senare, har jag en idé på hur jag ska göra nästa gång för att både få tiden att räcka till och för att fler ska uppleva att de fått sina förväntningar uppfyllda och svar på specifika frågor. Det här borde ju egentligen vara en no-brainer för någon som dagligen jobbar med agil utveckling och föreläser om leans principer och toeri.

Svaret? Enkelt; ”Less is more”.

Nästa gång ska jag försöka halvera antalet slides jag ska hinna igenom under 2 x 8 timmar (minus tiden för övningar). Att jag i dagsläget har cirka 350 slides för två dagar kanske avslöjar min nuvarande taktik…

Genom att helt enkelt halvera innehållet så kommer det finnas gott om tid att fördjupa sig i frågor och diskusser som gruppen upplever är intressanta och viktiga. Win – Win!

Fast å andra sidan kanske jag inte ska vara för hård mot mig själv. Något gör jag rätt för övnings-scrum-projektet går bättre och bättre varje gång. Spelen blir bättre och bättre och grupperna blir allt bättre och bättre på att praktisera Scrum under övningens extrema omständigheter.

.

En extra rolig grej är också att kursen blev omnämd på InfoTech Umeås hemsida. InfoTech Umeå är en strategisk satsning för att marknadsföra och utveckla IT inom regionen.

Läs nyhetsartikeln här:
http://www.infotechumea.se/battre-metoder-for-projektstyrning

h1

Fel, fel, fel!

måndag, 28 juni, 2010

Under Agila Sverige 2010 höll Joakim Ohlrogge från Agical ett mycket uppskattat blixttal som handlar om hur vi ser på fel och hur vi hanterar dem. Titeln för blixttalen var ”Fel, fel, fel!”.

Mot slutet av sin presentation argumenterar han för att vi kanske borde betrakta och hantera fel och testning på ett radikalt annorlunda sätt…

Det hölls många intressanta, insiktsfulla och lärorika blixttal under Agila Sverige 2010. Jag var inte där själv men har fått möjlighet att kika igenom dem alla på video efteråt.

Joakims tal fokuserar kring fel, hur vi betraktar dem och hur vi hanterar dem. Dels har vi antalet fel, dels har varje fel en ”allvarlighetsgrad”. Bilden blir dock inte komplett om vi inte dessutom tar hänsyn till hur lång tid felet existerar. En litet fel som existerar under en lång tid kan göra större skada än ett kortvarigt allvarligt fel. Det riskerar sluta i irritaion, frustration, färre användare, färre sålda produkter, osv. Med andra ord…

Felyta = allvarlighet x tid.
Den totala felytan kan då minskas på tre olika sätt:

  1. ”Släppa igenom” färre fel (minskar antalet fel)
  2. ”Släppa igenom” mindre allvarliga fel (minskar allvarligheten)
  3. Reagera på och hantera fel så fort som möjligt (minskar tiden)

Han argumenterar för att om vi kan agera snabbt och reparera fel fort kanske vi inte behöver vara lika rädda för att ”släppa igenom” fel. Även om felet är allvarligt blir felytan liten om felen bara existerar en kort stund.

Felytan för ett mindre allvarligt fel kan vara större än för ett kritiskt…

.

Konsekvens = Ingen testning?

Om man godtar felyta som vårt mätetal och som en mer sann beskrivning (för systemets kvalité ur ett defekt-perspektiv) fullt ut får det stora konsekvenser för vår testprocess.

Att minska antalet fel som slinker igenom och felens allvarlighet med en allt rigorösare testprocess är både kostsamt och tidskrävande, och gör dessutom inget för att dra ner livslängden på de fel som faktiskt hittas. Det kan till och med vara kontraproduktivt, en tung testprocess kan göra så att våra fel lever längre innan de blir åtgärdade.

Om vi istället fokuserar på processen (dvs. att höja kvalitén genom test driven development, par programmering, continuous integration, m.m.) och att möjliggöra snabba fixar (genom t.ex. defensiv programmering, defect proofing, rigorös loggning, etc.) samt att stöda snabba deployer av nya versioner som metoder för att minska felytan kan detta visa sig vara både betydligt effektivare och betydligt billigare.

Kan det vara så att det absolut effektivaste är att inte ha något testning alls? Hmm…

.


Joakim Ohlrogge är konsult på Agical AB.
Hans blogg heter ”The Point is Missed”.

.

.

Videoupptagningar från Agila Sverige 2010 hittar du här:
http://www.webbtv.nu/5557.htm

För att se ”Fel, fel, fel!” klicka på ”Celsius 20100510”.
När videon väl har laddats klicka på sista passet ”Fel, fel, fel!”.

h1

Agil Testning och Molnbaserad Testning starkast trender inom kvalitetssäkring

torsdag, 17 juni, 2010

World Quality Report 2010-2011, en rapport som publicerades igår av Capgemini och HP bekräftade något som jag redan betraktade som ”kunskap” efter vad jag sett, hört, erfarit och upplevt i mitt kontaktnätverk på Sogeti och ute hos kunder, nämligen att fokuset kring Agil Testning, men även molnbaserade testtjänster, snabbt växer i mjukvaruutvecklingsbranchen.

I Sogetis pressmeddelande kan man läsa ett utdrag från rapporten:

”…kraven ökar, på både utvecklare och testare, för att skapa större effektivitet, konsekvent använda kvalitetssäkringsmetoder och öka återanvändningen av testautomatisering. Därför använder organisationer sig av allt mer agila och molnbaserade leveransmetoder för att modernisera sina applikationer.”

Man kan vidare läsa:

”Då kraven på IT-leveranser förändras, visar rapporten att även kraven på kvalitetssäkring ökar i betydelser. Morgondagens testare kommer att arbeta i mindre team som förväntas leverera användbar kod inom fyra till sex veckor. Korta deadlines och mindre team kommer sannolikt att leda till en framtid där prioriteringen av kompetensen i kvalitetssäkrings- och testteam kommer att förändrad.”

Den nya Agila Testaren?

.

Vidare presenteras också vad företag upplever som de största fördelarna med agil utveckling. Sådan statistik tycker jag alltid är spännande och intressant.

Detta är bara ytterligare en bekräftelse på att agila metoder vinner mark och att branchen kommit långt i en övergång till agila utvecklingsmetoder. Läs mer om de agila metodernas framfart i denna artikel.


Ladda hem rapporten i sin helhet här från Capgeminis hemsida. Kräver dock registrering.