Users Come First
Det går inte att missa budskapet kring UX och API-design, att vi ska ställa oss frågan varför och vad innan vi går in på hur. Hur ser målgruppen ut och vad vill användaren ha?

”Design is the competivtive advantage, the question entrepreneurs and investors have to answer is no longer “can this be built and by who?” but, “should this be built and for who?”

DevOps, DevSec, DevTest…
Vi lämnar våra traditionella roller och avdelningar. Alla kompetenser, roller och områden närmar sig varandra och vi jobbar som bäst tillsammans och tar ansvar för helheten. Det innebär att vi skapar en miljö och kultur för att kunna tänka på alla delar i utvecklingprocessen och få kvalitet i arbetet. Nya roller skapas för att stötta i arbetet.

Agile
Det här året flyttades fokus från principerna Scrum och Kanban till hur man kan tänka Agile i större utsträckning i hela verksamheten. Hur gör man en upphandling och skriver avtal utan tydliga leverabler som ex. tid och scope? Och hur arbetar man med kompetens och distribuerade team utan tunga processer? Det märks också att man flyttar agile upp en nivå till affärsområdet där projektportföljen och organisationen bli en mer naturlig del. Agile inom testing är också hett och det är tydligt att resan, lärandet och de unika behoven är viktigare än målet oavsett om ämnet är utveckling eller testning.

Säkerhet
Nya mobila enheter öppnar upp för nya typer av säkerhetshot. Vi behöver bli bättre på att förstå de nya sårbarheterna och skapa strategier för ”Platform security” som berör både iOS och Android . Även applikationssäkerhet och säkerhettestning flyttar fram sina gränser för vad som är möjligt när vi går ifrån backend och använder oss mer av klientsidan med ex. javascript som tolkas av browsern. Vi behöver ställa krav på att hitta och utveckla fler färdiga ramverk som ger oss stöd i det arbetet.

Talare: Shuel Gershon, Experience report on Exploratory testing and leadership

Det märks att ämnet test är hett och att man börjar få upp intresset för testning i en agil miljö. Det beror mycket på att man ser fördelar i kvaliteten när testning blir en del av utvecklingen istället för att traditionellt ha ett utvecklingsteam, en testare eller ett testteam. Liksom tidigare talare David Evans(agile testning) så pratar även Shuel om hur man kan väva in testning i utvecklingsprocessen.

Här kommer några råd som vi kan ta med oss på resan
* Testning är en resa! Planera inte i detalj vad som ska göras vid testning, hitta istället guidelines utifrån arbetssätten i teamen.
* Exploatory testing based- Utforska snarare än att sätta hårda krav
* Personal view of system – Aktuell status, hur upplever vi våra system och vad vet vi om dem?
* Berätta din egen ”quality story” – Spåra och simulera mekanismen, finns brister och flaskhalsar?
* Undvik en person som har rollen som testare, kvalitet och testning har alla i teamen ansvar för
* Investigate, lär, undervisa, analysera rapport(notes, bugs, questions)

För att lyckas med det som Shuel sammanfattar som ”Test management” behöver vi flytta fokus och arbetet från testrollen och över till teamen.

* Skapa en failsafe miljö, visulalisera data och problemen (Sonar) och följ upp med testrapporter
* Designa teamen utifrån tänket att alla har ansvar för test och kvalitet
* Optimera kvalitet – som utvecklare har man bättre förutsättningar än som testare att påverka kvaliteten

Känns verkligen som vi är på rätt väg! Det påminner mig om att vi behöver fortsätta utifrån vår workshop med tänket att automatisera det som är möjligt i våra miljöer och experimentera mer för att hitta ett sätt som passar oss utifrån olika behov i teamen och vår utvecklingsprocess.

En konkret sak vi kan börja med i alla team är att avsätta tid och få in test i en sprint. Vi gör testning redan idag men på lite olika vis. Syftet är att vi lär oss mer för varje review och kan resonera och samla kunskap kontinuerligt.

Testning: ”Ett ostört moment i sprinten av analys, review och testförsök”

Talare: Dan North, keynote

Ett återkommande ämne oavsett spår tycks vara ovisshet och osäkerhet. I dagens keynote fördjupar dig Dan inom ämnet och uppmanar oss att prata mer om magkänslan och det vi känner oss osäkra kring.

Han menar på att ”Fear leeds to risk” och ”Process leads to hate”. Ett vanligt problem är att om det inte finns utrymme och går att hantera ovisshet så väljer man som person och team hellre att misslyckas. Det kan man styra över.

Budskapet är att vi ska försöka att förstå osäkerheten, vad består magont av och hur sannolikt är det att det inträffar?

Vi bör omfamna osäkerheten kring olika områden:

* Scope
* Teknik
* Ansträngning

Det går att göra val utifrån en modell för osäkerhet
* options have value, att ta ett beslut har ett värde i sig självt
* options expire, beroende på när jag gör valet får det olika effekter
* commit deliberately

Det går inte att förutse allt och osäkerhet är naturligt. Vi behöver bara bli bättre på att prata om det.

Note to self: Just nu är jag osäker på om alla som inte var där och som läser det här förstår vad jag menar. Vad är sannolikheten för det?

”Never commit early unless you know why and expect the unexpectable”

Keynote Alexis Ohanian
Gårdagens keynote handlade åter igen om det heta ämnet User Expirience och tänket ”Users Come First”

