Gå till innehåll

Kategori: Testing

Getting good at testing. My reflections

Publicerat den

Äntligen dags för vår första Peer Conference i test

Helgen 11-12 november samlades ett tappert gäng på Högberga gård, Lidingö för att i två dagar diskutera testdesign. Konferensen har som mål att deltagarna ska få presentera sin egna erfarenheter och alla får sen ställa frågor och kommentera. Skillnaden mot "vanliga" konferenser är att dn som presenterar säger det han ska och sen ställs det ett par frågor för sakens skull. I vårt fall är det tvärtom, presentationen tar mellan 20 och 30 minuter och den efterföljande diskussionen för de först två presentationerna tog en dryg timme för varje presentation. För första gången på länge känner jag att vi verkligen har en diskussion och och utbyte av värde. Förhoppningen är att detta första mötet följs av åtskilliga liknande möten.    

Till vår hjälp hade vi testgurun James Bach som troligen är den som deltagit i flest liknande konferenser i USA och England. James började med att berätta reglerna för mötet vilka kan sammanfattas som:

1. Alla presentationer bygger på egna erfarenheter

2. Allt som sägs på mötet får föras vidare

3. Varje presentatör får presentera sin sak utan att bli avbruten

4. Efter detta följer diskussionsstunden där övriga deltagare ställer frågor eller kommenterar det som sagts. Vi bestämmer själva hur länge diskussionen pågår genom att sluta ställa frågor.

5. Agendan för mötet och inbjudna deltagare bestäms av Content Owner: den person som arrangerar mötet. Moderator som håller reda på diskussioner och frågor kallas i vårt fall Facilitator.

Deltagare denna gång var:
Content Owner: Torbjörn Ryber
Special Guest: James Bach
Deltagare: Siv Carlsson, Klaus Andersson, Daniel Nordling, Pablo Garcia (han som har många strängar i sin villa enligt CS 10 nov), Jörgen Damberg, Anders Claesson, Frederik Rydberg, Michael Albrecht, Örjan Svensson, Rolf Nilsson, Ann-Charlotte Bolander

Jag fick äran att inleda konferensen med en kort presentation om test av en kreditratingfunktion. Efter en tjugo minuter lång beskrivning av hur testdesign fungerade otroligt kraftfullt för att hitta fel i kraven innan någon kodning hade startat följde en timmes frågestund. Verkligen kul att alla är så engagerade. 

Klaus Andersson berättar om hur de använder sig av all-pairs för att få en rimlig mängd testfall då de får nya versioner av elektroniken i bilar. Spännande att höra om all funktionalitet som finns kopplat till bilen i form av signaler från krockkuddar, bensintank, GPS etc och automatiska funktioner som skickar SMS vid en krock. James visade en demo av ett nytt verktyg för att ta fram parvisa tester som heter PICT. 

Dags för nästa presentation om Free User Testing på Maquet.  Frederik Rydberg berättar hur de kompletterar de skriptade testerna som krävs av FDA (USAs kontrollorgan för medicin) med fria tester. Vi hade en mycket lång diskussion som kom in på fördelarna och nackdelarna med utforskande testning. Det var så intressant att vi beslutade oss för att låta James presentera sina erfarenheter av utforskande testning nästa dag.

Lördagkvällen bjöd på en utsökt trerätters middag, jacuzzibad, vedeldad bastu, whisky i Kinasalen, nytt försök med vedeldat bastu och efterföljande brankårsbesök. Brandmännen påpekade att de var mitt i lördagsfilmen och bad oss att i framtiden använda den eluppvärmda bastun istället så att de kunde åka hem och se hur filmen slutade.

Söndagen började med nypressad apelsinjuice, bacon och kaffe för att skaka liv i våra trötta kroppar. Efter det gjorde vi en check-in där alla fick berätta om upplevelsen av gårdagen och förväntningarna inför dagen. 

James berättade om ett lyckat projekt där Exploratory Testing var sättet de arbetade på. Fokus var scenariotester som beskrevs i form av charters dvs en översiktlig beskrivning med data, förberedelser och variationer. Till testutförandet och analysen av testerna användes flera mycket användbara verktyg. Allt testarna gjorde inklusive anteckningar loggades med hjälp av Spector (spelar in vad som händer  på skärmen, 99 USD) så att testledaren kan läsa och analysera i efterhand. Loggfilerna analyserades via Excel för att se testtäckning. Exempelvis kan du be utvecklarna att skriva ut väldigt detaljerat till loggen, att numrera alla funktioner eller objekt och utifrån loggfilen se vad som använts.

