Fem framgångsfaktorer för acceptanstest Jesper Högberg Magnus C. Ohlsson
JESPER HÖGBERG Teststrateg och utbildare hos System Verification Testledning, teststrategier, partnerutveckling och kurser Civilingenjör och nationalekonom ISTQB Full Advanced Level Certified REQB FL, ITIL FL, TOGAF FL Certified Arbetat sedan 2001 inom kravställning, systemintegration och test Erfarenhet av olika roller från bank, finans, spel, telekom, myndighet, handel etc. Små/stora projekt och IT program Har utbildat 150+ testspecialister för ISTQB Foundation och Advanced Har sett hur det fungerar bakom kulisserna!
MAGNUS C. OHLSSON Teststrateg och kvalitetsspecialist hos System Verification Processförbättring, teststrategier, kurser, mentorskap osv. Teknologie doktor i programvaruteknik LTH Controlling Fault-Prone Components for Software Evolution ISTQB Foundation och Advanced Test Manager Arbetat inom både stora och små organisationer Domänerna spänner från telekom och medicinteknik till militärt och finans Har innehaft diverse olika roller som testare, testledare och avdelningschef Allt mellan himmel och test
AGENDA Mål och syfte med acceptanstest Förutsättningar Olika typer av acceptanstest Exempel från verkligheten User Acceptance Test Contractual Acceptance Test Operational Acceptance Test Alpha/Beta Test De fem framgångsfaktorerna
MÅL OCH SYFTE Kvittens att systemen passar för sitt ändamål Ta fram ett beslutsunderlag för produktionssättning eller ej Uppnå kvalitetsmål Att veta när leverantören ska få betalt Produktionssätta på utsatt tid Lansera en produkt inom ett kritisk tidsfönster Sälja in produkten eller systemet till användare
FRÅGOR SOM BEHÖVER SVAR Byggde vi rätt system? Är systemet snabbt, snyggt, enkelt, säkert osv? Ger det en hög produktivitet för användaren? Är serverparken dimensionerad för att hantera den stora volymen användare? Vad är den kalkylerade risken vid produktionssättning? Kan vi acceptera systemet och ersätta leverantören enligt det affärsmässiga kontraktet?
FÖRUTSÄTTNINGAR... vi behöver testmiljö, testdata, testfall, testare, testledning, strategi, planer, defektprocess osv. Framgångsfaktor 1: Säkerställ att det finns en teststrategi för helheten... om arbetet och ta tar reda en vecka på tidigare eller sex resultaten månader beror innan av kvalitén acceptanstest Test nivå / Typ Funktionalitet Användar vänlighet Prestanda Teknisk Säkerhet Portabilitet Tillförlitlighet Acceptans x x x x x x System Integration System Integration Unit Vad är redan gjort? Av vem och När? Finns bevis? Dagens exempel
TYPER AV ACCEPTANSTEST User Acceptance Rätt system för sitt ändamål utifrån användarens perspektiv Operational Acceptance Systemets hantering i drift SLA uppfyllnad Säkerhetstest, prestanda, stabilitet osv. Contract and regulation Legala krav, myndighetskrav och säkerhetsstandarder Alpha and Beta Konsumentprodukter som testas av användare innan officiell lansering
USER ACCEPTANCE TEST ÖVERGRIPANDE Exempel på egenskaper från business intelligence och rapportering Användarna som ska genomföra testerna har inte test som huvudsyssla Lång framförhållning krävs Allokeringen oftast deltid under en begränsad tid Syfte, mål, prioritering, testprocess, defekthantering bör vara snabbt och enkelt att förstå Kan det förklaras på 10 minuter är det ännu bättre Förväntningarna måste hanteras Berätta att det är viktigt att få med användare men att fel kan uppstå som de inte vill se
USER ACCEPTANCE TEST PLANERING Uppstart Med beställaren. Allmän information, syfte, mål, resursförfrågan Omfattning Typer av tester, detaljnivå på testfall, ska användarna skriva testfallen själva? Kick-off Målet, syftet, vem testar vad? Hur rapporterar vi utfall och defekter? Vilken är prioriteringen av testfallen? Nu kör vi! Exekvering Beslut Testresultat presenteras, kvarvarande defekter, vad som testats och inte, kända problem. Rekommendation Framgångsfaktor 2: Testledaren är testspecialisten som sköter strukturen och testarna är användare som involveras tidigt månader Testmiljö och data Finns testmiljö på plats? Vilken datavolym krävs? Behövs avidentifiering av data? Planerings möte Med resurser som identifierats Testfall och testdata Testfall förbereds, testdata, användarkonton etc Lagom detaljnivå på testfall
USER ACCEPTANCE TEST KICK-OFF EXEMPEL Syftet Säkerställ att det dagliga arbetet kan göras effektivt i systemet Målet Exekvera planerade testfall och nå accepterad nivå av kända defekter senast 2013-xx-xx Roll Namn Ansvar Mail Telefon Testledare Jesper Högberg Att nå målet jesper.hogberg@kund.se 0709-830508 Testare Kalle Use case X Rapport Z Testare Anna Rapport Y, Use case Y Testare Pelle Funktion Z, Regel X kalle@kund.se 070-1234567 anna@kund.se 010-1234567 pelle@kund.se 073-1234567
USER ACCEPTANCE TEST KICK-OFF (forts.) Prioritering av testfall (mest verksamhetskritiskt först!) Use case X prio 1 Use case Y prio 1 Funktion Z prio 2 Regel X prio 2 Rapport Y prio 3 Rapport Z prio 3 Prioritering Förväntningar Rättningar tar tid. Dessa tider måste vara förankrade! De ska göras, checkas in, kompileras, ny version installeras, omtestas etc. Severity Critical High Medium Low System obrukbart Funktionen obrukbar Ej stoppande för produktion Utseende Priority 1 dag 2 dagar 3 dagar 5 dagar Exit criteria 0 0 5 10
USER ACCEPTANCE TEST EXEKVERING Möte dagligen för defekter - Är det en defekt? Severity? Priority? Assign! - Kan några stängas? Hur optimerar vi ledtiden? Framgångsfaktor 3: Tydligt mål och syfte samt enkla instruktioner tillsammans med prioriteringar och förväntningar Prio 1 Prio 2 Prio 3 Omtest av defekter Säketställ måluppfyllnad Omtest och regressions test, riskbaserat i prioriteringsordning dagar Tester
CONTRACTUAL ACCEPTANCE TEST EXEMPEL Beställaren anlitar konsult för att kvalitetssäkra leverans Beslutsstödsystem med ca. en miljon urvalskriterier Hög komplexitet i logiken och många informationskällor Korrekta beräkningar med hög precision viktigaste egenskapen En testspecialist och ont om tid Läge att höja den teoretiska nivån! Att jobba fler timmar är inte lösningen! En effektiv metod krävs
CONTRACTUAL ACCEPTANCE TEST TEST DESIGN Equivalence All-pairs Partitioning Algorithm: Reducera arbetsmängden och öka testtäckningen Boundary Values
OPERATIONAL ACCEPTANCE TEST EXEMPEL Prestanda och stabilitet måste säkerställas Webbsite med 30000-50000 samtidiga användare vid peaklast Det finns inga dokumenterade krav Webbsite finns och ska ersättas med det som är under utveckling HUR GÖR MAN?
OPERATIONAL ACCEPTANCE TEST ANGREPPSSÄTT Analys och design Trafikstatistik över sidor, antal visningar, prioriterat topp 20 sidor i fokus Testfall skapas som besöker utvalda sidor enligt trafikstatistik Testscript och testdata skapas baseline last URL Hits per hour www.abc.com/kollasaldo 85432 www.abc.com/login 78154 www.abc.com/betala 65543 www.abc.com/transaktioner 61254 www.abc.com/meddelande 48234 peaklast stress stabilitet tid
OPERATIONAL ACCEPTANCE TEST ANGREPPSSÄTT Referenstest av befintlig website Baseline, last, stress och stabilitetstest Genomförs med befintlig webbsite i en storskalig testmiljö Referens för vad den nya siten behöver klara av Acceptanstest av ny website Baseline, last, stress och stabilitetstest körs på den nya siten Svarstider jämförs mellan gamla och nya webbsiten, serverparken dimensioneras, algoritmer trimmas, parametrar konfigureras och optimeras Lastgenerering - Transaktioner per sekund (samtidiga användare) - Svarstid per sida Framgångsfaktor 4: Gör rätt typer av tester och säkerställ rätt egenskaper samt var kreativ vid genomförandet Verktygs UI Monitorer Lastgenerator Systemet - Minne, CPU, disk, lastbalans - Flaskhalsar? API Server - Databaser
ALPHA/BETA TEST ÖVERGRIPANDE Alpha/Beta test används ofta för konsumentprodukter eller tjänster där den enskilda konsumenten är målgruppen Vanligt förekommande inom spelindustrin Bjuder in en liten skara trogna användare för alphatest Går ut till en större mängd användare (betatestare) som får rapportera in problem Ställer stora krav på felhanteringen samt hur man sorterar och prioriterar Använder ibland Tissue testers för att prova spelidéer Inom mobiltelefonindustrin genomförs acceptanstester på ett antal olika sätt och nivåer Olika angreppssätt baserat på om det är plattformar, applikationer eller färdiga mobiltelefoner Ofta ligger fokus på samspelet mellan olika enheter som t.ex. mobiltelefon och basstation alternativt utbyte av data mellan applikationer
ALPHA/BETA TEST EXEMPEL Plattformar En salig röra av olika typer av acceptanstester men ingen riktig alpha/beta test Mobiltelefoner och appar Många infallsvinklar på hur saker skall fungera Fokusgrupper specifika urvalsgrupper med specifika förutsättningar Testfester kunder och konkurrenter testar tillsammans Småskalig spridning inom företaget några få utvalda på testavdelningarna får börja köra Storskalig spridning inom företaget anställda får anmäla sitt intresse Insamling av data i form av dumpar och felrapporter (både automatiskt och manuellt) Alla som tankar ner en app blir en testare
ÄR VI FÄRDIGA? Affärsmässigt mycket viktigt med framgångsrik acceptanstest Betalningspunkt, möjlighet att börja tjäna pengar, göra affärer samt förenkla arbetet En testrapport är ett beslutsunderlag inför driftsättning/lansering Framgångsfaktor 5: En rapport från ett lyckat acceptanstest ger bra beslutsstöd och möjliggör en affärsmässig framgång Testresultat, defektstatistik, kända problem, kvarvarande risker och en rekommendation Rekommendationen från test är en av många underlag inför beslut om driftsättning
DE FEM FRAMGÅNGSFAKTORERNA 2. Testledaren är testspecialisten som sköter strukturen och testarna är användare som involveras tidigt 3. Tydligt mål och syfte samt enkla instruktioner tillsammans med prioriteringar och förväntningar 4. Gör rätt typer av tester och säkerställ rätt egenskaper samt var kreativ vid genomförandet 1. Säkerställ att det finns en teststrategi för helheten och ta reda på tidigare resultaten innan acceptanstest 5. En rapport från ett lyckat acceptanstest ger bra beslutsstöd och möjliggör en affärsmässig framgång
KONTAKTINFORMATION Jesper Högberg Birger Jarlsgatan 9 111 45 Stockholm +46709830508 jesper.hogberg@systemverifivation.com Magnus C. Ohlsson Hyllie Stationstorg 13 215 32 Malmö +46736612860 magnus.c.ohlsson@systemverification.com