Gå till innehåll

Kategori: Test Design

Test design, requirements etc

Publicerat den

Sitter på tåget hem från Ronneby. En sex timmar lång tågresa skiljer metropolerna Örebro och Ronneby åt, speciellt intressant att åka andra klass på tåget en fredagkväll. Mycket sprit bland resenärerna och SJ eldar på med fulla rättigheter i bistron. Som tur var fanns dator med DVD så jag kunde kolla på en rätt menlös thriller av den typen som min sambo INTE gillar.

I Ronneby finns en avdelning av Blekinge Tekniska Högskola som sysslar med V&V. Jag hade blivit inbjuden till den akademiska världen för att hålla en introduktionskurs för fjärde året på högskolan. Med 90% utländska studenter varav majoriteten från Pakistan var det Engelska som gällde hela tiden. Så nu har jag äntligen en två eller kanske tre dagar lång kurs i testintro och test design helt på engelska. Respekten för läraren är stor i de länder studenterna kommer ifrån så de är mest vana vid att en lärare står och mässar och inga frågor ställs så det var bitvis ganska tunt med frågor. Kul var det i alla fall och en utmaning. I dag var det två studenter som försiktigt frågade om vi kunde skjuta på lunchen så att de kunde ha sin bönestund och hinna äta efteråt. Turligt nog för mig så svarade jag att det gick bra och insåg samtidigt att de flesta av deltagarna skulle delta i fredagsbönen. Fredag är ju helgdag inom islam men jag har aldrig märkt av det förut.

Forskarna på BTH, med Richard Torkar i spetsen, var entusiastiska över den nya konferensen i Lillehammer i april. Jag har läst ienom föredragen och inser att de ligger på en helt annan nivå en vad jag är van vid från EuroSTAR och svenska testkonferenser. Frågan är om de ligger så högt att det blir svårt att ta till sig dem alls för mig. Nåja jag har i alla fall bestämt mig för att ta en paus från testkonferenserna i år, mest av familjeskäl.

Uppenbarligen finns det många svenska forskare som är långt framme inom testområdet men det verkar som att endast ett fåtal företag utnyttjar detta och samarbetar med dem. ABB och Eriksson är några av dem. Jag inser på vilken otroligt låg nivå de flesta företag ligger på och undrar hur vi ska kunna ändra på detta? Hoppas att det kommer ut fler högskoleutbildade med testutbildning som kan visa vägen.

Publicerat den

Läste precis föreläsningsmaterial och en artikel av Lloyd Roden där han går igenom tekniken parvis testing. Principen är att de fel som finns vanligen är enkla fel - dvs ett visst värde på en viss parameter ger ett fel oavsett värdena på övriga variabler, eller duala där en kombination av två värden för två olika variabler i kombination gör att felet uppträder. Fel som kräver fler kombinationer är betydligt förre och att testa alla kombinationer av värden för alla variabler är sällan möjligt. 

Som många andra, ex Lee Copeland, ägnar han stor möda åt att förklara fenomenet ortogonala arrayer och hur dessa kan användas för att lösa problemen. O Arrayer är matematiska och manuellt framtagna och har egenskapen att de innehåller alla par av värden för vilka två kolumner som helst dvs i vårt falla för alla variabler och alla värden, jag ska inte förklara detta närmare här. Läs artikeln om du vill veta mer. problemet som jag ser det är att det finns en mängd begränsingar med arrayerna och det finns inga (?) bevisade fördelar med den ena eller andra metoden vad gäller felupptäckning för mjukvara. Däremot finns ett exempel för hårdvara 

The index is important when you want to make sure not only that each combination is tested, but that each combination is tested the same number of times. That's important in manufacturing and product safety tests, because it allows us to account for wear or friction between components. When we test combinations of components using orthogonal arrays, we find not only which combination of components will break, but also which combination will break first.  Michael Bolton

 Det Lloydutelämnar i artikeln är alla de fördelar som finns med ett verktyg som ex PICT nämligen följande:

a) det går att ha variabel täckning för olika variabler dvs du kan ha enkel täckning för vissa, parvis för andra och ännu högre för resten. Med andra ord högre risk - bättre täckning! Ortogonala arrayer för högre kombinationer är mycket stora och svåra att hantera.

b) det går att lägga in begränsingar för vissa kombinationer av variabler vilket är praktiskt då det ofta finns kombinationer som ej är tillåtna

c) det går att markera vissa värden som ogiltiga vilket gör att verktyget endast har med ett ogiltigt värde i varje testfall. detta är rekommendationen att ha då annars ett felaktigt värde kan hindra att nästa felaktiga vrde testas - dvs felhantering gör att vi hoppar ur loopen innan värdet avläses

d) när, inte OM men NÄR, du kommer på att det finns fler värden för en viss variabel. Då är det bara att lägga in de nya värdena och köra om filen. Använder du en array så är risken stor att du måste leta upp en ny vilket är tidsödande.

e) eftersom det inte finns arrayer för alla kombinationer av parameterantal och värden så är risken större att det blir fler testfall med arrayerna. Självklart finns det exempel på fall där motsaten gäller då du lyclas hitta en perfekt array för dina variabler.

Jag har diskuterat arrayer med Mats Grindal på ENEA som skrivit en doktorsavhandling i ämnet och med Peter Zimmerer som hade en tutorial på EuroSTAR förra veckan. Deras svar är entydliga - använd verktyg! 

Någon som har en avvikande mening är välkommen att argumentera för den här.

