2009-12-01
Utforskande testning av och med Mr M.B.
Igår var det Exploritory testing Masterclass av och med Michael Bolton på EuroSTAR 2009.
Han är i mitt tycke en helt fantastisk föreläsare.
8 timmar inspiration... känner mig fortfarande kraftigt påverkad, och färgad.
Varför har han den effekten på mig? Jag vill kunna säga nej... men kan inte.
Det kommer bara ett... Ja!
En kortare sammanfattning och presentation kommer inom kort på en Elevate-kväll nära dig!
Postad av Daniel Granlund
Kommentarer (0)
Kategorier:
Test
Föreläsning
2009-11-26
Miljövänlig inflygning testas
Flygbolaget Novair är först med en ny inflygningsteknik som ska spara bränsle och minska bullret från flyget.
Tekniken testades på Arlanda igår (25 nov '09). Planet kan glidflyga in till flyplatsen med minsta möjliga motorpådrag.
Källa: Metro
Postad av Daniel Granlund
Kommentarer (0)
Kategorier:
Test
2009-10-12
EuroSTAR 2009
2007 hölls senaste EuroSTAR Conf. i Stockholm, förra året var det Haag, och nu är det återigen Stockholms tur.
Under konferansen '07 fick alla åhörare en väska med just texten EuroSTAR på.
En utvecklare på mitt dåvarande uppdrag fick ett par dagar efter konferansen syn på min väska och frågade:
- EuroSTAR? Vad är det? Är det en sån karaoketävling?
Om du har samma fundering tycker jag det är dags att du skaffar lite omvärldskunskap och läser in dig på http://www.eurostarconferences.com/
Postad av Daniel Granlund
Kommentarer (0)
Kategorier:
Test
Föreläsning
2009-04-12
Hur lång tid tar test?
På mitt uppdrag sitter jag med ena foten i förvaltning som testledare.
Nya krav dyker upp från verksamheten, prioriteras och godkäns av områdesansvarig och systemägare efter att vi uppskattat den tid/kostnad det tar för utveckling och test och ställt det i relation till nyttan för verksamheten.
Men vad är det man svarar på när frågan om hur lång tid en ny eller förändrad funktion tar att testa?
Det är mycket man måste väga in i det svaret.
Vi jobbar inte direkt iterativt, men oavsett så brukar det handla om minst tre lyft även för att testa av mindre komplicerade förändringar. (Även om ibland testas ett nytt VO med nya procedurer i ett lyft och dialogen i ett andra.)
Varje förändring kräver planering, förberedelse, genomförande och uppföljning.
Där jag brukar se det som att genomförandet är en liten del av den totala test-tiden, säg 30 %.
Jag tror att man normalt säger att test nästan tar lika lång tid som utveckling.
Men då handlar det ju inte om att testgenomförandet tar lika lång tid som det tar för utvecklaren att koda.
Kalendertiden behöver inte vara den samma som antalet timmar det tar.
Beroende på hur erfaren och agil testaren är, och hur väl han/hon känner till systemet påverkar också den tid det tar att genomföra en testinsats.
Hur stor påverkan på befintlig funktionalitet kommer förändringen ha? Kommer det att behövas köras mycket regressionstester? Har krav förändrats eller bara tillkommit?
Kommer automatiserade testfall påverkas?
Oftast får man inte all den tiden man behöver. Men gör den som ställer frågan till dig medveten om påverkan av förändringen, inte bara på systemet, utan även nyttan och påverkan på test, så kanske du får mer av den tid du behöver.
Postad av Daniel Granlund
Kommentarer (0)
Kategorier:
Test
Testledning
2009-03-18
resultat eller utfall
Enligt SSTB 's ordlista v2.0 är resultat och utfall samma sak.
Visst kan det kännas okej i många fall, men inte alltid.
Ett testfall eller teststeg har i genomförandefasen en status.
Denna status kan vara t.ex. "No run", "Not Completed" eller "Passed".
Varje steg eller ett helt testfall har ett förväntat resultat.
Det kan var t.ex. "42" eller "Kunden är sparad i databasen".
Vad vill jag då ha för definition på utfall?
Jo, att utfallet är en bedömning av det faktiska resultatet mot det förväntade.
Det behöver alltså inte vara samma sak som status, och absolut inte samma sak som resultat.
Ex:
Vi förväntar oss resultatet att kunden skulle bli sparad. Testfallet resulterade i att kunden blev sparad.
Resultatet blev att kunden blev sparad.
Eftersom utvecklaren hade infört koden förväntade vi oss ett posistivt utfall. Så vi jämför det förväntade resultatet med det faktiska och konstaterar att utfallet är positivt, dvs. "Passed".
Hade inte koden införts, och vi ändå skulle köra testfallet hade vi förväntat oss en negativt utfall. Testfallet har fortfarande samma förväntade resultat, men ett annat förväntat utfall.
Postad av Daniel Granlund
Kommentarer (0)
Kategorier:
Test
2009-02-17
Test-terminologi
Det är inte helt enkelt med terminologin kring test.
Ibland får jag känslan av att det rör till det för vissa, bara av att sätta ordet test- framför.
Därför är det några grundläggande termer jag vill kasta ut och hoppas vi kan enas kring:
Testfas.
En fas, en del av ett tidsförlopp, t.ex. testförberedelse eller testgenomförande
Testnivå.
En nivå avsedd för en viss typ av tester, t.ex. enhetstest, systemtest, acceptanstest.
Iteration.
Ett återupprepningsbart förlopp av faser.
Testtyp.
En viss typ av tester, t.ex. funktionella, prestanda, användbarhet, säkerhet.
Testteknik.
En teknik eller metod för att testa, t.ex. villkorstester, gränsvärden, utforskande tester.
Alltså kan vi då sammanfatta med att: En iteration består av flera testfaser som kan täcka en eller flera testnivåer, bestå av en eller flera testtyper och även en eller flera testtekniker.
Postad av Daniel Granlund
Kommentarer (0)
Kategorier:
Test
Testtekniker
2009-01-07
Vad gör en Testanalytiker?
Det kan vara svårt det här med rollerna inom test.
Vad gör t.ex. en testanalytiker, en testdesigner eller en teststrateg?
På det uppdrag där jag idag sitter har vi precis definierat alla roller vi behöver inom test som en del i testprocessarbetet, och just rollen testanalytiker anser jag vara den för testgenomförande viktigaste rollen.
Men testledaren da?
Självklart finns det massor av viktiga aktiviteter även inom rollen för en testledare, men för att kunna genomföra dessa aktiviteter behövs inte samma kompetens inom test som för de en analytiker har.
Varför då?
Jo, följande aktiviteter finns bl.a. definierade för en testanalytiker hos oss:
- Förbered testprovskott (ansvarig)
- Skapa testsviter (ansvarig)
- Beställ testdata (ansvarig)
- Granska testfall (ansvarig)
- Identifiera testfall för automatisering (ansvarig)
- Identifiera testidéer (ansvarig)
- Kravställ testmiljö (ansvarig)
- Sammanställ testresultat
- Säkerställ testbarhet (ansvarig)
- Beskriv tillvägagångssätt för testarbetet
- Genomför testförbättringar
- Identifiera testmotiv
- Skapa automatiserade testfall
- Utvärdera och bedöm kvalitet
- Utvärdera testarbetet
- Detaljera testplaneringen.
Vilket kräver en hel del kompetens som varken rollerna testare eller testledare behöver besitta.
Postad av Daniel Granlund
Kommentarer (0)
Kategorier:
Testledning
Testprocesser
2008-11-27
Try it again
Undrar vad Fagerstagrabbarna i the Hives hade i tankarna när dom skrev låten "Try it again".
Den låter väldigt fighting-inspirerad, har inte sett videon dock.
I låten återfinns:
"They say the defenition of madness is doing the same thing and expecting a different result..."
Det kan då inte varit mjukvarutester de tänkte på iallafall.
Postad av Daniel Granlund
Kommentarer (0)
Kategorier:
Test
2008-11-20
Ekvivalensklasser och testtäckning
En testteknik som jag funnit mycket användbar är ekvikalensklassindelning.
Ett svårt ord, men inte alls speciellt svår teknik.
Definitionen blir:
En ekvivalensklass är en grupp värden som kan förväntas behandlas lika, utifrån att de enligt definition eller specifikation ska behandlas lika.
Inget konstigt där, eller hur?
Om man nu bestämmer sig för att testa enligt detta, vad kommer det säga om kod- resp. testtäckning?
Att kodtäckningen blir hög medan testtäckningen lägre? och vad har testtäckning med ekvivalensklasser att göra?
Om du väljer att förenkla din teststrategi med hjälp av ekvivalensklassindelning, kommer många hävda att din testtäckning kommer sjunka, utifrån att du har ett färre antal testfall.
Arbetsinsatsen för att nå en större kodtäckning på kortare tid minskar, kanske blir fler funktioner testade, men den totala testtäckningen ökar inte. Oftast testas färre varianter.
Vad är det då för nytta om inte testtäckningen ökar?
Ekvivalensklassindelning är inte en teknik för att öka den totala testtäckningen, utan snarare att testa fler funktioner smartare på kortare tid.
För att minska den totala testtäckningen genom att ha färre testfall behöver ju inte betyda att systemet är mindre testat.
Skriver man rätt testfall kan det räcka för att täcka kraven.
Och det är här vi knyter ihop det med testtäckning!
För om vi väljer ut testfall utifrån ekvivalensklasser kan vi minska antalet testfall, dvs. minska testinsatsen, men bibehålla kodtäckningen och testtäckningen, bara vi tänker till!
Min egentliga fråga är nog; måste färre testfall (dvs. mindre (inte lägre) testtäckning) tolkas som att systemet testats i mindre utsträckning, eller kan det likväl vara så att om ekvivalensklassindelning används effektivt för att designa testfall, kan 5/5 (100 %) vara bättre än 23/25 (92 %).
- För att inte testa mer än vad som behövs, fokusera på vad som behövs testas.
- Dela upp testerna utifrån testdata (in- utdata) i olika grupper. Kalla dessa grupper ekvivalensgrupper, och fokusera på täckningen i dessa klasser.
- Färre testfall behöver inte betyda sämre testtäckning. M.h.a. ekvivalensklassindelning kan det faktiskt bli både högre kodtäckning och högre testtäckning.
Postad av Daniel Granlund
Kommentarer (0)
Kategorier:
Test
Testtekniker