En intervju av Alan PAGE, som började sin karriär som testare 1993. Han började på Microsoft 1995, och har för närvande titeln ”Director of test excellence” . I denna roll har han har ett övergripande ansvar för den tekniska träning som alla testare genomgår samt ett antal andra aktiviteter fokuserade på att förbättra testarna, testning samt test verktyg.
Intervjuare och översättare; Thomas Klevmar
Först några frågor om boken: How We Test At Microsoft, HTWSAM
Thomas: Kommer det någon ny upplaga av HWTSAM? Eller planeras andra test böcker från Microsoft eller från dig själv till exempel om test på den kommande Windows 8, Windows Mobile (Tablet/Pad) eller testning i Microsoft Cloud?
Alan Page; Vid denna tid finns inga planer från förlaget för en ny upplaga av HWTSAM. Men, jag skulle älska en möjlighet att uppdatera boken. Det finns en hel del ny information som vi kunde dela, och även om jag hatar att erkänna det, finns det några misstag (bugs!) i boken som jag skulle vilja fixa.
Såvitt jag vet finns det inga andra böcker om test som kommer från Microsoft inom en snar framtid. Men Ken Johnston (författare HWTSAM kapitel 1, 2 och 14) och jag skriver båda om testning hos Microsoft i en kommande bok ”Experiences of Test Automation”, av Dorothy Graham, som ska publiceras under hösten 2011.
Thomas: Jag (översättaren) och många läsare har säker funnit AFA (Automatisk Fel Analys) kapitlet intressant i HWTSAM.
A) Finns det någon mer information till allmänheten om AFA ämne eller AFA Toolkit?
B) Hur ska testloggar från SUT vara utformade för att göra de tester som lämpar sig för AFA? (Vi såg några ledtrådar i din bok, som till exempel att loggning vid FAIL scenarios i testlogg bör vara utförlig, och att PASS borde vara sparsam för att automatisk analys ska fungera bäst)
C) Är det bara defekter av typen kraschar(som uppvisar call-stack/ s.k. anrops-stack) och stabilitets-problem som är lämpliga för AFA?
Vilka andra områden använder du AFA för, annat än automatiskt analysera kraschar?
Alan Page:
A) Det finns en del information att ta del av inom området tex;
Publik information om automatiserade felanalys är sparsam, förutom HWTSAM det finns en IEEE uppsats om ämnet finns:
http://ieeexplore.ieee.org/xpl/freeabs_all.jsp?arnumber=4539565
http://academic.research.microsoft.com/Paper/4719159.aspx
B) Vägledning för instrumentering:
http://www.sasqag.org/pastmeetings/9-2007/SASQAG_9-20-2007.ppt
http://www.sasqag.org/pastmeetings/9-2007/SASQAG-BP-Logging.doc
C) Automatisk Fel Analys (AFA) kan användas för en mängd olika situationer där data som analyseras följer ett förutsägbart mönster.
AFA konceptet har applicerats inom datacenter för att snabba ”failover” och ”recovery”, i support-organisation – för att effektivt identifiera rapporterade problem snabbt, samt ett triage/beslutstöds–verktyg för testautomatisering och är mer utbredd vid kvalitetskontroll i tillverkning av hårdvara.
I analys av mjukvarans testresultat, kan typen av felsymptom variera kraftigt. Många verktyg och testare börjar med hårda felsymptomer såsom krasch i SUT och ”assert” i tron att dess anropsstack, fel-väg, kommer att vara unik och entydig för en viss typ av fel.
En snabb inspektion av den premissen avslöjar att detta inte nödvändigtvis är fallet. Många mjukare former av felsymptomer (t.ex. en felaktig matematisk uträkning, fel svar) kan vara tydlig och entydig medan många hårdare felsymptomer (t.ex. krasch) för misslyckande i praktiken kan urarta (Översättaren; och t.ex. värsta fallen t.o.m. skriva över anrops-stacken).
Den begränsande faktorn på effektiviteten i AFA, är kvaliteten på inkommande data med avseende på typen av felsymptom. Mjuka fel kan lika lätt identifieras som hårda fel när vederbörlig hänsyn tas till instrumentering och loggnings klassificeringar från början. Översättaren; Alan Page vill förmodligen säga att det är väldigt svårt att i efterhand modifiera ett system(SUT) att ha en loggning som möjliggör AFA.
Vid hårda felsymptomer, såsom krascher och ”asserts”, frestas de som analyserar felen att sätta en enorm vikt till särskilda mönster i anropsstacken, men samma anrops-stackar kan komma från dussintals grundorsaker.
Till exempel, förutsätt en produkt som autentiserar med ett konto ”Network Service” i Windows. Det finns en mängd olika sätt att produkten kan använda kontot ”Network Service” felaktigt innan du reflekterar över att kontot ”Network Service” går under namnet ”Netzwerkdienst” på Tyska system. Om du endast har identifierat ditt fel-läge(felsymptom) med anropstacken till ”Ogiltig Användare” , kommer du automatiskt att maskera bort denna typ av språkspecifika fel (utan att ens beakta alla de olika sätt man kan sluta med ett fel-läget ”Ogiltigt Användare” för en viss operation, fastän du har identifieras med rätt användaren).
AFA ger stor kapacitet att göra något snabbt, som med alla tekniker för automatisering det är upp till användaren att kontrollera att rätt sak görs. Användaren, genom att genomdriva en klassificering på inkommande data och skapandet av matchande kriterier, har den kontrollen.
Fortsättning följer nästa vecka…
—
Följ gärna Alan Pages blog!
