torsdag den 5. maj 2016

STAReast 2016 - Onsdagens Oplevelser

Så blev det tredje dagen på STAReast-konferencen, og dermed en dag med mange flere forskellige indtryk og oplevelser. Hvor mandagen og tirsdagen har været fyldt med halvdags tutorials, så er det om onsdagen, at der er track sessions. Ved track sesions kører der 6 parallelle faglige præsentationer og 3 tekniske præsentationer (sponsorerne) - så der skal tilvælges og fravælges. Udover dette kører der også nogle generelle sessioner kaldet Keynotes.

Morgenen startede med, at Lee Copeland officielt åbnede konferencen, og introducerede den første keynote.

Den første keynote var over emnet 'Lessons Learned in (Selling) Software Testing' med Keith Klain. Han havde skiftet fra 'køber' til 'sælger' siden, og det var spændende (og underholdende) at høre hans syn og oplevelser fra den vinkel. Han havde et par gode budskaber: Fokuser på den forretningsmæssige værdi af test over for ledelsen, og ikke om selve test. Tal ikke om test, men om hvad det giver - altså resultatet, men i forretningsmæssige termer. Han havde også et lille indspark til testmanagere - i skal være 80% 'hands on' med hensyn til testen, gem jer ikke bag skærmen og møder - vær synlige og aktive. Og hvis man lægger op til fri diskussion, så accepter at der kan (og vil) være forskellige synspunkter, og tag dette seriøst (var det et lille indspark i forhold til enkelte individer i den context drevne verden - hvad ved jeg?). Totalt set en god start på morgenen.

Onsdagens anden keynote var 'Open Source Test Automation - Riding the Second Wave' med David Dang. Det lykkedes ham at gøre et måske lidt nørdet emne spændende - ved hjælp af lidt selvironi og humor. Den første bølge af open source test automation omfattede værktøjer som Fitnesse, Ruby/Watir og Selenium RC, og han viste nogle eksempler på, hvorfor det kun var en delvis succes, og så lavede han et flot skifte over mod den anden bølge, som omfattede: Selenium WebDriver, Cucumber (BDD), Robot Framework med key-word driven automatisering, som nogle af dem han nævnte. Han omtalte følgende årsager til, at disse blev mere populære: Bedre support (også fra store veletablerede virksomheder og organisationer), bedre API, bedre integrationer, mindre instrumentering kræves, support af populære metoder som f.eks. BDD. Samlet set - et nørdet emne gjort spændende.

Han henviste til følgende hjemmeside: www.opensourcetesting.org

Så begyndte de forskellige track sessions, og som før nævnt, dermed også en masse valg - til og fra.

Den første track session jeg valgte var 'Helpful Practices in Agile Testing' med Jeroen Mengerink. Hans udgangspunkt var det aktuelle for mange organisationer - et skifte fra de sekventielle udviklingsmodeller til agil udvikling. Han havde mange guldkorn, og her kommer et af dem: 'Hvis man vil arbejde struktureret med agile, må man lære den strukturerede teknikker, herunder testteknikkerne'.

Grundlæggende var hans tese, at agil test drejer sig også om mere bløde værdier i form af tættere samarbejde, tekniske emner som drivere og stubbe og vidensdeling indenfor test på tværs af teams og indenfor teamet på tværs af roller. Han lagde meget vægt på de bløde værdier og teamudvikling.

Han brugte bl.a. den efterhånden kendte model: FORMING - STORMING - NORMING - PERFORMING. En god referencemodel til illustration af, hvad der sker i teamet ved ændring i sammensætningen:
  • Forming: lærer om hinanden
  • Storming: udfordrer hinanden
  • Norming: arbejder med hinanden
  • Performing: arbejder som EN.
Det der er ideen her er, at man principielt starter forfra ved en ændring af teamets sammensætning - så pas på. Han omtalte også en visualisering af målet som en god ide - uden at visualisere dette yderligere!  Men når vi som testere deltager i et agilt team, hvad vi så bidrage med - udover at teste. Vi kan introducere testteknikker til udviklerne, vi kan udfordre designet og forretningsanalysen med WHAT-IF scenarier og udfordre Product Owner på, hvilke test der skal udføres.