Idag står Agile, Test och UX på min agenda. Jag tänker också utmana mig inom något område som jag inte har kunskap om. Exakt vad har jag inte kommit fram till ännu då det finns så många spännande spår. Dags att pringa vidare…..

Talare: David Evans (Quality testing agile coach)

I sitt arbete som Quality testing agile coach har David uppmärksammat mönster som visar på att man får utmaningar med testning i stora företag där man har problem i orgnisationen och på avdelningar. Ett sätt att skapa bra förutsättningar för att arbeta med testning är en bra miljö och kultur för att hantera när fel uppstår och att det är något positivt som går att hantera och lösa.

* Granska utifrån olika perspektiv – explore
* Prova nya saker – utmana oss
* Lär från misstag – lärande

Varför ska man testa?
* Genomgång av ”The agile testing quadrants” (Brian Marick diagram)
* Hitta testerna som supportar teamets arbetssätt
* Mer testing förbättrar inte kvaliteten. Man måste förstå vad som inträffat och agera på den informationen. Ta hand om problemet och skapa en plan för det man finner i sina tester.
* Testa på rätt nivå.

Tips på vägen
* Vad behöver vi skriva och vad ska vi bygga för att kunna testa. TDD
* Lär dig det som är användbart
* En felrapport är bara en uppfattning, stakeholders tar beslut och prioriterar.
* En defekt är ett tecken på att det inte finns ett test.
* End to end testing är överskattat.
* Varning: TDD gör utvecklingen mer långsam! Tänk på att hastigheten inte är det viktiga, det är vad vi fyller den.
* Alla kan testa, testare är våra vänner
* Det viktiga är hur vi gör våra tester, inte hur vi är som testare.

Jag tycker vi har många bra idéer om hur vi kan väva in testning i teamen och vår utvecklingsprocess. Vi fortsätter prova nya sätt och utmanar oss inom området och det lär vi oss mycket på.

”Testing is never finished, it is only ever stopped”

Talare: Chris Pattersson

Chris satte fokus på grundläggande processer och verktyg utan någon större djupdykning och analys av ämnet. Frågan var, hur ska man tänka i utvecklingsprocessen?

Vi fick en övergripande genomgång av grunderna för design, process, genomförande, underhåll och verktyg. Ledorden var mockups, automatiserade tester och automatiserad deployment.

• Enkla Mockups med fokus på idén och design av funktionaliuteten inte grafiken.
• Avoid abstraction – undvik förvirring och fokusera på rätt saker
• Names matters – sätt namn som alla förstår på classer, metoder och argument. minimera dokumentationen
• Composition – skapa återanvändbara komponenter
• Reuse – hög kvalitet gör att vi kan återanvända komponeneter
• Measurement – mät, logga och analysera
• Automatiserade tester
• Autodeployment till dev
• Lär dig olika språk
• Utbilda andra

Talare: Michael Nygard

Michael berättar om flera projekt där han varit delaktig både som applikationsutvecklare och systemarkitekt i ett operationsteam och där man stött på stora problem som utmanat organisationen och avdelningarnas samarbeten. Han berättar om fördelarna och vikten av att arbeta närmare varandra i vardagen. Att tillsammans nå över gränserna är nyckeln i stora organisationer.

 Att tänka på i samarbetet
– Extra hw löser ofta inte problemet(prestanda), spara kostnader
– Kombinera kunskap om utveckling, backend och operation
– Prata ett konkret språk: nätverk, protokoll, paket, xml, etc. samarbeta över gränserna och delad förståelse för problemet

 Organization Design
Designa organisationen på samma sätt som ett system. Det skapar en syn och process för hur man arbetar i framtiden med förvaltningen. Vi bygger samtidigt organisationen som ska underhålla applikationen. Det arbetet görs inte i en sprint, det är en Marathon…

Jag tänker Superteamet, gör ni också det? Vi samarbetar, hittar, visualiserar, analyserar och hantera problem och buggar på olika sätt och nivåer utifrån flera kompetenser.

Finns det fler sätt vi kan arbeta närmare varandra på i Superteamet? Kanske ha en gemensam backlog och mer delaktighet i alla ärenden så att vi får förutsättningar att arbeta mer tillsammans med samma saker?

Michel reflekterade också över vad gick rätt i projekten även där projekten havererat. Punkterna nedan är från Michel men sammanfattar Superteamet på ett mycket bra sätt.

– Vi använder Kanban för hantering av incidenter, det ökar transparensen
– Vi delar information, verktyg och kunskap
– Vi hanterar snabba förändringar
– Vi gör heroiska insatser – utsätter oss för stora utmaningar dagligen

”Dev + Ops = DevOps (IT operations och application developer in collaboration)”

Talare: Jon Skeet

Om konsten att tala och kommunicera om kod utan kod. Underhållande session där Jon delade med sig om hur han som person och utvecklare (pedant och ibland nitisk) försöker  kommunicerar på ett trevligt sätt. Hur kan man vara uppriktig och tydlig utan att vara otrevlig?

1) Var snäll, tänk på kunskapsnivån hos de utvecklare du talar med och sätt dig in i personens situation (annars vill de inte tala med dig)

2) Linda in budskapet något genom att vara medveten om detaljerna när du berättar hela bilden.Tala på rätt nivå om rätt saker.

3) Både i tal och skrift, tonen och presentationen. Konkreta detaljer väcker starka känslor, information på övergripande nivå skapar förståelse.