I dessa agila tider är det intressant att se hur utvecklarnas engagemang i nya metoder frodas. SCRUM, Testdriven utveckling, XP och User Stories är inne sen ett tag tillbaka. Sen funderar jag förstås på hur vi testare ska utvecklas för att matcha det nya? Ibland kan jag tycka att vi glöms bort i farten för att sedan återupptäckas. Hoppsan, det räcke inte med enhetstester.
Vad kan vi själva göra för att få till ett bra samarbete? Hur kan vi lära oss mer om hur vi kan passa in, och göra ett bra jobb med dessa helt nya förutsättningar som finns. Själv läser jag om SCRUM, testdriven utveckling och verktygsstöd i form av Fitnesse, Selenium, Watir och annat. Sen finns det gott om bloggar och annat material på webben pch en hel del riktigt tunga namn som exempelvis Henrik Kniberg som skriver friskt om den senaste – just nu om Kanban.
Sen tittar jag på vad testarna i Sverige håller på med, vad som kommer upp i artiklar och konferenser. Förvånande ofta ligger fokus fortfarande på V-modellen – en variant av vattenfallsmodellen som ingen IT-människa med självaktning hävdar att de följer idag – eller automatisering med GUI-baserade kommersiella verktyg som är helt ute i agil utveckling. När nyare utvecklingsmodeller fokuserar på User Stories och vikten av att kommunicera så pratar många testare fortfarande om vikten av spårbarhet, tydliga krav, detaljerade testfall, loggade testkörningar och vikten av att mäta. Visst finns det sammanhang där spårbarhet och detaljerade krav väger tungt, som medicin och flyplansindustri till exempel, men i väldigt många andra fall gäller motsatsen. Om de nedskrivna kraven är vaga och föränderliga – ska vi testare då svara med att kräva mer dokumentation eller är det bättre om vi kommer med i matchen på de nya villkor som finns?
Till sist ger jag återigen testcertifieringen enligt ISTQB eller ISEB en känga. Innehållet känns väldigt gammalt och inte alls i takt med de utvecklingsmetoder som används idag. De exempel på tekniker som visas har allvarliga brister och leder novisen in i en falsk trygghet av att de förstår hur test fungerar. De processer och standarder som man tvingas lära sig i detalj bygger helt på vattenfallstänkande och tar ingen som helst hänsyn till sammanhanget. Vad sägs i kursen om test i förhållande till Unified process och agil utveckling – dagens verklighet? Inte mycket, anser jag. Hur mycket praktisk nytta har en testare av kursen? De flesta erfarna testare jag pratat med anser att det är en fejkad försäljningsploj med ringa värde, vissa andra anser att det är ett hot mot testarnas utveckling då den sprider felaktig och skadlig information.
Om jag har rätt eller fel eller nånting mittemellan är upp till dig själv att avgöra. Syftet med artikeln är att visa att det finns alternativ för hur du kan utvecklas och bli en ytterst värdefull resurs. Det viktigaste för en testare är att ifrågasätta. Detta gäller oavsett om det är krav, blogginlägg, system redo att testa eller vårt eget arbetssätt.
Det finns visionärer! Läs bloggarna av James Bach, Mickael Bolton, Cem Kaner, TheTesteye.com m fl. Det har öppnat mina ögon och gjort att jag omvärderar mycket av mina tidigare föreställningar. Jag tror att Sverige kan bli ett föregångsland för testning – det gäller bara att alla som känner sig upplysta förmedlar sina kunskaper på testzonen och andra bloggar.
Torbjörn, jag håller inte riktigt med dig om att debatten och konferenserna inte berör agile och kanban osv. Jag tycker att väldigt mycket av debatten har svängt och jag tycker att istort sätt alla artiklar och konferenser handlar om agile på något sätt. Sedan måste det i stora organisationer ibland anpassas till och tas hänsyn till befintliga processer och beslutspunkter varav detta berörs i praktikfall och diskutionerna.
Detaljerade testfall var det tack och lov länge sedan jag såg någon förespråka, det är ju nästan alltid en rads testfall och utforskande test som diskuteras och framhålls.
Så nog går utvecklingen framåt, även om man alltid vill att den skall gå fortare när man är engagerad!
Mycket intressant frågeställning, ibland har jag stort hopp, ibland mindre…
Men nog tycker jag att det börjar sätta sig att testning inte bara handlar om att verifiera krav.
Och intressant nog är det Sverige och Nya Zealand som nappat mest på Exploratory Testing.
Men jag har fortfarande inte hört talas om någon som verkligen siktat på att bli testare, snarare halkar man in där på ett bananskal (vilket iofs är jättebra, då får vi diversifierade test-team.)
Vad gäller de “nya” metodikerna så är jag lite bakåtsträvande på ett speciellt sätt:
Jag tycker att testning är otroligt likt oavsett utvecklingsmetodik: man lär sig mycket, hittar på bra saker att testa, och testar dem på bästa möjliga sätt.
Visst är det olika planer, möten, rapporter, kommunikationsvägar, men själva “testningen” – det kritiska och kreativa tänkandet – är (eller borde vara!) väldigt likt oavsett process.
Jag är snarare orolig för det motsatta, att man fokuserar för mycket på process, och glömmer bort att skapa värde (efter Jonathan Kohl, EuroSTAR 2009)
På EuroSTAR förra veckan var det inte jättemånga svenska presentationer, men inte var de speciellt bakåtsträvande: en var åt teater-hållet, en om Exploratory Testing, och en om enradingar (min egen)
Jonas: “det är ju nästan alltid en rads testfall” – detta är mitt favoritområde just nu, så jag är mycket intresserad av mer info om detta!
Jag har inte tagit nån ISTQB-certifiering, bara läst materialet, och borde kanske inte uttala mig; men jag tror nog inte att det är skadligt att gå kursen, om man tar den med en nypa salt.
Att det skulle vara välinvesterad tid och pengar (ur ett kunskapsperspektiv) har jag dock svårt att tänka mig.
Jag tror också att Sverige kan bli ett föregångsland inom testning (vi är ju världens mest moderna land, enligt Fredrik Lindström); kanske är vi redan på väg, t.ex. tror jag att vi i Sverige är de som mest använder oss av intressanta kombinationer av utforskande och “skriptad” testning.
“Vart är test på väg?”
Oavsett vilken utvecklingsmetod/process man använder så är jag övertygad om att kraven på (kostnads)effektiv test kommer att öka med tiden.
Om man vill överleva i branschen på sikt tror jag att man måste kombinera teknikkunskap och verksamhetskunskap i sitt testande (utöver testkunskap).
Teknikkunskap (programmering, verktyg, arkitektur m.m.) möjliggör effektiv testexekvering,
större testtäckning och underlättar vid samarbete med Utveckling m.fl.
Vidare kan man ta större kontroll över sin (test)situation genom hantering av testmiljöer, byggen, testdata, servrar m.m. i egen regi och på så vis även minska/eliminera flaskhalsar i testarbetet.
Verksamhetskunskap underlättar vid kommunikationen med kund samt gör det lättare och snabbare att besvara frågan: Är det ett problem här?
Stefan,jag håller helt med dig. Framförallt om teknikkunskapen som saknas hos väldigt många testare. Den möjliggör också effektiv testautomatisering som är ett område jag själv tror mycket på.
jag känner inte riktigt att vi blir bortglömda inom den agila utvklingen. Det är snarare så att Agil test har en liten annan syn på vad testning är och hur den bör exekveras. Jag tror att detta kommer sig av att det var utvecklare som tagit fram de agila metoderna och principrena. Utvecklare tenderar ofta till att tycka att det är ballast med teknik och kod. Hur löser man då testning med automatisering så klart!
Vad jag däremot känner är att vi testare tappat bort oss själva när den agila stormen kom. Jag tror liksom många inte han med att reagera och kännde sig övermannade. Vårt sätt att reagera har då varit att skylla på att agile inte tar hänsyn till testare istället för att skapa en plats och ett berättigande åt oss. Vi blev visst lite handlingsförlamade och valde istället att sura för ett litet tag .
Det är nu på senare tid som jag hör fler och fler börjar stå upp för vår kunskap och vår roll, både agile coacher och testare.
Rikard – “Visst är det olika planer, möten, rapporter, kommunikationsvägar, men själva ”testningen” – det kritiska och kreativa tänkandet – är (eller borde vara!) väldigt likt oavsett process.”
Jag håller helt med dig tyvärr så är det ganska nedslående att upptäcka att vi är ganska få som ser det på det viset.
det är här som det skadliga i kurser som ISTQB kommer in. Jag har ISEB foundation och practitioner och har även varit lärare för ISTQB foundation två gånger. Jag kan ärligt säga att jag tycker att dessa kurser är direkt skadliga att gå om man vill bli en bra testare. Dom tutar i en ett monotomt och repetativt arbetsätt som inte tar någon hänsyn till kontexten. ISTQB förenklar testningen till den grad att man inte behöver tänka för att planera eller utföra test utan bara slaviskt följa mallar och ofullständiga tekniker. Kort sagt kan man säga att ISTQB lär inte ut testning utan lär ut att man ska sluta tänka och inte ta eget ansvar. Det hejdade upp min utveckling i ungefär 1,5 år som för mig var total waste. hmm kanske en kommande artikel, så mycket att skriva och så lite tid 🙁
Stefan och matt Teknisk kunskap är otroligt viktig och värdefull i en testgrupp men jag skulle inte vilja dra det så långt så att jag vill att alla måste ha det. Det finns en överhängande risk att testningen blir allt för teknikfokuserad. Jag kan även tycka att teknisktkunnande saknas i många av dagens testgrupper så ni har inte fel. Bara tänka på att vi vill inte ha steriotyper och homogen kunskap i våra testare utan en fin spridning där vi totalt i gruppen kompleterar varandra med spetskompetenser inom en rad olika områden.
Roligt med så många kommentarer. Jag var ju tvungen att läsa igenom lite konferensprogram från förr och nu. Konstaterar att det åtminstone på pappret ser ganska OK ut med nyare metoder. Skönt att ha fel ibland…
Men hur ser det ut i testarnas vardag? Jag har hållit väldigt många kurser i främst testdesign. Deltagare har kommit från alla olika branscher och de flesta tror jag har haft nån nytta av det de lärt sig. Men väldigt många – de flesta faktiskt – använder inte innan kursen regelbundet några strukturerade testdesign tekniker. Och i de flesta fall är det (för) enkla varianter av dataanalys som används. Här hänvisar jag också till Mats Grindal på ENEA som i sin doktorsavhandling hade frågat teknikbolag och medicinbolag om detta och resultatet var skrämmande – ytterst få använda regelbundet något annat än Ekvivalensgrupper/gränsvärden.
Teknikkunskap hos någon, men inte alla, av testarna i ett projekt är viktigt. I mitt senaste projekt jobbade vi till största delen med XML-filer, egenbyggda testgränssnitt, loggläsningar, SQL-verktyg och BIZTalk-verktyg. Väldigt lite var tester som kunde utföras av någon utan grundläggande databaskunskaper mm.
Sen inser jag efter Oscar Cs senaste inlägg att jag måste lära mig mer om webbteknik inför kommande projektet.