Dessutom finns Strings som hjälper dig att dumpa all text från en databas för att sedan analysera den. Beskrivningar av verktygen och länkar till verktyget hittar du på James blog.

Sista presentationen är Pablo Garcia som berättar om test av ett avancerat telefonisystem. Problem han hittade var att dokumentationen av kraven var undermålig. Kraven var inte granskade och samma dokument existerade i flera olika varianter fast det på revisionsbeteckningen var samma datum och version. Första åtgärden blev att skaffa kontroll över kraven och utbilda alla i CM. Nästa steg var att besöka fabriken som tillverkade enheterna fysiskt och där införa manuell kontroll av monteringen. Följande steg var att organisera test, uteckling, dokumentationsstruktur och processen som helhet. Allt var väldigt formaliserat och alla testfall beskrivna i detalj. Resultatet blev att komponentens kvalitet ändrades från instabil till extremt stabil. Fortfarande två år senare var komponenten väldigt stabil men då inga script eller testfall hade uppdaterats hade kvaliteten fömsämrats till viss del. Men på grund av regressionstesterna kunde man ändå hålla en bra nivå.  

Den efterföljande diskussionen handlade mycket om hur detaljerad information som måste sparas för regressionstester. I detta fall fanns det 500 sidor detaljerad testfallsinfo eftersom det inte fanns möjlighet att få bra eller ens halvbra testare i framtiden. Vi inser att dokumentation är ett bra ämne till nästa konferens.

Vi avslutar med att diskutera framtiden och ser alla fram emot nästa gång vi träffas. James lovar att återkomma gratis för att facilitera möten i framtiden. Allt ser lysande ut!      

Publicerat den

Hur kommer det sig att fokus för automatisering av tester ligger på användandet av dyra kommersiella verktyg som mycket sällan ger någon vinst åt andra än verktygsleverantörerna? Få är de som verkligen lyckats tjäna något i det långa loppet medan historierna om misslyckanden duggar tätt. Möjliga faktorer är en massiv marknadsföring samt en brist på alternativa synsätt hos oss testare. Jag vill därför presentera ett alternativt synsätt som kallas agil automatisering.

Agil automatisering handlar om att vi istället för synsättet att verktygen ska ersätta oss manuella testare genom att utföra samma tester automatiskt, så är verktygen ett sätt för oss att utföra tester som är svåra eller omöjliga att göra manuellt. Ett exempel är verktyg för prestandatest. Det är i princip omöjligt att simulera trafik utan någon sorts verktyg - där funkar faktiskt de kommersiella bra så länge det finns experter som sitter bakom spakarna. För mig som testare kan det handla om att jag vill lägga upp 200 användare i min testdatabas via det grafiska gränssnittet - här kan det passa bra med ett litet script. Det kan också handla om att analysera loggfiler med tusentals rader och markera det som verkar konstigt. Något jag skulle ha velat ha i ett nyligt projekt var ett sätt att själv ställa frågor till en komponent utan att ha det grafiska gränssnttet klart samt att få ut svaren och skriva dem på ett aptitligt format. Här behöver jag någon som kan hjälpa mig med det tekniska - troligen en utvecklare i projektet. James Bach pratar om Toolsmith - en verktygssmed - som kan hjälpa oss med den här typen av verktygsbyggande. Oftast löser vi problemen med hjälp av gratisverktyg eller hemmabyggen. Nyckelorden är snabbt, billigt och omedelbar användning.

Jag har bara nosat litegrann på detta otroligt intressanta ämne men hoppas att kunna förkovra mig vidare. Letar efter någon med programmerarbakgrund som gillar test och vill jobba med testautomatisering som INTE handlar om att använda dyra kommersiella verktyg. Jag efterlyser talare som jobbat med egna verktyg och vill prata om hur det lyckats.

För den som vill börja själv finns gratisverktygen Canned Heat och Holodeck Lite att hämta hem från James Whittakers sida. AllPairs och PerlScript är två verktyg skapade av James Bach. Allpairs skapar testfall för alla par av värden mellan variabler PerlScript hjälper dig att skapa testdata, exempelvis en sträng av ett visst antal tecken eller alla ASCII-tecken.

Läs en utmärkt artikel på engelska om Agile automation

Publicerat den