Jeroens udgangspunkt var også, at mange at de discipliner der ellers anvendes, og bør anvendes ved agil udvikling og test. På området teststrategi/testfremgangsmåden var det emner som HVAD og HVORNÅR vi tester, få test integreret som del af udviklingen, der testes i alle sprints, og ikke mindst: tillad afvigelser til strategien - få defineret den tilladte båndbredde. Den tilladte båndbredde kunne typisk påvirkes af risikoen, modenheden, færdigheder, produktet/systemet, størrelsen, tid og kulturen. Dette var en rigtig spændende betragtning, og viser noget om den ønskede fleksibilitet som man ofte ønsker sig. Hans budskab var klart - tag stilling på forhånd. Jeroen gjorde sig også til talsmand for brug af forskellige testniveauer - men med respekt for noget af det grundlæggende i agil udvikling - vi stoler på hinanden - så vi skal ikke gentage en test, hvis det er gennemført før.

Anvendelsen af PRA (ProduktRisikoAnalyse) blev også omtalt, og gerne på flere niveauer: End-2-end, release og user story. Han sluttede af med at pointere, at omkring end-2-end test er det vigtigt at huske, at det er bredere end sprintet og, sandsynligvis også, teamet. Et godt indlæg, som klart 'skar ud' af den store agile kage, hvad der er vigtigt.

Den anden track session jeg deltog i var 'Ensuring Maximum Quality in the Era of IoT and Wearables' af Gauri Arondekar. Mit udgangspunkt var, at emnet er spændende - også set i lyset af en af de tutorials jeg deltog i tidligere på ugen. Gauri startede med en hurtig opsummering af, hvad IoT drejer sig om, men kom desværre hurtigt til at dreje sig om et konkret værktøj (som hendes virksomhed pudsigt nok også havde udviklet og solgte - stor overraskelse, og stor skuffelse).

Men der var dog enkelte generelle guldkort i forhold til test af IoT og Wearables. Hun kom ind på en række udfordringer der typisk er for test på dette område: testinfrastrukturen (miljø, stubbe, drivere, data m.m. - som alt sammen er en forudsætningen for teste), prioritering af testen (anvendelse af risikobaseret test eller anden form for udvælgelse af test, integrationer (seamless integration mellem ofte meget forskellige teknologier) og skalering (løsningerne er forskellige og load kan være meget forskellig).

Hun sluttede af med et godt statement ved test af IoT og Wearables - opbyg en kultur hvor der testes 'as a user'. Nok en meget god pointe.

Dagens tredje track session for mig var 'The Road to DevOps - Data, Environment and Test Automation' med Tanya Kravtsov. Hun startede med at definere DevOps som:
  • Culture
  • Automation
  • Monitoring
  • Sharing.
Ordet automatisering indgik ekstremt meget i indlægget, og hun sluttede af med at sige, at med DevOps kunne man opnå 50 builds om dagen, fuldt testet og produktionsklar. Det var spændende og lærerigt, MEN jeg er nok lidt skeptisk over hendes generelle tilgang til al ting - som tester er man nok lidt skeptisk når det ser for godt ud.

MEN hun lagde ud med nogle gode tanker om 'identify bottlenecks' i relation til miljøer, testcyklusser og de manuelle processer. Hun omtalte de kendte teknikker til det: brainstorming, mind maps, interviews og retrospectives, men omtalte også Speed Boat Game, hvor der man forsøger at identificere de ankre der holder os tilbage - spændende betragtning, og jeg kan ikke lige huske, at jeg har set den tidligere præsenteret på den måde og med det navn. Og da jeg elsker at sejle, er det nok en jeg vil afprøve fremover.

Onsdagen sluttede af med 'Lightning Strikes the Keynotes' - hvor der kommer en række indlægsholdere op i 5 minutter, og præsenterer et emne - som sædvanligt både sjovt og interessant.

2 kommentarer:

  1. 'Helpful Practices in Agile Testing'
    Spændende læsning, kan relatere mig til meget af det, da jeg selv har haft den spændende opgave at være testansvarlig for et firmas transformation fra traditionel udvikling til agil udvikling.
    FORMING - STORMING - NORMING - PERFORMING - gav faktisk et rigtig godt billede af nogle af de udfordringer man står overfor på personalesiden, det kræver en del at få "sådan plejer vi at gøre" væk fra medarbejdernes mindset

    SvarSlet
  2. Enig i dine betragtninger. Modellen FORMING - STORMING - NORMING - PERFORMING er ganske anvendelig, men det er ikke en statisk tilstand. Når/Hvis der sker ændringer i teamets sammensætning starter man 'forfra'.

    SvarSlet