Talentum testkonferens

I början av veckan deltog jag på testkonferens i Stockholm arrangerad av NFI/Talentum. Konferensen bjöd på ett antal föreläsningar främst inom områdena agil test och testautomatisering. I slutet av konferensen samlades tiotalet deltagare i en workshop om testautomatisering. Denna workshop lotsades av Jonas Hermansson med sedvanlig säker hand och det var synd att inte flera personer deltog då det bjöds på många bra insikter och aha-upplevelser. Här är några punkter som jag tar med mig...

• Automatiseringskod är lika viktig som resten av kodbasen och ska versionshanteras och förvaltas på samma sätt av samma organisation.
• Automatiserade testfall är en del av förvaltningsobjektet och bör ligga hos berörd förvaltningsorganisation.
• Det är viktigt med en välgenomtänkt arkitektur och lämpliga abstraktionsnivåer för att inte bygga fast sig.
• Ett lämpligt automatiseringteam består av utvecklare som kan systemet, testare som kan domänen och en expert som kan automatisering.
• Börja enkelt med sånt som ger stor effekt, samt kan återanvändas och ge vinster för de manuella testerna.
• Man tjänar inte pengar på testautomatisering men däremot frigörs resurser för komplex manuell testning samt att man kan hålla ett högre releasetempo.

Insikter om ISTQB

Det går en skiljelinje idag mellan de testare som förespråkar traditionell testning och de som föredrar kontextdriven testning. Mitt i skottlinjen ligger ISTQB-certifikaten, som många av oss testare har och många organisationer efterfrågar. ISTQB-certifikaten har blivit en de-facto standard för testarbetet men det förenklade och smula dogmatiska innehållet gör att det ifrågasätts, främst av den kontextdrivna skolan. Eftersom det var ganska länge sen som jag tog min certifiering så satte jag mig ner för att fräscha upp minnet om vad ISQTB-syllabus verkligen innehåller.

Jag håller med om att ISTQB är skriven med ett genomgående självsäkert tonfall som får innehållet av verka mer vedertaget än vad som är fallet. Det är en teoretisering av samma typ man lär sig i skolan innan man förstår att den verkliga världen är mer komplex än vad lektionerna ger utrymme för. Det som jag tycker är mest graverande är dock tyngdpunkten vid traditionell testning och obskyra standarder. Många testare är påväg ifrån sådana begränsningar och om ISTQB ska vara relevant så borde man lämna utrymme även för kontextdrivna förhållningssätt.

Lite fler tveksamheter följer här:

• ISTQB gör ett stor nummer av skillnaden mellan "error", "defect", "fault", "failure" och "bug". Jag har aldrig förstått varför alla dessa distinktioner och nöjer mig med Rob Sabourins definition "To make our job more fun, whenever we have a concern with software, we call it a "bug".
• Att dela upp testarbetet i fem olika faser, varav en innehåller faktiskt testgenomförande till hälften, är inte bara vattenfall utan nedgradering av testarens viktigaste arbetsuppgift till förmån för administration. ISTQB's testprocess definieras såsom (planning and control, analysis and design, implementation and execution, evaluating exit criteria and reporting, test closure activities.
• ISTQB menar att oberoende leder till bättre tester. Jag tror att ett gemensamt ansvar för leverans och kvalité med testare som jobbar nära utvecklarna leder till oslagbara resultat.
• Integrationstester beskrivs som att systemkomponenter kopplas ihop och testas tillsammans innan systemtester tas vid. Systemintegrationstester nämns inte alls.
• Att ta upp "test design specification", "test case specification" och "test procedure specification" samt jämföra skillnader dem emellan är hårklyverier. Finns det organisationer som använder sig av alla dessa specifikationer och dokument. På samma sätt gör man en stor sak av skillnanden mellan "test policy", "test strategy", "master test plan" och "level test plan".
• ISTQB verkar närmast fixerad vid olika standarder och nämner IEEE-829, IEEE-1044, IEEE-1028, CMM, CMMi, TMM, TMMi och TPI. Jag har rätt ingående studerat IEEE-829 samt TPI och anser att det läggs alldeles för stor vikt vid dokumentation och frågan är om det gör att testerna blir så mycket bättre.

Trendspaning Testing Forum 2012