(Kommentar till artikel i Computer Sweden 16 juni 2006) Den rubriken fick mig att haja till. Liksom meningen "Det finns för många inkompetenta testare eftersom det främst är utvecklare som blivit över som får hålla på med sådant" Syftet var att den provocerade läsaren omdelbart skulle slå upp och läsa hela artikeln och det lyckades nog tror jag. Trist är nog det sista jag skulle säga om mitt eget jobb som jag tycker är otroligt spännande och givande, så spännande att jag under tiden jag är föräldraledig läser mer på egen hand och skriver den här bloggen. I artikeln finns frågan hur utvecklarorganisationen ska öka statusen för testning och därmed kompetensen för testare. Jag tror att det är tvärtom - om vi testare blir bättre på det vi gör så ökar vår status. Sen står det att ITIL garanterar att man tänker på kvaliteten, Jag uttryckte mig nog mer som att ITIL visar att man reflekterar över hur man arbetar och det är viktigt för kvalitetstänkandet. Jag har bara läst om ITIL i pressen och inte själv implementerat någon av processerna och vill inte framhäva mig själv som någon sorts expert. Jag inser hur svårt det är för mig att uttrycka vad jag tycker genom någon annans alster i form av en artikel. Inser att en artikel måste han någon sorts vinkling för att bli intressant, denna gång inkompetensen hos min egen yrkesgrupp. Inser efter att ha läst igenom artikeln en tredje gång att det säkert finns många som kommer att bli upprörda av vad som står där och säkert en hel del som kommer att nicka instämmande. Nu frågar ni er vad jag egentligen har sagt eftersom det i artikeln står att bara de sämsta utvecklarna hamnar hos test. Min åsikt är att det under lång tid varit så att nyanställda och personer som inte kommer från IT-sidan har tildelats rollen testare och att de sedan utan någon form av utbildning förväntas göra ett bra jobb Nej, jag tror inte att det finns speciella personer med medfödda talanger som utan vidare blir testproffs utan att anstränga sig. Utbildning, övning, teknisk kompetens och en vilja att lära sig är essentiella ingredienser för att bli en bra testare. Jag blir förvånad då många testare jag pratar med erkänner att de aldrig öppnat en bok eller läst en artikel om test. Vi måste dessutom för att bli riktigt bra känna till grunderna i utvecklingsprocesserna, modellering och helst lite databaser. Och självklart har jag en stor mängd mycket kompetenta kollegor både på och utanför min egen arbetsplats och tycker inte att alla utom jag själv är idioter. Det hoppas jag att min blogg och min bok visar.

/Torbjörn

Publicerat den

Först och främst gillar jag inte beteckningen icke-funktionell. Vadå icke-funktionell, vad är det som inte fungerar? prestanda och säkerhet är det icke-funktioner? Att man måste logga in, att man bara kan se vissa delar av ett system eller vissa delar av databasen är typiska behörighetsfrågor som jag räknar till "säkerhet". Är det icke-funktioner? Jag har läst en del försök till alternativa benämningar: kvalitetsfaktorer/egenskaper(inte så illa), para-funktionella delar(hmm, paralyserad, para-normal(utanför det normala enl SAOL), paraply..nja kanske inte), supplementary requirements (RUP) "kompletterande krav" - kompletterande till vadå? Jag fastnar nog för kvalitetskrav - det säger mest. Nån annan som har ett bättre förslag?

Och nu till frågan varför det är så svårt att testa dessa krav. Det första som slår mig är att det är för att de sällan eller aldrig finns nerskrivna. Om det nu skulle finnas något på pränt så är det oftast otillräckligt, tvetydigt, motsägesefullt eller kanske en blandning av allt ihop. Så vi får börja med att ta fram kraven genom att intervjua de olika intressenterna, som inte heller de vet vad de vill ha eller hur de ska fråga efter det de tycker om. Läste precis i boken "Exploring Requirements" (rekommenderas varmt - finns på bla Adlibris.se) att vårt mål är att ge kunden vad de behöver inte vad de tror att de vill ha - då blir de mest nöjda. Intressant vinkling på problemet. Lyssnade på en lysande föreläsning av Andreas Granqvist om tillgänglighet på NFI Testforum. han spetsade till det genom att påpeka att användares beteende kan studeras som man gör med djur men räkna inte med att få nåt vettigt ut av dem vad gäller vad de vill ha.

