OnTime nr 1 2003 - Combitech.se

More documents

Recommendations

Info

AV DOROTHY GRAHAM Krav och tester: Sju myter om felande länkar Copyright © 2002 IEEE. Publicerad med tillstånd av IEEE. Ursprungligen publicerad i IEEE Software, september/oktober 2002, med namnet ”Requirements and Testing: Seven Missing-Link Myths”. Testexperten Dorothy Graham hävdar att man kan spara en hel del tid och pengar om testarna är med och testar kraven. När kraven har fasta kvalitetskriterier kan testarna ställa frågor och hitta problem innan dessa förvandlas till kod. En stark koppling mellan testning och kravhantering är till nytta för båda sidor, tyvärr saknas ofta denna länk. Vi granskar de sju vanligaste myterna eller missförstånden som är orsak till att länken saknas. Myt 1: Kraven i början, testningen på slutet ”Vi behöver inte tänka på testning ännu. Vi koncentrerar oss på kraven”. Detta är en attityd som garanterar att du får problem i slutet av projektet. Javisst, det är självklart viktigt att ha bra krav, men att ha testarna med under kravanalysen är ett av de bästa sätten att säkerställa bra krav. Som framgår av figur 1 bör utformning av tester göras så snart det finns något att utforma tester för – vanligen under kravanalysen och framtagandet av användarnas acceptanstest. Ett vanligt problem, speciellt för testpersonal, är påverkan från sena kravförändringar. Anta till exempel att du är i de sista veckorna av systemtesterna och acceptanstest är planerat att börja inom två veckor. Plötsligt säger användaren ”Jo förresten, vi vill att systemet ska göra det här på ett annat sätt”, vilket ju är hemskt frustrerande och förekommer mycket oftare än det skulle. Men, vad är det egentligen användarna gör? De utformar sina acceptanstest! Utformningen av testet belyser vad de verkligen vill att systemet ska göra. Hade testerna utformats tidigt (vänstra sidan av fig. 1), hade problemen upptäckts innan de byggdes in i systemet. Det är mycket viktigt att få användarna delaktiga i både kravutformning och testdesign. Har du någon gång köpt en begagnad bil? Skulle du säga till försäljaren: ”Du vet mycket mer om bilar än vad jag gör, så kör provturen åt mig!”? I så fall får man skylla Affärskrav Projektspecifikation Design tester Test des Systemspecifikation Test des Designspecifikation Kod Test des Test des Test des Figur 1. En V-modell för tidig testutformning Acceptanstest Test av systemintegrering Systemtestning Test av komponentintegrering Komponenttestning sig själv. På samma sätt säger användarna ofta till teknikerna: ”Ni vet mycket mer om datorer än vi gör, så gör acceptanstestet åt oss!” Caveat emptor! (Köparen varnas!) Myt 2: Det går inte att testa innan systemet existerar ”Vi kan inte göra några tester därför att inget är konstruerat än. Testfolket leker bara med systemet och ser vad som händer. Förresten kan man inte testa en bit papper.” Tre saker är fel med den inställningen. För det första, testning är mycket mer än att bara titta vad som händer. Det är mycket rigorösare och mer systematiskt än så. För det andra, det är inte bara att genomföra testen. Som framgår av figur 2 är testproceduren och resultatkontroll en del av hela testprocessen, men det finns dessutom andra viktiga aktiviteter. För det tredje, du kan, och ska, testa de skrivna kravdokumenten gentemot affärs- eller projektmål så att det blir korrekt och komplett. Testar du inte de nedskrivna kraven kommer du att bygga in fel i systemet som enkelt kunde ha undvikits tidigare. Myt 3: Kraven används i testning, men inte tvärtom ”Du testar inte kraven – du utgår från dem.” Testarens inställning skiljer sig från utvecklarens. Det är ganska lätt att skriva krav som är lite svävande och tvetydiga men som verkar vara OK. Men när duktiga testare tittar på kravspecifikationer hittar de på speciella testfall för att avslöja svävande, tvetydiga och oklara krav. När du försöker förklara ett abstrakt koncept för någon säger du: ”till exempel” och illustrerar idén med verkliga och specifika fall för att klargöra det hela. Tester är ”till exempel” för kraven. Tänk på ”vad händer om”-användarfall eller -affärsscenarier. Föreställ dig hur en speciell användare kommer att köra systemet. Funktionen hos systemet som verkade abstrakt när det först beskrevs blir då förståelig för just den användaren. Såväl tester som kravanalys har nytta av att denna återkoppling finns. Bra kravspecificering ger bättre tester; bra testanalys ger bättre krav. Myt 4: Om det är svårt att konstruera bra tester, så är det endast ett testproblem ”Testpersonalen verkar ha problem med att göra tester av våra krav – kanske vi ska skaffa bättre testare.” Inte alla krav är lika sett från en testares perspektiv. Skapa tester för en del krav är enkelt, för andra kan det vara en mardröm. Man ska identifiera exakt vad systemet ska göra och därmed identifiera tester som kan säkerställa att just dessa saker görs. Att specificera testbara icke-funktionella krav såsom användbarhet eller prestanda är svårt. Uttryck av typen enkelt att använda, användarvänligt, mycket pålitligt eller acceptabel prestanda är inte specifikationer, det är vaga, svävande förhoppningar. Jag instämmer med Tom Gilbs lag: ”Allting kan göras mätbart på ett sätt som är bättre än att inte mäta det alls.” Observera att det inte görs mätbart på ett perfekt sätt, utan på ett användbart sätt. Suzanne och James Robertsons ”passande kriterier” (fit criteria) visar precis hur krav kan göras mätbara och därmed testbara. Myt 5: Smärre ändringar av kraven påverkar inte projektet (mycket) ”Lägg bara till lite mer utrymme i det här inmatningsfältet. Det finns massor med plats på skärmen. Det är bara en mindre ändring; 24 Nr 1 mars 2003 Combitech Systems AB Kör tester
den behöver man inte testa, därför att den är så liten.” En ändring som verkar liten sedd från kravsynpunkt kan få långtgående konsekvenser, speciellt i testarbetet. Anta att ett tillägg av två tecken i ett fält innebär att databasen i vilken fältet är definierat måste omorganiseras. Vad händer om detta fält överensstämmer med liknande information som finns på annat ställe i systemet? Vad händer om rutinerna som kontrollerar detta fält även kontrollerar andra fält som inte har ökat i längd? Kommer man då att behöva två kontrollrutiner? Du måste testa alla sådana ändringar för att vara säker på att systemet nu gör rätt sak i varje situation som påverkats av ändringen. Dessutom kan oväntade följdeffekter uppstå, så du måste även göra regressionstester för att vara säker på att systemet inte har förfallit på andra områden. Hur mycket testning du måste göra beror på i vilken utsträckning en ändring kan ha både kända och okända effekter på systemet. Testning kan också hjälpa till att minska risken med en ändring, genom att ge trovärdighet åt att effekten är liten. Myt 6:Testarna behöver egentligen inte kraven ”Jag vet att vi inte har en bra kravspecifikation för det här systemet, men testa så gott det går – bara kolla vad systemet gör.” En testares jobb är att bedöma vad systemet gör och vad det borde göra. Systemet ska hjälpa till att uppnå affärsmål, så vad systemet gör ska jämföras med dessa mål. Det finns ett antagande av orakeltyp (vilket inte har något med databaser eller företagen som säljer dem att göra – istället är det fråga om Oraklet i Delfi, som kunde förutsäga framtiden på ett ofelbart sätt). Detta orakelmässiga antagande säger att testaren regelmässigt vet vilket det korrekta svaret ska vara, en förutsättning för testning. Ett test består av indata, förutsättningar och förväntat resultat. Hur kan man veta vad det förväntade resultatet ska vara? En kravspecifikation utgör testbasen – oraklet. Så testarna behöver verkligen kraven, i Nr 1 mars 2003 Combitech Systems AB annat fall kan man påstå att det inte har gjorts något riktigt test. Myt 7:Testare kan inte testa utan krav ”Eftersom kraven utgör grunden för testerna, så kan vi uppenbarligen inte göra några tester innan vi har ordentliga krav.” Detta är också ett vanligt missförstånd. Ibland görs ändringar av systemet där kraven är otillräckliga eller obefintliga. Det gör testarbetet svårare, men ryck inte bara på axlarna och säg att du inte kan göra det. Utan krav behöver testarna i alla fall någon typ av orakel – kanske användare som känner till hur systemet fungerar, det gamla systemet, manualer eller testarens egen uppfattning. Vad händer om testoraklet är testaren? Istället för att bara jämföra systemet med en dokumentation kommer testaren att bedöma systemet med utgångspunkt från sin personliga uppfattning av vad det bör göra. (I själva verket bör testare alltid göra detta i viss mån, men det är en annan historia). En del säger att utan en specifikation gör du egentligen ingen testning, du bara undersöker systemet. Detta finns formaliserat i vad som kallas undersökande testning (exploratory testing), som är utformad för situationer med otillräckliga krav och stor tidspress. När du till slut har en bra uppsättning testprogram, testplanering, testspecifikationer och så vidare, blir testvaran den enda kravdokumentationen i projektet. Så behövs kravspecifikationerna alls om man har tillräckligt bra tester? Blir testarna kravutformare? Är detta en bra idé? När kraven är dåliga eller obefintliga måste testarna göra så gott de kan under de mindre ideala omständigheterna. Testningen blir betydligt mera noggrann om den baseras på en bra kravspecifikation och en stor fördel är om testarna får delta i ett tidigt stadium. Praktiska tips Jag hoppas att jag har övertygat er om att testpersonal har mycket att erbjuda vid STRATEGIER FÖR EFFEKTIV TEST Figur 2.Vad är ”testning”? Policy och strategier Testplanering (på varje nivå) Identifiera förutsättningar Utforma testfall Konstruera tester Kör tester Kontrollera resultat Kontrollera utdata-kriterier, testrapporter Testprocessen Processförbättring utformningen av bättre krav. Så här åstadkoms detta i praktiken: • Inbjud testare att delta i granskning av kraven. • Påbörja testning parallellt med kravanalysen. • Be om prov på testförutsättningar och testfall för att användas som exempel i kravspecifikationen. • Ta i kravdokumentet med de specifika fall du hade i åtanke när kraven analyserades. • Använd affärsscenarier och användarfall för att ge specifika exempel på hur systemet bör fungera. • Skapa mätbara kriterier för både funktionella och icke-funktionella krav. Testning är en utmaning på två sätt: det är en stimulerande intellektuell aktivitet, men det utmanar också allt som testerna baseras på. Skapa länken mellan krav och testning. Om du accepterar och uppmuntrar att testarna utmanar dina krav kan du undvika missuppfattningar, och får i slutänden både betydligt bättre krav och tester. ■ Dorothy Graham är grundare av Grove Consultants, som erbjuder tjänster och utbildning inom områdena mjukvarutest, testverktyg och granskning. Dorothy har skrivit flera böcker inom området och är även en av grundarna till ISEB Software Testing Board. På EuroSTAR Conference 1999 fick Dorothy Graham mottaga priset ”European Excellence Award in Software Testing” 25
Page 1 and 2: nTimeGER INSIKT I TID Vad är test
Page 3 and 4: Effektiv test - en fråga om överl
Page 5 and 6: 4. Om en mycket ljus bild visas fö
Page 7 and 8: trollers och andra inbyggda system)
Page 9 and 10: • Gör ett urval av vägar som sa
Page 11 and 12: • Har jag tänkt igenom de sätt
Page 13 and 14: Test av felhantering i distribuerad
Page 15 and 16: Miljölagar driver på testutveckli
Page 17 and 18: När fel inte får förekomma För
Page 19 and 20: Kom igång med prediktions- och evo
Page 21 and 22: in, samt antalet fel som rapportera
Page 23: Mått Beskrivning SDL-pages Antalet
Page 27 and 28: Kursschema VÅREN 2003 STRATEGIER F

OnTime nr 1 2003 - Combitech.se

You also want an ePaper? Increase the reach of your titles

Delete template?

Save as template?