Kunde inte låta bli att publicera några synpunkter från talarna på kommande Testing Forum 2012. Det är måhända ursäktat eftersom jag ändå är en av dem som är med och tycker till...


Vilka trender och vilken utveckling ser du inom testing-området det kommande året?

Örjan Bjermert, Test Manager, Omegapoint:
Jag tror på flitigare användande av verktyg, automatisering och tekniknära tester. Till viss del kommer testprovisionen att delas upp mellan de som förordar kontextdrivna tester och de som föredrar mer traditionella testmetoder.

Anders Claesson, Senior Test Specialist, xdin:
Att nästan alla går över till att jobba i Agila projekt, även de stora företagen. För testningens del kommer erfarenhetsbaserade testtekniker att användas allt mer, t.ex. exploratory testing, riskbaserad test, m.fl.

Günter Lenhardt, Testspecialist, Wasa Kredit:
Testautomatisering och outsourcing kommer att spela en allt viktigare roll inom test.

Jagannath Tammeleht, OnTrax:
Jag tror att testområdet kommer fortsätta växa även om vi kan se en tydligare personalbrist. Vi kommer även se fler specialist inriktningar så som agilt, prestanda testning, automatisering, testledning, användartestning osv

Kristian Karl, Testchef, Spotify:
Ökad grad av testautomation

Ingvar Nordström, ordförande SSTB, vice ordförande SQEB och Beata Karpinska, ordförande SQEB, vice ordförande SST:   
Agil utveckling sätter definitivt sina spår i testplanering. Om man inte ser upp, finns dock stora risker, att det påverkar grundtänkandet i test (att ha väl utvecklat tänkande för att hitta fel)

    
På vilket sätt har kraven på kvalitet ökat de senaste åren?

Örjan Bjermert, Test Manager, Omegapoint:
Förutom möjligen mindre överseende med teknikstrul så ser jag inte att kvalitetskraven har ökat. Det som däremot sker är att testobjekten blir allt mer komplexa och utvecklas under kortare tid.

Anders Claesson, Senior Test Specialist, xdin:   
En ökad användning av Agila arbetssätt ställer högre krav på kvaliteten i och med att man ska ta fram potentiellt release-bar kod i varje inkrement.

Günter Lenhardt, Testspecialist, Wasa Kredit:
Kraven på kvalitet har inte ökat, utan det som har ökat är leveranshastigheten och därmed kraven på att få ut produkter med samma kvalitet som tidigare, dvs. vi måste kunna testa snabbare.

Jagannath Tammeleht, OnTrax:   
Den globala konkurrensen inom de flesta branscher har gjort att företag idag inte har ”råd” att skapa mjukvara med dålig kvalitet. Dålig kvalitet kostar pengar både i goodwill, förlorade kunder och misslyckade projekt. Idag så är även kraven på time to market betydligt högre, det är inte möjligt att avvakta för länge för då har konkurrenterna redan tagit den delen av marknaden. Snabba kontinuerliga releaser kräver en hög kvalitet på produkten under hela utvecklinsarbetet för att inte riskera misslyckade releaser.

Kristian Karl, Testchef, Spotify:   
Jag är inte så säker på att kraven på kvalitet har ökat, snarare att leverera 'just-in-time' med 'lagom' kvalitet.

Ingvar Nordström, ordförande SSTB, vice ordförande SQEB och Beata Karpinska, ordförande SQEB, vice ordförande SST:   
- Ökad verksamhets- och behovförståelse
- Insikt att testningen som är utförd på rätt sätt, kan bidra till ökad kvalitet


Vilka är dina tre bästa tips för att ligga i framkant vad det gäller kvalitet och säkerhet?

Örjan Bjermert, Test Manager, Omegapoint:
Våga se bortanför de traditionella testmetoderna. Ta alltid fasta på det sammanhang och kontext som gäller för testobjektet. Var kritisk, och självkritisk, både gällande testobjektet och dina arbetsmetoder.

Anders Claesson, Senior Test Specialist, xdin:
Att ha en helhetssyn på systemutveckling, test och kvalitet. Det är inte test som är ansvariga för kvaliteten på systemet utan alla i projektet. Att lära sig hur man bäst använder erfarenhetsbaserade testmetoder.

Günter Lenhardt, Testspecialist, Wasa Kredit:   
1. Automatisera allt som går att automatisera
2. Använd den mänskliga kreativiteten på rätt sätt
3. Bevaka din omvärld inom test