Säg att vi nu skulle ha riktigt bra krav nedskrivna, hur bra skulle vi då kunna testa dem? Svaret blir nog att vi som icke-specialister inte skulle göra ett specielt bra jobb. Om vi tar exempelvis användbarhet, visst kan vi med hjälp av diverse checklistor kolla att knappar och texter stämmer med standard men användbarheten i sig - det blir nog mest våra egna åsikter om vad vi tycker är bra snarare än vad som är rätt eller fel. Och vad är våra åsikter som amatörer värde mot designproffsen som byggt systemet, nej det går inte. Här behöver vi specialister och kanske ett användbarhetslabb. Kolla in FunkaNu Säkerhet, prestanda eller robusthet då? Då krävs det verktyg, teknisk kunskap och säkerligen en bättre testmiljö än den vi testar på just nu. Vad ska vi då göra? Nu spånar jag fritt, har inte gjort någon djupare analys men tänkt en hel del.

1. Steg ett är att vi måste veta vad vi behöver för krav på kvalitetsfaktorerna. Vilket underlag krävs i vårt projekt? Jag kan tänka mig en prioriteringslista där beställaren säger att tex prestanda är viktigt men säkerhet inte är lika viktigt. Sen får de då beskriva vad de menar med prestanda: Det ska inte uppfattas som långsamt för en normalkund att öppna förstasidan på vår websajt. Definiera normalkund, PC-typ, uppkoppling, under vilka förhållanden - högtrafik, normal...Långsamt : typ mer än tre sekunder. Även om vi inte kan få exakta svar kan vi om vi skriver kraven i dess sammanhang med syfte och mål få en bra bild. Det är dock tveksamt om vi som testare ska ta fram kraven, då överskrider vi våra arbetsuppgifter. Men visst händer det att vi gör så, eller hur?

2. Steg två är att utifrån kraven kunna göra en bedömning om det är något vi kan hantera själv, om vi behöver mer information, om vi behöver viss miljö, eller om vi ska kalla in experter - eller rättare sagt meddela projektledaren att vi rekommenderar att man tar in experter. Ska dessa då både ta fram kraven och sen testa dem? Det är väl oftast det som sker. Är det bra då?

3. Steg tre är att vi eller specialisterna utför tester och rapporterar resultatet. När det gäller prestandatester sker det ofta en "tuning" under testerna så att systemet uppnår den prestanda som begärts. Redan här inser jag mina begränsingar och skulle aldrig ta på mig ansvaret för att utföra prestandatesterna i ett projekt.

Har letat med ljus och lykta efter böcker, artiklar om detta och hittat vissa delar om prestanda och användbarhet. Kanske dags att skriva en bok till tillsammans med de bästa inom varja område. Finns det någon som har en riktigt bra mall för "icke-funktionella2 krav. Skicka den gärna till mig på torbjorn at ryber.se

//Tobbe

Publicerat den

Jag fick i förra veckan förmånen att delta på ett seminarie med testgurun James Bach anordnat av ENEA. Som vanligt körde han hårt med publiken och ifrågasatte det mesta. Grundtanken är att vi inte ska tro på allt som sägs utan kritiskt ifrågasätta och försöka förstå innebörden. Han tar upp "gamla sanningar" och dissekerar dem så att deltagarna själva kan ha möjlighet att ta ställning till vad som är rätt och fel. Han är en man med starka åsikter och ett väldigt direkt sätt att uttrycka dem. Detta har gjort att många gamlingar i tesbranschen har reagerat med att totalt såga hans tankar om exempelvis utforskande testning. Själv anser jag honom som en lysande talare och en man med stor integritet. Det är av James och hans kollegor i "The context-driven school" jag lärt mig det lilla extra inom test. Jag håller med om att väldigt många testböcker fokuserar mest på procedurer och dokument och innehåller väldigt lite information om vad test egentligen innebär. det finns en drös böcker som handlöar om testning i allmänhet men endast ett fåtal om testdesign som jag anser är kärnan i bra testarbete. Förutom Lee Copelands bok "Test design for the practitioner" finns det ytterst lite skrivet. Jag har försökt ta mig igenom Boris Beizers "Black-Box testing Techniques" men gett upp flera gånger då boken är fruktansvärt omständig och känns mer som en historiebok över test än en en handbok för ambtiösa testare. Kolla in Boktips för fler bokrecensioner. Det är sällan man träffar en så engagerad och intressant person som James att prata med. Jag fick nöjet av att på tu man hand ta med honom på Edsbackas Bistro och njuta av deras svenska specialiteter. Han hoppas att de idéer han har kan spridas i Sverige och jag har lovat att göra mitt bästa för att missionera om test med inspiration från hans många alster. Jag rekommenderar verkligen ett besök på www.satisfice.com. Och du, vill du gå en riktigt bra kurs inom test - kolla på ENEAs kursprogram för nästa kurs.

//Torbjörn