Publicerat den

Det farliga med en standard är att det som står i den ska räknas som det som gäller. Det är därför viktigt att informationen stämmer överens med resten av världen. Då jag just nu sitter och arbetar med test i Unified Process undersökte jag vad som står i Syllabusen om Use-Cases. Väljer att studera den internationella version som övriga länders översättning bygger på.

4.3.5 Use case testing (K2)

Tests can be specified from use cases or business scenarios. A use case describes interactions between actors, including users and the system, which produce a result of value to a system user. Each use case has preconditions, which need to be met for a use case to work successfully. Each use case terminates with post-conditions, which are the observable results and final state of the system after the use case has been completed. A use case usually has a mainstream (i.e. most likely) scenario, and sometimes alternative branches.

Use cases describe the “process flows” through a system based on its actual likely use, so the test cases derived from use cases are most useful in uncovering defects in the process flows during real-world use of the system. Use cases, often referred to as scenarios, are very useful for designing acceptance tests with customer/user participation. They also help uncover integration defects caused by the interaction and interference of different components, which individual component testing would not see.

Som metodare reagerar jag på de ord och förklaringar man använder sig av.

1) Mainstream Scenario: detta betecknas vanligen primary flow, basic flow eller happy flow. Mainstream är en helt ny beteckning.

2) Alternative branches: flow eller path är OK men branch är också en ny beteckning.

3) Sen står det att Use-Cases är mest effektiva för att hitta Real-World problem och därmed bäst för acceptanstest. Nu finns det ju en business modeling disciplin och där kan det finnas business use cases men ofta är det business processes, information och rules som beskrivs och dessa testas främst i acceptanstest. Use-Cases är ju kraven på SYSTEMET och testas främst i systemtest.

4) Sen säger man att ett Use-Case vanligen kallas scenarios vilket också är fel då ett scenario är EN väg genom ett use-case. Oftast finns det ett flertal scenarios som ska testas - detta är också tekniken för test av Use-Cases. Ta fram aktivitetsdigrammet och testa alla (om det går) scenarios.

5) Till sist blandar man in component testing och integration mellan komponenter där man blandar ihop component, component -integration och system testing. Det är som att skriva att use-case testing - som är en black-box teknik är bättre än komponenttest för att testa helheten. Ja det är ju rätt i princip men jämföra en en specifik teknik med en testnivå är väl knappast logiskt.

Helt uppenbart har den som skrivit texten inte rådfrågat en UP/Use-Case expert eftersom till och med de vanligaste begreppen och huvudsyftena är felaktiga.

Lite mer än så borde vi kunna förvänta oss av en internationell standard tycker jag.

 

 

Publicerat den

Som student har man aldrig speciellt mycket pengar. Det minns jag fortfarande även om jag tog examen för drygt 12 år sedan. Jag sträcker därför ut en hand åt alla som studerar och erbjuder min bok till kraftigt rabatterat pris. För en hundring jämt så skickar jag boken hem till dig. I detta ingår porto på 39 kr. Med detta hoppas jag kunna sprida kunskapen om test till den akademiska världen. Om nån på mer bestämmande nivå beslutar att ni vill ha boken som kursmaterial, kontakta mig så fixar vi ett riktigt bra pris. Lägsta tänkbara pris är helt gratis. Intressant?

Vill du ha boken. Skicka ett brev till Torbjörn Ryber, Tennringen 63, 176 74 Järfälla. Berätta vad och var du pluggar och glöm inte hundringen. En bok kommer inom kort på posten. 

Publicerat den

Det här med morgontidning är intressant. Sverige är rätt unikt vad gäller att det varje morgon delas ut tidningar hem till hushållen. Oftast fungerar det bra, dock inte denna vecka.

Som prenumerant kan jag logga in via webben och själv anmäla uppehåll eller reklamationer. Login och lösen är från början mitt prenumerationsnummer med postnummer som lösen. Det kan jag sen byta till något jag lättare kommer ihåg. Bra lösning tycker jag. När jag väl kommer in och ska gnälla av mig lite finns det sex radioknappar att välja på - det går bara att välja en i taget. Följande val finns:

utebliven tidning idag, igår, i förrgår, tidning kom sent, trasig tidning eller fel tidning.

Jag har bara ett testfall jag vill köra: denna vecka har jag inte haft tid att gå in varje dag och gnälla utan sparat det till idag. Följande vill jag rapportera: fel tidning i måndags (DN), sen tidning i onsdags (07.15) och utebliven tidning idag. Det enda jag kan anmäla autmatiskt är att tidningen uteblev idag. Jag fundrear på att anmäla även sen tidning och fel tidning och se hur det behandlas. Tolkas det som att idag kom det ingen tidning, dessutom var det fel tidning och till på köpet var den trasig!

Lite större flexibilitet i gränssnittet skulle vara trevligt. Tex att jag per dag den senaste veckan kan anmäla vad som skett. Fast den här gången orkar jag nog inte ringa, så kanske är designen genomtänkt iallafall. Kan dom vara så smarta? 

Samma dag kl 09.15: Hoppsan nu dök det upp ett testfall till. Tdningen kom till slut fast väldigt sent. Så nu loggar jag på igen och vill byta reklamationsorsak från utebliven till sen. Vad händer då?

Felmeddelande:
Det gick inte att spara reklamationen då en tidigare redan är sparad för samma dag
Så nu vet det, har vi sagt en sak så är det det som gäller!