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: 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”