Jagannath Tammeleht, OnTrax:
Kompetenta medarbetare är A och O. Utan kompetenta medarbetare spelare det ingen roll hur mycket du försöker förbättra, du kommer ändå inte nå önskat resultat.

En bra och tydlig strategi/process för utvecklingsarbetet, om det saknas så blir även kvalitén lidande. Ofta så vet man inte riktigt vad man menar med exempelvis kvalitet, ska man mäta kvalitet behöver man först förstå vad som menas med det inom organisationen.

En arbetsmiljö som strävar efter att ständigt förbättra och optimera arbetet på alla nivåer. Det är viktigt att våga försöka förbättra och våga misslyckas, kan man skapa denna kultur inom organisationen så har man kommit långt när det gäller kvalitet och säkerhet.

Kristian Karl, Testchef, Spotify:
Förstå produkten och kunden! Ha koll på utvecklingsprocessen, och var beredd att ständigt förbättra den.

Ingvar Nordström, ordförande SSTB, vice ordförande SQEB och Beata Karpinska, ordförande SQEB, vice ordförande SST:   
- Kompetens i test och kravhantering
- Analys och förståelse av kundensbehov och vad som skapar kvalitet för kunden
- Ett managementinitiativ (eller förståelse) att i längden kan kvalitet vara viktigare än tidsplan


Vad har du för förväntningar på konferensen Testing Forum och vad kommer deltagarna få med sig från din föreläsning?

Örjan Bjermert, Test Manager, Omegapoint:
Att ta del av alla spännande testidéer och arbetssätt därute. Jag hoppas bidra med praktiska exempel på hur man kan lyckas med testning inom agila team

Anders Claesson, Senior Test Specialist, xdin:
Att får nya idéer hur man effektiviserar sin testning.

Günter Lenhardt, Testspecialist, Wasa Kredit:   
Jag förväntar mig höra om de nyaste utvecklingarna inom test och träffa kreativa kollegor inom området. Från min föreläsning får man med sig hur man gör för att sätta upp och genomföra en framgångsrik testautomatisering som ger många vinster och en lyckad förvaltning.

Jagannath Tammeleht, OnTrax:   
Mina förväntningar är som alltid att lära mig något nytt, se vilka trender som kommer under 2012-2013. Jag hoppas kunna ge en liten annan ovanligare bild av agilt och test som har mer fokus på mjukare värden och organisationsförändring. Där många föreläsningar fastnar i test automatisering och verktyg så glömmer man ofta det viktigaste och det är den inställning som genomsyrar organisationen. Är den fel så blir det svårt att lyckas övergå till ett agilt arbetssätt.

Kristian Karl, Testchef, Spotify:   
Bli inspirerade.

Ingvar Nordström, ordförande SSTB, vice ordförande SQEB och Beata Karpinska, ordförande SQEB, vice ordförande SST:   
- Från vår föreläsning: Att testkompetens är oerhört viktigt inför den krävande agila verkligheten

Agila testnivåer

Testnivåer används för att fokusera testarbetet och testa utifrån olika egenskaper hos systemlösningen. Vid olika testnivåer upptäckts olika typer av fel samt att de olika testerna skiljer sig i hur lång tid genomförandet tar. Man börjar med basala tester av arkitektur och grundläggande funktioner. Då får man snabb återkoppling om utvecklarna är på rätt spår. De övre testnivåerna handlar om komplexa tester av komplicerade användarfall och systemsamband. I den här bloggposten visar jag hur olika testnivåer kan kopplas till den agila utvecklingscykeln.

Ett vanligt synsätt är att man ska sträva efter att hitta alla fel så tidigt som möjligt vilket beror på ett antagande att kostnaden för att åtgärda buggar ökar med tiden. Jag anser att det inte nödvändigtvis är sant. T.ex. är det kostsamt att hitta och rätta obskyra integrationsfel vid tidiga testnivåer, utan tillgång till angränsande system. Sträva istället efter att testa ekonomiskt och vänta med de komplexa testerna till senare faser. Ifall de basala funktionerna åtgärdas tidigt, så kommer antagligen de felaktigheter som upptäck senare att kunna åtgärdas relativt enkelt.

