“Technical tester”, “Automatiseringsexpert” och “Testingenjör” är eftersökta kompetenser. Alla vill ha dom, alla behöver dom. Vi går från tunga manuella tester i vattenfallsprojekt till agil utveckling med snabba och automatiserade tester. I den agila världen blir testcyklerna tätare samt att regressionstest blir tyngre och behöver köras oftare. Detta kräver hundratals av manuella testare eller automatisering. Automatiseringen i sig gör att testerna blir mer tekniska. Antalet testverktyg ökar men dom ökar även i komplexitet. Vi kan spela in alla typer av protokollspråk, vi kan med lite fix i skriptkoden manipulera våra testfall till vad som helst. Vi har genomtänkta strukturer för automatisk verifiering där moduler återanvänds. Vi matar testverktyget med generisk testdata osv. Detta kräver en helt annan typ av kunskap och erfarenhet än vad den traditionella testaren som vuxit upp med manuella klicka-steg-för-steg-tester har.
Medvetenhteten för test har ökat och man förstår att det är viktigt och vill satsa på det. Det är ju iofs väldigt roligt och efter att ha stävat efter detta i flera år känns det skönt när det släpper lite. Men ”man” är dock oftast chefer, projekt ledning eller liknande som främst varit och är fokuserade på utveckling. Vilket lätt gör att man vill bygga upp något smart, effektivt och just det, automatiserat. Men det finns väldigt få bra testare att få tag på.
Att ha testtänket OCH teknikkunskapen. Kunna automatisera… ja, då är frågan om den man söker inte är mer utvecklare än testare. Har man tur och hittar en utvecklare som även har erfarenhet av test är det ganska stor sannolikhet att man hittat en utvecklare som inte vill testa men som åkt på arbetsuppgifterna. Samma sak är det med motsatsen. Det finns en hel del traditionella testare som blivit påtvingade att arbeta med mer tekniska tester, för det var det man måste satsa på. Testaren är dock inte intresserad och känner sig illa till mods då denne saknar erfarenhet och kunskap. Var hittar man den moderna testaren? Jag känner till några men dom är få!
Är det kurser och utbildning som saknas? Är det fortfarande testyrkets rykte om att vara ett lågstatusjobb som sätter käppar i hjulen? Är det insnöat sysätt för hur test ska bedrivas som gör det svårt att ge sig in i framtiden på bred front? Eller är det så att tekniska tester och automatisering är fel väg att gå?
Ja, jag vet inte… jag vet bara att det är väldigt svårt att få tag på riktigt duktiga testare som även besitter djup teknisk kunskap samt erfarenhet från testautomatisering.
Då detta ämne ligger mig varmt om hjärtat (jobbat med automatisering/testverktygsutveckling i nästan 10 år på deltid) så ska jag delge lite tankar om detta:
Är det kurser och utbildning som saknas ?
Intresse, intresse samt inlärningsförmåga räcker långt. Jag har byggt mycket av min tekniska kunskap på att fråga andra kollegor, sökt på nätet, deltagit på diverse forum, läst bloggar, tittat på annans kod, läst böcker etc. Några kurser har det inte blivit än…Stöter jag på ett problem så kan man ge sig på någon annan även gjort det innan och funnit en lösning. Detta är den främsta anledningen till min blogg då jag gärna delar med mig av tankar och kodexempel då jag vill ge tillbaka till den enorma Community som finns.
Är det fortfarande testyrkets rykte om att vara ett lågstatusjobb som sätter käppar i hjulen ?
Tror inte det gäller längre. Beror förmodligen mera på att kombon test och programmering är sällsynt. Är man duktig utvecklare lockar nog applikationsutveckling före testautomatisering tror jag som du varit inne på.
Är det insnöat sysätt för hur test ska bedrivas som gör det svårt att ge sig in i framtiden på bred front?
Förstår inte frågeställningen riktigt. Vilket synsätt är insnöat? Traditionell testning eller automatisering? Jag förespråkar manuella utforskande tester med kompletering av automatiserade regressionstester av de vanligaste fallen.
Eller är det så att tekniska tester och automatisering är fel väg att gå?
Om man tror att automatisering via GUI kommer att lösa en massa problem så finns det risk att man blir besviken när man ser vilket värde/kostnad som man får. Jag är mer anhängare av “semi”-automatisering, dvs man förser utforskande testare med diverse verktyg/script så att de manuella testerna blir kraftfullare.
Jag tror även mycket på att bygga in testbarhet direkt i systemet men det är väl ingen nyhet för en trogen läsare av TestZonen 🙂
Hej,
Automatiserade GUI tester är inte tillräckligt för att höja kvaliten på slutprodukten men det kommer att ha en avgörande roll för att garantera miniminivån av kvalite om vi pratar många leveranser i agila projekt!
Det krävs bättre och mer smarta ramverk för att GUI tester ska kunna utföras automatiskt och utan beroende på en massa specialskript som några få förstår.
Ska man testa ett system utifrån, så ska man inte begära att systemet ska ha testbarhet i sig, vi måste ju testa det utifrån eller hur?
Själv kommer jag från utvecklarhållet och har alltid försökt leverera kod som “fungerar” genom att testa min egen kod ordentligt.
Jag har väldigt svårt att förstå att utvecklare kan än idag hålla på och lämna ifrån sig leveranser som man inte ens med tång kan ta i!!!
Jag tror att vi behöver förstå att testautomatisering “kräver” folk med utvecklarkompetens just nu. Det är komplicerad och kräver förståelse för teknik, logik och programmering/skripting, ramverk och dess APIer. Nu pratar jag testautomatisering som är smart där man måste kunna återanvända kod, tester, valideringar mm.
Hörde för ett tag sedan att Microsoft har 55000 anställda varav 20000 jobbar med test! Dessutom var komptenskravet för att jobba med test samma som för att jobba med utveckling, säger det nåt?
Mvh
Majid
Intressant input…
Ska man testa ett system utifrån, så ska man inte begära att systemet ska ha testbarhet i sig, vi måste ju testa det utifrån eller hur?
Jag tror på både tester utifrån samt inbyggd testbarhet. Allt som hittar buggar på tidigt stadium och är billigt är väl bra?
Hörde för ett tag sedan att Microsoft har 55000 anställda varav 20000 jobbar med test! Dessutom var komptenskravet för att jobba med test samma som för att jobba med utveckling, säger det nåt?
Jag skulle inte vilja ha 20000 testutvecklare enbart (ofattbar siffra!) utan bra test kräver många olika kompetenser och infallsvinklar varav utvecklingskravet blir hämmande. Om jag hade en testarmé på 20 000 tror jag att några 1000-tals duktiga utforskande testare skulle sitta fint 🙂
Ett av dom stora problemen är att folk går och tror att det är testarna som ska ägna sin tid till att skapa script för automatiserade checkar.
Om vi istället vänder på steken och frågar oss vem är det som har störst behov och nytta av dessa checkar?
Mitt svar på detta är utvecklaren. Han/hon vill ha dessa för att tryggt kunna lägga till ny kod eller förändra befintlig kod. Om den nya koden ställer till problem vill utvecklare få en snabb indikation att något står snett till. Ett sett att lösa detta är att ha en massa automatiserade checkar för befintlig kod och kontinuerligt skapa nya för ny och förändrad kod. Lika så är det populärt att prata om automatiserade acceptens checkar. Att skapa dessa innan man bygger sin produktions kod get utvecklaren en indikation när denne skrivit tillräckligt mycket kod för att uppfylla acceptanskirterierna för storyn samt att dessa checkar kan läggas till regressionssviterna för att produkten som helhet uppfyller acceptanskriterierna för alla implementerad stories.
Ingenstans i ovan scenario ser jag testare eller testning allt handlar om utvecklare och checkar. Låt de som har störst nytta och intresse av dessa checkar inkorporera detta i sitt dagliga arbete (ja, vi kan rådgiva kring detta). I agilt pratar man om att teamet som helhet är ansvarig för kvaliten som teamet levererar det är då väldigt konstigt att vissa förespråkar att testaren ska göra allt arbete som har med test eller checking att göra. Sluta leta efter testare som ska ansvara för automation i agila team, detta synsätt visar bara på att man inte förstått bakgrunden till att man använder sig av checkar och fortfarande inbillar sig att det är en testakrivitet. Att föra in detta under utvecklres uppgifter kan medföra att man kortar ner feedbackloopen, hjälper till en hållbarar och enklare design, ökat ansvarstagande av koden samt en stabilare mjukvara. Varför vill man inte ta vara på dessa starka fördelar?
Testning däremot är ett detektivarbete som inte är förutsägbart. För att citera Bob Hund “Jag anser, dessutom, att det okända, e helt å hållet på min sida!”
En testares främsta uppgift är att ta fram och leverera information till våra intressenter som en del i grunden till de beslut som behöver fattas. Duktiga testare ser till att denna information tas fram vid rätt tid, är lämplig, relevant och värdefull för våra intressenter.
För att utföra detta arbete krävs helt andra egenskaper än att försöka kopiera kompetensen hos en utvecklare.
Sluta leta efter testare som ska vara utvecklare. Fundera över vad som krävs för att man i ert team ska kunna utföra bra testning (inte checking) och prova att ta in en riktigt duktig testare istället.
Låt utvecklare göra det jobb dom är bra på och låt oss testare det jobb dom vi är bra på. Lär er att utnyttja människorna i teamet på bästa möjliga och effektivaste sätt istället.
Men börja med att skaffa er en förståelse om vad testning handlar om och vilket syfte det kan fylla hos er.
Hej,
Äntligen är det någon mer än mig som har börjat uppmärksamma den tekniska testare och dess tillvaro. Test är ett lågstatusyrke och kommer att så förbli så länge som det endast krävs en tredagarskurs och en certifiering lättar det enklaste sudoku-spelet. Detta gör att Tant agda kan kalla sig testare utan att ens förstå grunderna inom IT-området. För att få fram mer generellt duktiga testare måste certifikatet göras om eller tas bort helt. Som den är i dag är löjligt och ett hån mot alla seriösa testare.
Själv har jag hållit på med test i 5 år, japp jag är också certifierad mest för att jag skulle få det första testjobbet, och i höstas tog jag steget över till programmering igen. Detta för att jag tycker teknik är roligt och utmanade, efter ca 5 månader som programmerare inser jag hur lätt det är att vara testare och jag förstår nu många programmerares syn på test som lågstatus yrke. Så enkelt det var att testa, klicka lite över allt och allt bara kraschar. Som jag ser det har test en viktig funktion men det behövs ingen större kunskap för att bli testare.
Om verkligheten går mot mer tekniskt krävande tester såsom test automatisering eller som jag ser det, semiutvecklare måste ett viktigt incitament öka nämligen lönen. Det måste lönen för den tekniska testare närma sig programmerarens lön och inte ligga i samma lönespan som klick-testarnas. Genom att lönen tror jag att många av dagens programmerare skulle kunna tänka sig att hålla på med mer teknisk testning.
Så mina två konkreta punkter är att gör om eller ta bort testningcertifikatet och lönen för den tekniska testare skall lika en programmerares lön för att locka över fler programmerare.
Kul med så många bra kommentarer!
@Henrik#1
Håller med om att utvecklarna bör ansvara för utvecklingsnära checking som Unit test, code coverage m.m. Tror inte varken utvecklare eller testare ska spendera för mycket tid på GUI-automatisering utöver “smoketesting”.
Det som kan göra testaren mera framgångsrik i jakten på problem är vad jag kallar “semi-automatisering”, dvs diverse checks (SQL-script, loggparsers m.m.) och testhjälpmedel (stränggeneratorer, filgeneratorer m.m.) som underlättar det manuella testandet. Fördelen om testaren själv kan skapa dessa är att man kan skräddarsy efter sammanhanget samt ökar sin tekniska kunskap i och med framtagandet. Men har man en “Test toolsmith” i teamet så funkar det med. Som artikeln handlar om är dessa sällsynta…
@Henrik#2
ta bort testningcertifikatet
Håller med.
lönen för den tekniska testare skall lika en programmerares lön för att locka över fler programmerare
Utan att ha något underlag så gissar jag att dessa sällsynta testare får bra betalt, i många fall mer än utvecklare i snitt. Om en utvecklare skulle “ta steget” till en teknisk testare så gissar jag att de inte skulle gå med på en lönesänkning…
Så enkelt det var att testa, klicka lite över allt och allt bara kraschar. Som jag ser det har test en viktig funktion men det behövs ingen större kunskap för att bli testare.
Skojar du? För att bli en bra testare krävs förutom rätt egenskaper, verksamhetskännedom och underlättas av teknisk kunskap. Att ha en testare som bara klickar runt kan man ersätta med automatisering…en bra testare kan man inte ersätta med automatisering.
Nu vet jag inte riktigt om jag förstod den tekniske Henriks berättelse, så rätta mig gärna om jag har fel.
Du har bytt till programmering, och när du nu testar din kod, så kraschar det hela tiden?
Oavsett vem som programmerat, så är min erfarenhet att den mesta koden som skrivs är ganska stabil.
Och att testare ska ta fram mycket mer sorters information än krascher;
förutom risker, förbättringsidéer, styrkor, så undersöker man problem inom prestanda, korrekthet, säkerhet, testbarhet, tillgänglighet, användbarhet m.m. för olika användares behov, känslor, data och konfiguration.
Jag tycker det är svårt, framför allt när det ska göras på ett snabbt sätt och kommuniceras effektivt.
Nu är jag i och för sig inte certifierad, men jag har 13 års erfarenhet, och har precis bemästrat Svarta-Orm-tekniken.
Om du på riktigt vet hur man gör testning lätt, berätta mera!
Stefan jag håller med dig och en “Test toolsmith” kan vara mycket värdefullt att ha i ett team för att tex speeda upp en del moment och på så sätt frigöra mer tid till testning. Dock så läser jag inte alls denna artikel som att det är funktionen/nyttan av en “Test toolsmith” som tas upp. Min beskrivning av av en sådan roll ligger väldigt långt ifrån vad som beskrivs i artikeln.
Henrik – menar du alvar med det du skriver eller försöker du bara reta upp folk? Jag väljer att tolka detta som ett dåligt skämt!
Måste manuell nödvändigtvis betyda tung? En manuell, tänkande testare kan lägga märke till miljontals detaljer utan att man ens behöver be honom eller henne att göra det. En dator kan bara lägga märke till exakt det du ber den leta efter. Javisst finns det värde i automatiserade checkar, massor av värde till och med, men jag vill varna för faran i att säga att vi går mot snabba automatiserade tester på ett sätt som implicerar att vi samtidigt skulle sluta testa manuellt. (Men rätta mig gärna om jag feltolkar.)
Vi behöver ha bort tunggrodda, dyra manuella checkar, absolut, men vi behöver ersätta det med kritiska, kreativa, noggranna, utforskande, nyfikna, “manuella” testare som kan hantera implicita kravmassor och inte bara “kolla av kraven”, eller “klicka runt lite till det krashar”.
Jag instämmer i tidigare kommentarer: Du måste skämta?
För det första så var det länge sedan jag stötte ihop med en programmerare som såg ner på mig som testare efter några få minuters samtal, så i min lilla värld verkar test inte ha låg status längre.
Om det sedan räcker med att klicka runt lite för att applikationerna du jobbar med ska krasha så förstår jag inte varför test skulle ha en viktig funktion? Det låter ju inte som att produkten är redo att testas alls?
En av (de många) svårigheterna och utmaningarna för en duktig testare är att ständigt kunna ha förmågan att kunna anpassa sin strategi och tillvägagångssätt för att leverera ny och värdefull information. Att vi slutar hitta buggar betyder inte nödvändigtvis att produkten är stabil. Kanske har vi en dålig strategi?
För att lyckas måste en bra testare också kunna tänka kritisk, kreativt och lateralt – kunna interagera med och förstå sin omgivning och kontext – känna och lära mer om produktens kvalitetskriterier – ständigt ta in mer kunskap om de olika produktelementen och hur dessa hänger samman. Och då skrapar vi ändå bara på ytan…
Jag har hållit på i lite över 5 år, och jag tycker fortfarande är att jag i högsta grad är en nybörjare på ovanstående. Så jag instämmer med Rikard att jag gärna lär mig mera om hur detta skulle vara lätt.
Oj, va mycket kommentarer! Härligt!
Artikeln är väldigt inriktad på automatiserade tester ja, men jag tycker inte att detta ämne med brist på teknikkunniga testare bör begränsas till det. Så tack alla som tagit upp detta i era kommentarer.
Att ha en testare, som dessutom kan utveckla, i testgruppen som jobbar med teststöd är något jag haft tidigare det har varit väldigt bra. Och jag har haft även detta i åtanke då jag skrev artikeln men nej, det kanske inte framgår.
Det finns ytterligare en del, kanske den som är mest tydlig för mig idag, och det är att vårt testobjekt/systemet vi ska testa är väldigt tekniskt. Våra slutanvändare är utvecklare. Vi behöver alltså testare (manuella, utforskande tester) som kan teknik och kan testa ur en utvecklares perspektiv eller en utvecklare som kan testa.
Jag vill även poängtera att om man har en testare i ett Scrumteam och teamet ansvarar för att automatisera, så bör testaren sträva efter att jobba med detta lika mycket som utvecklarna. I Scrum ska ju alla kunna hjälpas åt med allt.
Jag lyssnade på Janet Gregory här om dan och hon uppmanar testare/agila testare att vidga sina vyer, lära sig nya saker och hon uppmuntrar mycket till att förbättra sina utvecklarsskills. Jag tror detta är viktigt om man jobbar agilt i snabbt tempo och nära utvecklarna. Det går inte att sitta som en manuell teknikmotsträvare och vägra lära sig hur man automatiserar eller kan förbättra teststödet.
Jag vill dessutom påpeka att jag inte alls menar att all manuell testning ska ersättas med automatiserad testning. Det är den repetitiva regressionstestningen som oftast är “checka av” som vi tjänar på att automatisera. Jag hävdar starkt att vi absolut inte får ta bort den manuella intelligenta testningen. Men där har jag inte riktigt lika svårt att hitta folk. 🙂
Om man hakar upp sig på att man använder ordet “test” istället för “checka av” tycker jag man är en aning trångsynt. Alla använder inte samma terminologi, det är inte svart och vitt. Vi måste vara lite ödmjuka inför olika sätt att uttrycka sig. Har man inte en aning om vad test handlar om bara för att man slagit ihop “test” och “checka av” under ett och samma ord? Det tycker inte jag.
Henrik 2, jag är också nyfiken på hur du kan tycka testning är lätt. Speciellt smart, tids- och kostnadseffektiv testning som hittar alla dom rätta buggarna och som tydligt visar när man testat klart/tillräckligt.
Tack för förtydligandet.
Oj, intressant. Jag skulle kunna skriva en artikel om precis motsatsen. Jag har jättesvårt att hitta bra tänkande, passionerade testare. Alltför många manuella testare verkar aldrig kommit ur antingen “klicka runt tills något händer”-stadiet, eller “verifiera kraven”-stadiet. Den stora hopen utforskande testare lyser fortfarande med sin frånvaro på min radar (utforskande i ordets bredare mening).
Absolut. Därför är diskussionen efter en artikel, presentation eller vad som helst, oftast mer intressant än “fröet” i sig. Däri ligger lärdomarna.
Personligen tycker jag att det är väldigt hjälpfullt att dela upp terminologin i “checkar” och “tester” för att försöka tydliggöra vilken del av x-axeln man siktar på (syftar på Marick’s Testing Matrix i det här fallet). Skillnaden mellan tester som stödjer utveckling eller verifierar enskilda saker och tester som utforskar, ifrågasätter och ger upphov till ny kunskap om en produkt är för mig jättestor. Tror det är därför Gregory och Crispin ägnade ganska många sidor i sin bok till att tala om (och vidareutveckla?) detta, och det är därför Bolton jobbar hårt med att jobba in termen “check” för att vi lättare ska kunna sätta en etikett på tester i första och andra kvadranten. Genom att i olika gruppering (såsom denna) adoptera ny terminologi lite här och var kan vi motverka onödiga och “simpla” missförstånd och ta diskussioner direkt till nästa nivå (skippa klargörandefasen).
Jag är inte så säker på att jag håller med Scrum i detta. Ja, Scrum pratar om korsfunktionella team, men jag tror inte det är optimalt att ens sikta mot att alla ska kunna göra allt. Vi kommer alltid att ha och behöva spetskompetens för databaser, arktitektur, byggen, integration, testning, automatisering, verktyg och så vidare. Håller med om att det är bra att vidga vyerna, men inte i syftet att alla ska kunna hjälpas åt med allt. Vi mår bra av att ha lite skillnader i skillsets i våra team.
Hej!
Intressant diskussion! Jag vill inte peka finger åt folk här men jag ser en stor skillnad i kunskap i tråden och jag har några tips för vidare läsning.
Angående att testare bör utveckla sig själva rekommenderar jag Gerald M. Weinbergs serie ”Quality Software Management”. Redan i hans böcker från tidigt 90-tal (eller om det redan var sent 80-tal) så beskriver han nyttan att använda alla testarens sinnen och och olika kompetenser. Förvånansvärt mycket av det han skrev för över 20 år sedan är fortfarande “cutting edge” inom dagens mjukvaruutveckling samt testning och jag kan varmt rekommendera läsningen. För övrigt skulle jag vilja påstå om någon sitter och vägrar att ta på sig arbetsuppgifter eller är teknikmotsträvare så bör den personen byta jobb. Jag håller även med om att viss test automatisering lika gärna kan göras av utvecklare och jag håller helt med om att testare med utvecklarkompetens är väldigt värdefulla.
Checking vs Testing är för mig en avgrundsdjup skillnad. Basic checking är viktig (och automatiserad checking är i många fall nödvändig när man arbetar med t.ex. continous integration) men långt ifrån tillräcklig om man jobbar med någorlunda avancerad teknik. Testning är något väldigt mycket mer kreativt och avancerat och däför bör man hålla isär de båda termerna. Se för vidare läsning. Jag kan ha en förståelse för att man slår ihop orden ”checking” och ”test” under bara ordet ”test” precis som jag har förståelse för människor som klumpar ihop allt man gör på en dator med att man arbetar med ”data”. Återigen vill jag påpeka att jag inte vill peka finger men om man läser om test och deltar i diskussioner så lär man sig den vokabulär som används i test communityt.
Jag har själv suttit i projekt där jag fått leverad program som påståtts vara testad och klar och sedan har det visat sig att de har testat att starta programmet och gjort en ”check” men i själva verket fungerade programmet inte alls förutom att mer än starta det en enda gång (två ggr kraschade allt).
Att test yrket är har ett rykte att vara ett lågstatus jobb stämmer tyvärr fortfarande i vissa branscher och bland vissa beslutsfattare. Det brukar dock vara de företag eller avdelningar som har den synen som konkurreras ut. Bra testning idag är en jättefördel i konkurrensen och kan vara skillnaden mellan att flyta eller sjunka. Det kan vara skillnaden mellan att köpa en billig pryl eller en dyrare märkespryl som man vet är testad och kommer fungera. Men det finns också chefer som anser att utveckling är ett lågstatus jobb som enkelt kan outsourcas till billigaste möjliga indier. Min upplevelse är dock att testning får mer och mer erkännande då man ser att bra, utbildade testare gör att kvalitén på produkten ökar och projekten flyter på på ett bättre sätt.
jag sitter här vid datorn och stilla hoppas att Linda är den enda som läser min första kommentar och tolkar det som att jag kritiserar att hon inte använder sig av orden tester och checks.
Linda om det hade varit det budskap jag ville förmedla så hade det framgått mycket tydligare. För min del får du gärna kalla det kalkoner och tomater, for what i care.
jag använde mig av två olika ord (checkar och tester) för att tydliggöra skillnader på syften med dessa två och att det förutsätter olika egenskaper och kunskaper för att utföra.
Men för att inte förvirra dig så anpassar jag mig till ditt språkbruk så låt oss hädanefter kalla allt tester
min poäng var att en del tester medför andra fördelar när utvecklare gör dom:
“Att föra in detta under utvecklres uppgifter kan medföra att man kortar ner feedbackloopen, hjälper till en hållbarar och enklare design, ökat ansvarstagande av koden samt en stabilare mjukvara. Varför vill man inte ta vara på dessa starka fördelar?”
Min fråga kvarstår, varför vill du inte dra nytta av dessa fördelar?
vidare skriver du nu:
“Jag vill även poängtera att om man har en testare i ett Scrumteam och teamet ansvarar för att automatisera, så bör testaren sträva efter att jobba med detta lika mycket som utvecklarna. I Scrum ska ju alla kunna hjälpas åt med allt.”
Detta håller jag inte alls med om. Om man ska formera sig efter din logik att testaren ska jobba lika mycket med automatisera som utvecklarna så ska ju även testaren ägna lika mycket tid som utvecklaren med att skriva produktions kod och utvecklaren ska ägna lika mycket tid som testaren med Exploratory Test. Vad du förespråkar är likformighet (alla ska ha samma egenskaper och kunskaper) av alla personer i ett team. Detta förutsättar att du vet hur framtiden kommer att se ut och att du vet exakt vilka egenskaper som behövs för att lösa de uppgifter som kommer (för det finns inget oförutsett eller oväntat som kan hända). Jag tror att likformighet är en fara för teamets möjligheter att lösa de problem som kommer ligga framför dom. Att man ska hjälpa varandra i största möjliga mån är inget specifikt för Scrum utan det gäller generellt för väl fungerande team. Dock betyder det inte att alla ska göra lika mycket av allt eller att alla ska besitta samma egenskaper, min känsla är att det är väldigt få som förespråkar detta.
Jag tror att din poäng kan vara direkt förödande för ett team och jag vidhåller det jag tidigare skrev
“Låt utvecklare göra det jobb dom är bra på och låt oss testare det jobb dom vi är bra på. Lär er att utnyttja människorna i teamet på bästa möjliga och effektivaste sätt istället.”
Vidare skriver du att
“Jag lyssnade på Janet Gregory här om dan och hon uppmanar testare/agila testare att vidga sina vyer, lära sig nya saker och hon uppmuntrar mycket till att förbättra sina utvecklarsskills.”
Men du förespråkar ju inte att man ska vidga sina vyer eller lära sig nya saker. Du skriver ju att man ska lära sig teknik så att man kan automatisera and that is it!
Du hänvisar till Janet Gregory och på samma scen stog den stora allsmäktige profeten Henrik Andersson och pratade om just faran med likformighet av personer i team och att det vi bör eftersträva är mångfald och hur detta kan göra våra team väldigt mycket starkare (diversity in team compositon, kommer finnas en inspelning på öredevs web sida senare) . Så då måste allt jag skriver vara sanningen, eller hur?
Det är ju bara att gratulera dig till att du inte har svårt att hitta folk till den manuella intelligenta testningen. När jag anställer så har jag väldigt mycket svårare att hitta testare som kvalificerar sig till den typen av testning än var det är för mig att hitta någon som kan hjälpa till med att automatisera testningen.
Oj, riktigt roligt med sådant drag runt kommentarerna! Och tack för en bra artikel Linda.
Min filosofi är att låta de automatiserade testerna verifiera det som de är bra på. Det vill säga att verifiera hårda fakta så som beräkningar, api, tjänster m.m. Detta för att de manuella testarna ska kunna lägga all sin tid till de tester som kräver synintryck, mag- och fingertoppskänsla.
Min erfarenhet är att de med utvecklarkompetens absolut kan och skall göra stora delar av automatiseringen som en naturligdel av utvecklingen. Det skall helt enkelt finnas automatiserade tester som täcker den nyutvecklade/rättade funktionaliteten innan vi uppnått Definition of Done.
Men min erfarenhet säger också att för att bygga ett hållbart och förvaltningsbart automatiseringsramverk som verkligen testar på annat än kodnivå så krävs det erfarna testareautomatiserings speciallister som verkligen förstår test. Det behövs helt enkelt någon med testkompetens som pekar ut vad som skall verifieras och på vilken nivå de skall verifieras i de automatiseradetesterna.
För att uppnå detta så tillför vi någon form av abstaktionslager som möjliggör en uppdelning i automatiseringsarbetet. Utvecklarna skriver automatiseringskoden, testarna bestämmer vad som testas med automatiseringen och testautomatiseringsspeciallisterna bygger upp ett hållbart automatiserings-ramverk.
Och jag kan intyga att det är riktigt riktigt svårt att hitta duktiga Testautomatiseringsspeciallister! Det är min största huvudvärk just nu! Så om någon har något tips, så………..
Intressant diskussion, precis i linje med vad jag själv funderar på just nu.
Jag inbillar mig att jag kanske är en av de här “utvecklarna” ni pratar om. Dvs den sorten som fått smak för test och kvalitétsarbete och spenderar en stor del av min tid med att programmera automatiserade tester (‘checks’).
Att jag vill jobba på det viset kommer sig, för min del, naturligt av just den anledningen som Henrik (#1) anger. Dvs det är en självklar del av ett lättrörligt arbetssätt. Detta eftersom det skall bli teamets ansvar, som helhet, att skapa kvalitétsmässiga artefakter.
Tyvärr händer det ändå ofta att man inom ett team spontant delar upp sig i små silos kring “test” och “utveckling”. Två aspekter av samma uppgift om man frågar mig. Det kan vara så enkelt som att alla testrelaterade uppgifter får en annan färg på post-its än utvecklingslapparna och då bara plockas av “testarna”. Ett annat illaluktande symptom är att “testarna” inte blandas in i designdiskussioner eller analys på ett tidigt stadium, något jag vägrat gå med på sedan jag började jobba i testrollen.
På sistone har jag börjat fundera på om allt inte skulle bli bättre om man tog bort titeln “testare”. Istället kan man kalla alla för utvecklare och försöka odla och bejaka förkovring inom olika kompetensområden. Att någon kallas för “testare” gör bara att alla uppgifter som dyker upp som har med testning att göra automatiskt hamnar på testarens bord. Om han istället kallas för Kalle kanske någon ställer sig frågan varför just Kalle skall ta alla testuppgifter (som är av den typen att alla klarar av att göra dem).
Vad jag är ute efter här är alltså ett bredare samarbete inom team, mindre vi-och-dom-tänk (från alla håll), uppskattning för allas unika kompetenser samt spridning av den kunskap man kan dela med sig av.
Ok, skjut ner mig nu 🙂
@Ville: Håller med om att silos inte är bra. Håller även med om att det är en intressant tanke att helt enkelt kalla alla i ett team för “utevecklare”. Vet fler som använder termen på det viset och buntar ihop så kallade programmerare och testare under den etiketten. Och varför inte egentligen, oavsett specialitet så bidrar vi ju alla (i bästa fall) till “utvecklandet” av produkten.
Ska nog tydliggöra det jag skrev där tidigare… Jag menar nog att om man ska bunta ihop folk under termen “utvecklare” så bör alla som har med produktutveckling in under denna, dvs även arkitekter, designers, databasspecialister, kravställare, projektledare osv.
Fördelen är att potentiellt kunna riva ner lite silos. Faran, som jag glömde nämna, är att i och med att man använder ett ord med ganska inarbetad mening (utvecklare), så kan man få svårt att ändra meningen i ordet. Dvs, att kalla en testare för utvecklare kan vara bra på sitt sätt, så länge det inte per automatik innebär att denne nu då måste börja knacka kod för att han/hon nu är “utvecklare”.
Ja, vilken uppslutning kring ett hett ämne. Dock kan jag tycka det är väldigt mycket olika saker som avhandlas i kommentarerna som inte är kärnan av problemet. Hur rekryterar man tekniska testare?
Vad är en teknisk testare?
För att komma till kärnan måste vi först kolla på vad man menar med teknisk testare. Här vill jag gärna dra en parallell till min egen situation. Jag kom precis ur ett stort projekt där jag var en del av ett litet team testare. Projektet är ett stort systemintegrationsprojekt med många saker som är viktigt för kontextet som jag inte tänkte gå in på i detalj. Jag hade tidigare erfarenhet av systemlandskapet när jag började jobba i projektet, vilket innebar att jag tog en mer “tekniknära” plats i teamet med fokus på integrationstestning. Faktum är att spannet mellan mig och mitt team var hyfsat stort i hur “teknisk” testningen vi utförde var genom att jag gick loss på både databasscript, loggar och halvautomatiska internutvecklade testverktyg. De andra hade ganska mycket fokus på användningen och kravbilden på systemet.
Om jag sen tittar åt andra hållet, finns testautomationsspecialister som oftast har en viss plattform eller område som vanligtvis testas med deras automation. I mitt projekt tog vi hjälp av sådana specialister också.
Så när Linda nu säger:
““Technical tester”, “Automatiseringsexpert” och “Testingenjör” är eftersökta kompetenser. Alla vill ha dom, alla behöver dom.” så tycker jag inte man ska dra alla dessa över en kam, då jag kan se mig själv som teknisk testare, men jag är ingen automationsspecialist.
Jag tror att det finns många varianter av dessa, och de kommer i väldigt olika smaker, med olika domänkunskaper och erfarenheter. Säg tex att du då söker någon av dessa roller inom domänen telecom, som i sig är en väldigt teknisk domän. Hur särskiljer man då en “Technical tester” från en testare som mest är bevandrad inom domänen som jag själv kunde varit i fallet ovan? För min egen del så fanns båda på plats vill jag bara klargöra. Men att skilja på domänkunskap och teknisk kunskap, är det viktigt? Där skulle jag nog säga att det viktigaste är tekniska kunskapen och intresset. Man kan alltid lära upp domänkunskapen om bara intresset, möjligheten och viljan att lära sig finns på plats. Teknisk kompetens är en fallenhet i mina ögon som helt enkelt grundas på hur lätt man tar till sig tekniska detaljer och tillvägagångssätt.
Så vad är en automatiseringsexpert? Skulle man kunna säga att det är en teknisk testare med en djupare domänkunskap på den plattform man automatiserar? Det tror jag faktiskt inte. Jag tror att det ligger mer åt hållet att vara programmerare och ha en djupare förståelse för testning och vad det tillför projektet i form av snabb feedback.
Vilka är det då som är svåra att få tag i?
Ja det är knäckfrågan. Jag tror det helt enkelt handlar om att man har ett för snävt spektrum som man letar inom när man säger att det ska vara en testare som har massa års erfarenhet av alla faktorerna (1) programmering på rätt plattform, (2) tekniska domänen och (3) den ännu mer tekniska nisch inom domänen som man som företag verkar inom.
Roligt att det blev en diskussion utav det jag skrev. Mycket det jag skrev är en ren och skär provokation för att få fram en diskussion. Jag står fullständigt för att jag tycker ISTQB cert skall bort eller göras om dramstiskt. Som det var utformat våren 2005 när jag tog certifikatet var det inte mycket att hänga i julgranen.
@Johan Jonasson. Test som lågstatus yrke. Tyvärr finns det forfarande utvecklare som tycker att testare är lågstatus. Åldern och erfarenheten som utvecklaren har spelar ingen roll. En testare som jag känner fick kommentaren “Vi utvecklare hatar Er testare!”. Utvecklaren som sa detta var både ung och ny utexeminerad. Sedan kan man fråga hur allvarligt denna kommentar var. Så vad det gäller statusen har vi mycket att jobba på. Tror de flesta utvecklarna har insett vikten att ha med en duktig testare i teamet då applikationerna blir mer och mer avancerade.
@Stefan Thelenius skriver om rätta egenskaper och verksamhetskännedom, dessa två gäller för både kravaren, programmeraren och testaren. Jag tycker dessa egenskapar genomsyrar hela IT-verksamheten. Så att de skulle vara några speciella egenskaper för testare håller jag inte med om.
Är det lätt att testa ?
Japp, speciellt min kod som jag skriver. Behövs inte mycket domänkunskap för att inse att allt är åt helvete. Skämt och sido. Om man kan ta en 3 dagarskurs skriva ett certifikat och sedan kalla sig testare. Ja då är det lätt att testa. Dock kommer resultatet av testningen som har utförts troligtvis vara skit och totalt värdelöst. När jag skriver testare menar folk som manuellt testar via GUI (Exploratory eller Skriptat spelar ingen roll).
Att testa för att få fram rätt information om systemet är betydligt svårare än vad en 3 dagarskurs kan ge. På programmeringssidan snackas det mycket om craftmannaship och det är något som borde diskuteras inom test.
Hoppas att ni förstår att jag skrev med en provocerade framtoning för att få en diskussion.
Ja, det finns såklart den typen av människor i alla team och organisationer, och inom alla “skrån” (inte bara programmerare och testare) men jag tror att många av dessa är, precis som i ditt exempel, juniora i sin roll. När man varit med ett tag och får lite hum om hur saker och ting hänger ihop och hur ett team eller människor i allmänhet fungerar i interaktion med varandra, så tycker jag mig kunna se en ökad förståelse för vilken nytta man kan ha av olika kompetenser.
Sen hänger det såklart mycket på individen. I en organisation med en massa “testare” som bara suttit på samma stol och gjort vad de blivit tillsagda sedan dagen de tog sitt ISTQB-cert och därmed blev ett “proffs”… ja, där förstår jag om test är och förblir ett lågstatusyrke. Men i organisationer där silo-tänket är på väg bort, ja där ser jag bara två möjligheter: Testarna blir erkända för värdet och nyttan som deras kompetens tillför, eller testarna blir utbytta för de kan inte klara av att tänka själva och ta egna initiativ i sitt sökande efter kvalitetsrelaterad information (oavsett om det är med hjälp av verktyg eller ej).
Detta gäller inte bara för testare. Jag tror inte tiden är ute för testare som inte kan programmera. Jag tror att tiden är ute för alla som bara kan fungera i silos. Oavsett roll, oavsett om vi kallar det Scrum eller vattenfall.
Ville, Roligt att höra en “riktig urvecklares” syn på det hela!
Jag håller med dig i stort.
Själv är jag som en pendel ang titlars vara eller icke vara. En del i mig håller helt med dig titlar uppmuntrar till att stereotypa människor vilket ofta är väldigt hämmande.
En annan del i mig kan se en nytta med att ha kvar titlar för att inte darwins teori ska slå till och att vi får en likformighet på grund av att de som har majoritet av liknade egenskaper ska ta övertaget och bara vilja ha mer av samma. Jag borde verkligen ta och bestämma mig i denna frågan men jag är helt enkelt inte där än. Å andra sidan kan man ju säga att vi har använt oss av titlar ganska länge nu och det har i ett fabrikssamhälle fungerat väl men inte lika lyckat inom vår bransch så varför fortsätta när vi inte fått ordning på det ännu?
En sak som jag tror är väldigt farligt är om vi ska kalla alla för samma sak så ska vi inte välja ett etablerat ord som tex utvecklare som i sig redan har en stereotyp kopplat till sig. Utan vi bör då välja något annat som inte idag är kopplat till något vi refererar till.
Henrik
jag hänger inte riktigt med
“Om man kan ta en 3 dagarskurs skriva ett certifikat och sedan kalla sig testare. Ja då är det lätt att testa.”
Bara för att man kallar sig testare så innebär det väl inte att man är en testare. Bara för att kallar mig raketforskare när jag är ute på krogen så innebär det inte att jag är detta.
Det finna alltid folk som svärtar ner och skamfilar yrken och därför är det viktigt att vi som håller oss till en högre standard än så inte accepterar detta utan aktivt jobbar med att slå hål på myter och visar på vad testning egentligen innebär. Vi ska absolut inte gå i fällan och kallar dessa andra för testare eller erkänner att dom gör testning det sänker bara oss själva. Så nä en som bara tagit en ISQB certifiering och inte har något annat att komma med är varken en testare eller utför testning. Lika lite som att jag är en formel1 förare bara för att jag har körkort. Det är fortfarande inte lätt att testa.
@Henrik: Det är lättare att test än att utveckla samma funktion enligt mig.
och när får man kalla sig testare ?
Henrik,
själv är jag inte kapabel att göra den jämförelsen. Tycker också att det är en rätt ointressant jämförelse då jag ser det som två olika discipliner och som kräver olika egenskaper. Sen är det väl inte en tävling mellan test och utveckling vilket som är svårast?
Jag kan bara konstatera att jag inte tycker det är lätt att testa
En heuristic för när man kan börja kalla sig testare skulle kunna vara när andra personer som har trovärdighet och respekt i branschen börjar kalla dig testare.
Tror denna tråd blir en framtida klassiker i sitt sammanhang (sverige)…tack Linda och alla andra.
@Sigge
Vilka är det då som är svåra att få tag i? Ja det är knäckfrågan. Jag tror det helt enkelt handlar om att man har ett för snävt spektrum som man letar inom när man säger att det ska vara en testare som har massa års erfarenhet av alla faktorerna…
Helt riktigt, i mitt tycke är personliga egenskaper i många fall viktigare än gamla meriter. Min poäng är att med rätt inställning och egenskaper kan man gå hur långt som helst (gäller nog alla yrken), så uppmuntra till kreativitet och våga misslyckas!
@Henrik#2
@Stefan Thelenius skriver om rätta egenskaper och verksamhetskännedom, dessa två gäller för både kravaren, programmeraren och testaren. Jag tycker dessa egenskapar genomsyrar hela IT-verksamheten. Så att de skulle vara några speciella egenskaper för testare håller jag inte med om.
Kanske Ville har rätt att vi alla är Utvecklare, kanske inte…jag tror att som (system)testare ganska sent i utvecklingskedjan (oavsett vattenfall eller agilt) för komplexa system, så behöver testare kanske lite mer av vissa egenskaper än exempelvis än en kravanalytiker. Tror nog att det finns en viss skillnad mellan olika IT-roller även om den kan vara hårfin i vissa fall. Håller med om att verksamhets/domänkunskap är lika viktig oavsett IT-roll. Personligen har jag bytt domän fyra gånger under min karriär (medicinteknik, telekom, betalningar, försäkringar) och insett att utan domänkunskapen blir det svårare att prioritera viktiga tester och förutse problem som kan inträffa under produktionslika förhållanden.
Hoppas att ni förstår att jag skrev med en provocerade framtoning för att få en diskussion.
Det lyckades du bra med, dock inte självklart att se ironin i texten utan att känna dig personligen.
Det verkar som både tekniska testare och bra testare är sällsynta. Jag tror därför att ingen utav dessa betraktas som lågstatus eller har dåligt betalt…
Om man lyckas kombinera det tekniska med testandet så tror jag man kommer gå långt…och min slutpoäng är att du behöver inte 240 högskolepoäng och/eller 20 års erfarenhet…börja smått, lyckas/misslyckas/lär och fortsätt så 🙂
Tråden fick även lite internationell uppmärksamhet igår på Twitter. Tack Google Translate. 😉
@Johan “Personligen tycker jag att det är väldigt hjälpfullt att dela upp terminologin i “checkar” och “tester” för att försöka tydliggöra vilken del av x-axeln man siktar på”
Det tycker jag också… men jag tycker även att man bör kunna prata om “testning” och “checkar” generellt och som en klump genom att använda ordet “test”.
@Johan “I Scrum ska ju alla kunna hjälpas åt med allt.” “Håller med om att det är bra att vidga vyerna, men inte i syftet att alla ska kunna hjälpas åt med allt. Vi mår bra av att ha lite skillnader i skillsets i våra team.”
@Henrik “Om man ska formera sig efter din logik att testaren ska jobba lika mycket med automatisera som utvecklarna så ska ju även testaren ägna lika mycket tid som utvecklaren med att skriva produktions kod och utvecklaren ska ägna lika mycket tid som testaren med Exploratory Test. ”
Jag tycker väl egentligen någonstans mitt emellan. Jag tycker att vi ska sträva efter att kunna jobba med vad som helst på scrum-tavlan men i verkligheten är det väl oftast inte så det blir och jag tycker det har fungerat som bäst när det varit lite skillnad men där alla verkligen hjälps åt då det behövs (har oftast varit utvecklare som hugger tag i test-aktiviteter).
@Henrik “Att föra in detta under utvecklres uppgifter kan medföra att man kortar ner feedbackloopen” “Min fråga kvarstår, varför vill du inte dra nytta av dessa fördelar?”
Därför jag anser att feedbackloopen blir ytterligare kortare om du har en testare, som vet vad som ska automatiseras (=har koll på testfallet = har koll på kraven på automatiseringen) eller för den delen annat test stöd som behöver utvecklas. Vi behöver inte som testare kravställa till en utvecklare vad vi vill ha gjort utan vi gör det själva. Kan loopen bli kortare än så?
Jag ser visst fördelar med att låta utvecklarna sköta allt som har med utveckling av teststöd och automatisering att göra, det är så vi gör hos oss idag. MEN jag skulle hellre vilja ha någon som kan test som kan göra det.
@Henrik “Men du förespråkar ju inte att man ska vidga sina vyer eller lära sig nya saker. Du skriver ju att man ska lära sig teknik så att man kan automatisera and that is it!”
Ja, i den här artikeln. Men jag anser att det finns mycket att lära sig där ute! Om jag antytt något som pekar på att detta är det enda jag tycker man ska lära sig så ber jag om ursäkt, för det tycker jag inte alls.
@Henrik “Du hänvisar till Janet Gregory och på samma scen stog den stora allsmäktige profeten Henrik Andersson och pratade om just faran med likformighet…”
Jag lyssnade inte på henne på Öredev så jag såg tyvärr inte dig. Hon var hos oss och pratade. Jag har inte en aning om vad hon tog upp vid det tillfälle du hänvisar till.
@Henrik “Det är ju bara att gratulera dig till att du inte har svårt att hitta folk till den manuella intelligenta testningen.”
Nej, nej, nej… det sa jag inte. Jag sa “Men där har jag inte riktigt lika svårt att hitta folk.” Alltså jag har svårt med det också men inte riktigt lika svårt. 🙂 Men jag önskar att jag hade en svärm av superduktiga testare inom alla områden som det bara var att välja och vraka mellan. Det ska jag önska mig i julklapp tror jag. 😉
@Sigge “Dock kan jag tycka det är väldigt mycket olika saker som avhandlas i kommentarerna som inte är kärnan av problemet. Hur rekryterar man tekniska testare?”
ja, verkligen men det tycker jag är bra. Det är kul att se att det blir lite diskussion.
@Sigge “““Technical tester”, “Automatiseringsexpert” och “Testingenjör” är eftersökta kompetenser. Alla vill ha dom, alla behöver dom.” så tycker jag inte man ska dra alla dessa över en kam, då jag kan se mig själv som teknisk testare, men jag är ingen automationsspecialist.”
Jag tycker också det är olika saker men i artikeln blev det mest fokus på automatisering. Jag tycker alla är ungefär lika svåra att hitta bra folk för.
@Henrik #2 “Vi utvecklare hatar Er testare!”
Stackars den personen. Jag får ofta höra “Tack för att ni finns”, “Vad skulle vi göra utan er”, “Vi vågar inte släppa nått förrän ni tittat på det” etc.
@Stefan “Det verkar som både tekniska testare och bra testare är sällsynta. Jag tror därför att ingen utav dessa betraktas som lågstatus eller har dåligt betalt…”
Ja, som jag skrev här ovan har jag inte lätt att hitta bra testare, bara mindre svårt. Jag upplever också att på de ställen jag varit där det finns riktigt duktiga testare anses dom inte som någon lägre stående varelse. Jag har hört mycket positivt och jag har även upplevt att utvecklargrupper varit avundsjuka på testgruppen (kanske inte är helt och hållet i linje med denna diskussion men jag tycker det är lite kul att nämna). Men det varierar nog väldigt mycket från ställe till ställe.
Fair enough, men jag trot att du riskerar att hamna i många liknande diskussioner och missförståndssituationer om du väljer att använda ordet test för att beskriva två olika saker. Dvs om check är en typ av test, och test är en annan typ av test.
Ett alternativ skulle kunna vara att kalla checking för checking, och testning för “utforskande” testning. Men då hamnar man direkt i en annan potentiell missförståndssituation. Men kanske bara hos folk som ser utforskande testning som något man “gör” och inte som ett sätt att tänka.
Annat alternativ: tänkande testning och checking? Fast kan man verkligen undgå att tänka? Finns det någon bra översättning av “sapient testing” som James Bach använder som term? Vet inte.
Tills jag har en bra lösning så väljer jag att inte klumpa ihop checking och testing under en och samma etikett. Först när jag ser ett tydligt genomslag i industrin (att gemene testare gör skillnad på de två) kan jag tänka mig att blåsa “faran över”.
Tack för en bra diskussion.
När jag rekryterat så är det svårt att hitta bra testare. Bra betyder att de gick igenom våra tester på test kunskap, hur man testar och mindset kring testning m.m. Det finns få universitets utbildningar och få yrkeshögskoleutbildningar som har testfokus, därmed få studenter.
Som utvecklare med automatiseringsfokus finns det fler att välja bland, om de inte behöver viss kunskap om testning också, vilket jag anser är en god egenskap. Det finns ju många universitetsutbildningar med programmeringsfokus och det är många som programmerat sedan barnsben. Det finns färre som testat programvara sedan barnsben.
Sedan tror jag att det finns få utvecklare som vill fördjupa sig både inom testdomänen och utvecklardomänen. Jag har t.ex programmerat i 20 år men fördjupar mig mer inom testning än utveckling även fast jag håller mig ajour på tekniker och provar nya programspråk.
Angående tester vs checkar så förstår jag Lindas idé om att bunta ihop dem som begreppet test. I vissa diskussioner så tappar man fotfäste eller att fokus styrs om till fel sak när man gör denna distinktionen. Men jag försöker så ofta jag kan och när det är rätt tillfälle förtydliga skillnaderna. Risken är ju att man vill göra det lät för sig, så varför inte kalla allt för “smurf”? En av anledningarna är ju för att vi arbetar olika med dem. Om man endast utför checkar så missar man hela testbiten med sådant som är okänt. Om man endast testar så missar man troligtvis värdeful information av vad som checkats av och vad vi behövt verifiera. Det är dock högst troligt att man göra båda två samtidigt, men det ena eller det andra (eventuellt båda) är strukturerat.
Jag ger mig inte in i ISTQB diskussion här. Jag har skrivit min tankar i artikeln Testers greatest nemesis (http://thetesteye.com/blog/2011/05/testers-greatest-nemesis/) om detta.
Vad är en testare?
Testzonen.se är utan att överdriva en väldigt intressant blog som jag besöker så ofta jag kan. Gillar tonen mellan dem som skriver kommentarer samt artiklarna.
Det jag har upptäckt när jag nu, återigen letar efter ett nytt jobb är att branchen försöker att skapa ett teoretiskt ramverk för ett yrke som enligt min mening är helt och hållet empirisk.
Artikelförfattaren efterlyser olika typer av testare. Alla med olika typer av specialisering.
Hos min förra arbetsgivare så var testare en naturlig evolution från att vara utvecklare. Så bör det vara. Den anstälde måste förstå att det är ett steg i rätt riktning och inte en nedgradering.
Tyvärr så blir man nuförtiden certifierad testare efter en 3 dagars kurs, oavsett bakgrund. Försök övertyga en person som har studerat 4 år på universitet samt jobbat lika många år med utveckling ta steget till att bli testare. Kommer inte att hända och detta betyder att väldigt få testare med utvecklar bakgrund kommer finnas.
Skulle kunna gå så långt att påstå att testning är ett hantverk. En testare är en testare oavsett vad testobjektet är. Det som kategoriserar testaren är kunskapsnivån om verksamheten.
Skulle nog kunna testa Bibeln om jag hade en bra testspecifikation. 🙂
Citat från utvecklare.
”T.o.m. En apa kan lära sig att göra ert jobb.” – Vad svarar man ?
Med vänlig hälsning
/P
.
Hej Linda.
Är det kurser och utbildning som saknas?
Under alla mina år som testare har jag aldrig gått en kurs som handlar om testning. Dock otaliga kurser som har med verksamheten att göra. Som Stefan Thelenius skriver så har jag sökt annan information på nätet.
Är det fortfarande testyrkets rykte om att vara ett lågstatusjobb som sätter käppar i hjulen?
Detta påstående har jag stött på för första gången på testzonen.se. Hos min förra arbetsgivare så brukade karriären se ut som följande:
Utvecklare
Integratör
Verifierare (Testare som håller på mest med kod check. Jobbar nära utvecklaren. Nästan Test Driven Development)
Testare (Testar End2End subsystem)
Systemtestare (Testar hela härlighetet under driftförhållanden)
Är det insnöat sysätt för hur test ska bedrivas som gör det svårt att ge sig in i framtiden på bred front?
Detta är nog ett samtalsämne i sig.
Testning bör ske på en bredare front. Det finns så många olika aspekter av test. Kod checkar är också test och bör utföras av personer som har djupare kunskaper i systemutveckling medans UAT (User Acceptance Test) bör göras av slutkunden eller personer som kan verksamheten. Däremellan finns det ett antal ”flavors” av testning. Veritabel smörgåsbord bestående av testspecialister.
Eller är det så att tekniska tester och automatisering är fel väg att gå?
All test är av godo. Min testerfarenhet baseras på ett enormt system som var omöjlig att kvalitetssäkra utan testautomatisering av legacy funktionalitet. Mellan varje sprint tillkom 200-300k rader kod (vilket i sig säger inte mycket) samtidigt som refactoring skedde på gammal kod. Omöjligt att täcka alla nya testfall och legacy utan automatisering.
Med vänlig hälsning
/P
.