Några ryska matrushka-dockor får symbolisera olika testnivåer. Varje testnivå har olika syften och tid för återkoppling till utvecklarna skiljer sig åt.

TDD och parprogrammering

Testerna börjar redan medan utvecklarna skriver sin kod. Med bra utvecklardiciplin kan många fel hittas redan från början. De fel som hittas kan åtgärdas omgående och dessa typer av utvecklingsnära tester kan alltså bli mycket effektiva. Ge utvecklarna tid för att experimentera med parprogrammering och testdriven utveckling. Även testare och utvecklare kan arbeta i par och bidra med respektive kompetens.

Continuous integration

Här handlar det om att implementera och integrera små utvecklingsdelar i taget. När utvecklarna är klara med en delfunktion adderas koden till den gemensamma kodbasen. Därefter följer ett automatiserat kodbygge med ev. automatiserade modultester. Kodbygget kan även innehålla enklare regressionstester, deploy till testmiljöer och liknande. Genom täta incheckningar och kontroller av hur ny kod fungerar i systemet så kan avvikelser åtgärdas tidigt. En annan fördel är att med continuous integration får man ett bra ramverk för versionshantering, releasehantering och testautomatisering.

JAM-test

I det agila projektet finns behov av proaktiv testning av utvecklingsaktiveter allt eftersom dessa blir klara. Eftersom utvecklingsaktiviteterna ej är entydiga med användarfall eller testscenarier så kan man inte tala om regelrätta systemtester. Syftet är istället för testarna att ge så effektiv återkoppling som möjligt på de nyutvecklade funktionerna, gärna med utforskande testtekniker. Jag kallar detta för JAM-test och redogör för detta i tidigare blogginlägg.

ACT-test

I slutet av en agil utvecklingscykel ser jag ofta behovet att göra systemtester och regressionstester på hela levererade kodbasen efter kodfrys. Eftersom tidigare tester gjorts på delar av funktioner utifrån delleveranser från utvecklarna så är detta kanske första gången som användarfall kan köras i sin helhet. Det är också första gången som alla funktioner finns med i en potentiell releasekandidat. Jag kallar detta för ACT-test och ser det som ett koncentrerat hypereffektivt systemtest. Testerna är nu mer formella än tidigare testnivåer och veriferar de användarfall som ska levereras utifrån de testscenarier som skapats av testerna. Jag berättar mer om ACT i ett tidigare bloginlägg.

Systemintegrationstest och acceptanstest

Systemintegrationstest och acceptanstest är väsenskilda de övriga testnivåerna eftersom de ofta görs utanför den agila utvecklingscykeln. Dessa tester innefattar angränsande system och organisationer utanför det agila teamets kontroll. Man kan därmed inte ställa samma höga krav på effektivitet i genomförande och återkoppling. Se till att planera för nödvändiga testaktivteter och åsidosätt resurser i lämpliga sprintar så att teamets övriga arbete inte blir lidande när systemintegrationstester och acceptanstester pågår samtidigt som ordinarie utvecklingsarbete.

Agila proaktiv testning och traditionell testexpertis

För en testare i ett agilt team, upptagen med ett oändligt antal testaktiviteter, finns det alltid en risk att bli alltför utvecklingsorienterad. Trots att man blir avbruten med nya testreleaser varje dag så är det fortfarande viktigt att fokusera på helheten, testtäckning och kravuppfyllnad. Mitt upp i det hela, när man frågar sig hur en funktion verkligen ska fungera, så är det förförande enkelt att ta till sig utvecklarens uppfattning. Resultatet blir att en oerfaren testare börjar fokusera på ”vad som finns” när ”vad som saknas” förstås är lika viktigt. Det är nödvändigt att den agila testaren ibland tar några steg tillbaka och tänker på testaktiviteterna utifrån testtäckning, testscenarier och testidéer. Att kombinera teknisk proaktiv testning med kravbaserade traditionella tester, utan att låta någon av dessa stå tillbaka, är en riktig utmaning för den agile testaren.

Det första som sker när ett agilt team startar en ny utvecklingscykel är att den aktuella kravmassan bryts ner till underuppgifter inför utveckling. Det är väldigt viktigt att testarna är med på dessa aktiviteter. Att bryta ner krav till utvecklingsuppgifter hjälper testaren att förstå funktionerna och låter testaren bidra med kunskap om testbarhet, användbarhet och allmän systemkunskap. Vissa krav kan resultera i rena testaktiviteter. Exempel är icke-funktionella tester (såsom prestanda, säkerhet, användbarhet, förvaltningsbarhet et.c.) eller rena testaktiveter (t.ex. hantera testmiljöer och arbeta med regressionstester). Testuppgifterna utförs och följs upp precis som vanliga utvecklingsaktivteter. Kom bara ihåg att uppmärksamma tidsaspekten så att testarna har tillräckligt med tid att utföra dessa uppgifter och samtidigt kunna genomföra ordinarie testaktiviteter. Det är viktigt att införliva testaktiviteterna i mängden av uppgifter i utvecklingscykeln, likväl som rena utvecklingsaktiviteter.

I ett agilt team är det oftast fråga om ett par dagar innan utvecklarna har funktioner implementerade och klara för test. Än kan man inte förvänta sig att alla funktioner har grafiskt gränssnitt eller är fullständigt integrerade. Till en början får man som testare oftast nöja sig med databasscheman, fristående funktionslogik och liknande. Med lite teknisk systemkunskap bör det inte vara något större problem att testa småbitar av funktioner såsom de levereras. Ibland kan det vara en bra idé att låta testare och utvecklare arbeta i par och nyttja varandras kunskaper för testning och utveckling. När det inte finns några nya funktioner att testa finns det fortfarande mycket att göra. Testare kan arbeta på nya testscenarier eller testidéer utifrån krav och annan tillgänglig information. Testmiljöer, testdata och testverktyg behöver sättas upp. Kanske finns det testautomatisering som behöver utföras eller nya testmetoder och verktyg som är intressanta och behöver utvärderas? Det är viktigt att testarna kan bidra med allt detta och samtidigt fokusera på proaktiv testning.

En vanlig missuppfattning är att samtliga i ett agilt team ska jobba med utveckling och göra ungefär samma saker. Det är förstås inte sant. Alla har ett gemensamt ansvar för utveckling och kvalité men man kan bidra till det övergripande målet utifrån olika roller. Ifall det finns någon i teamet med ansvar för testplanering, testrapportering, testmiljöer/-verktyg/-data (formellt eller informellt), så är det förmodligen en testledare. Testledaren hör hemma i det agila teamet men eftersom det knappast finns uppgifter för en testledare på heltid så funkar det jättebra att komplettera med vanligt testarbete . Det behövs någon som har övergripande kontroll över vilka tester som görs, systemets kvalité och vidareutvecklar testarbetet. Ytterst är det testledarens ansvar att testarbetet skrider framåt. Det är också viktigt att testningen sker så effektivt som möjligt och alltid sträva efter förbättringar, antingen i testprocessen eller med hjälp av förbättrat tekniskt stöd.

Med alla utvecklingsaktiviteter levererade och alla delfunktioner individuellt testade, finns det en skaplig chans att också den kompletta levererade funktionen kommer att fungera väl. Det är nu som testaren måste byta fokus och verkligen verifiera funktionen utifrån krav, användarfall, systemets kontext eller annan tillgänglig information. Ett bra sätt att göra detta är att utgå från skrivna testscenarier eller checklistor. Testscenarier behöver inte vara särskilt detaljerade så länge som de hjälper testaren att se helheten och jämföra med vad som levererats. Nu testas hela användarfall snarare än enskilda små funktioner. Väl beprövade traditionella testtekniker är viktiga i vad som liknar ett traditionell systemtest, fast i kondenserad form.

Utvecklingscykeln avslutas vanligen med en sprintdemo, ”go/no go”-möte eller liknande. Där beslutas det om implementerade funktioner är tillräckligt bra för release. Testarna demonstrerar de viktigaste funktionerna och kravställarna uppmuntras att pröva egna testidéer. Testarna delar med sig av sin syn på systemets kvalité och det bestäms ifall systemet är tillräckligt bra för en release. En release kan sen göras till acceptanstestmiljö, för ytterligare tester utanför teamet, eller direkt till produktion.

1. Six development activities are being developed.	2. Four of them are finished and some successfully tested.
3. The rest of them are finished and some more successfully tested.	4. When all of them are finished and individually tested, chances are that the whole test case will be successful even though it has not been run in its full extent before.