Fem framgångsfaktorer för acceptanstest. Jesper Högberg Magnus C. Ohlsson



Relevanta dokument
Teststrategier och Testcertifiering. Per Strandberg, Maj 2013

Uppgift v1: Teststrategi i sammanhang Terese Berger. Teststrategi. Projekt CiviCRM. Version 0.9. Sida 1(7)

Sänk kostnaderna genom a/ ställa rä/ krav och testa effektivt

Copyright Prolore All Rights Reserved.

Spetskompetens inom systemintegration, SOA och systemutveckling

Configuration testing Why? Vad det är tänkt att koden ska göra. Performance testing Kommentarer Skriva om koden som kommentar

Automatiserade testsystem

Processinformation. Förvaltningsmöte Elvis och SURF Kerstin Lyngfelt Processledare VGR IT

Kurser och seminarier från AddQ Consulting

Värdering och skydd av immateriella tillgångar Magnus Henrikson

Test. Eleonore Hammare 16 April. NFI:s konferens om test

Testning som beslutsstöd

Konsultbolag1. Testplan för Europa version 2. Testplan Projekt Europa Sid 1 (av 9) Europa-projektet. Dokumenthistorik

SF Bio App. Repport. Test summary. 1- Syfte. 2. Produktöversikt. Författare: Zina Alhilfi Datum: Version: v1,0

Delivering Business Value through IT

Från vaga testuppdrag till förankrad teststrategi

Tjänstespecifik teststrategi. För anslutning till tjänsteplattform för vård- och omsorgsutbud

Jonas Hermansson

Belastningstester med Visual Studio Gränssnittet

Regelverk. Infrastrukturen för vidareförmedling av grundläggande uppgifter om företag. Bilaga C. Servicenivåer Producent, UC. Version: 1.

Acceptanstest av vårdsystem i Västra Götalandsregionen

Exempel på verklig projektplan

Microsoft ALM Agenda. Processer metoder Kundcase Paus Under huven på Visual Studio Team Test Frågor och Svar + en liten tävling

Testbara krav. SAST Syd Ställ gärna frågor under presentationen eller efteråt Åhörarkopior distribueras efteråt

Processbeskrivning Test

Framgångsfaktorer i molnet!

- Effektiv prestandatestning, teknisk verifiering, tuning, verifiera krav, förvalta prestanda

PEAK PERFORMANCE 11 JUNI 2015

Hur kvalitetssäkra komplexa IT-lösningar och vad är egentligen test?

QC i en organisation SAST

Användning av testautomation inom Extendas utvecklingsorganisation

Fem fördelar med att automatisera redovisningen

Regressionstestning teori och praktik

HP ALM som stöd under implementationslivscykeln av standard applikationer Sarah Eriksson & Per Nordlander SAST

Kapitel 4 Arkivmenyn Innehåll

Jeeves BI 3.0 JEEVES WORLD 2012 LASSE HELLBERG. Copyright 2012 Jeeves Information Systems AB

Dag König Developer Tools Specialist Microsoft Corporation

Testarens roll i en förunderlig NFI Testforum

Tjänsteavtal för ehälsotjänst

IBM Software Group. Agil Acceptans Test. Annika Kortell SAST 15-års jubileum IBM Corporation

Kursöversikt Certifierad Mjukvarutestare

Checklista för Driftsättning - Länsteknik

Bilaga 4g. Servicenivåer. Upphandling av ett helhetsåtagande avseende IT-stöd för pedagogiskt material inom Sko l- plattform Stockholm

Testning på 3 föreläsningar. PV7180 Verifiering och Validering. Litteratur. Vad är testning? Varför testa och olika syn? Målet med testning

Agil testning i SCRUM

TDDI02. Programmeringsprojekt. Föreläsning 3 Jonas Lindgren, Institutionen för Datavetenskap, LiU

Microsoft Visual Studio Team System 2008 Test Edition

Regelverk. Infrastrukturen för vidareförmedling av grundläggande uppgifter om företag. Bilaga B. Servicenivåer konsument, SLA. Version: 1.

Våra älskade och hatade applikationer! Våra älskade och hatade applikationer! Atea Application Center Applikationshantering dyrt och tidsödande, eller

Är din plattform redo för High Performance?

Testautomation av sammansatta och mobila applikationer. Magnus Nilsson Lemontree

Testdriven utveckling. Magnus Jonsson Siemens Medical Solutions

ARX på Windows Vista, Windows 7 eller Windows 2008 server

Att komma igång med Riskbaserad Testning

Platina och kvalité. Rasmus Staberg, Teknisk direktör,

Donator. Partnerprogram. Från produkt till molntjänst.

Så blev arkitekturen ett kitt mellan IT och den övriga verksamheten

M3 DB Cleanup and Archive

på ett stort spelföretag Andreas Ström

SLA (Service Level Agreement)

Bli framgångsrik med CRM. Det behöver inte vara så komplicerat! made for sales people

Hå rd- och mjukvårukråv såmt rekommendåtioner fo r 3L Pro from version 2015.Q1

Testautomatisering. Intro

Gösta Ljungberg 31 mars 2014

Mobilt Efos och ny metod för stark autentisering

Advanced Mobile Device Management

Version Testteam 4 Testledare: Patrik Bäck

Rutinbeskrivning Mallar för test

Big Data i spelbranchen

Metoder och verktyg för funktionssäkerhet

iscala Credit Management Scalabruk höstmöte 2011 Presenteras av: Fred Boström

ELVIS & SURF Test version 5.0

FRAMTIDENS DIGITALA EKONOMIFUNKTION

HANDLEDARE: Jonny Pedersen Datum: (Detta skrevs i November 09)

Mobilt Efos och ny metod för stark autentisering

FÖRELÄSNING 8 DSV2PVT

Testplanering, test-first, testverktyg

Datasäkerhet och integritet

ADITRO LÖSNINGAR FÖR EN ENKLARE JOBBVARDAG SUMMIT 2014 MATS REIVANT ERFARENHETER FRÅN BYTE AV LÖNESYSTEM

Sourcingdagarna, 8-9 Februari

Tomas Axelsson

Uppdateringsguide v6.1

Region Skåne Granskning av IT-kontroller

Visionen om en Tjänstekatalog

Attitude is everything. Peter Ericson, VD Exait AB

Region Dalsland

Varför testar vi? Att skaka fram förankrade testuppdrag

Botkyrka Kommun. Revisionsrapport. Generella IT kontroller Aditro och HRM. Detaljerade observationer och rekommendationer.

Hå rd- och mjukvårukråv såmt rekommendåtioner fo r 3L Pro from version 2013.Q3

Byta system bli klar i tid och undvik onödiga kostnader

Kravspecifikation. Crowdfunding Halland

Checklista Integrationsförnyelsen

Capitex dataservertjänst

Att utveckla, förvalta, och införa FGS:er Testmetodik

Viktigt! Glöm inte att skriva Tentamenskod eller namn på alla blad du lämnar in.

Digitala videomöten vid samordnad vårdplanering - Delprojekt IT-Nära

GEOSECMA FASTIGHET...

Microsoft Dynamics 365 Business Application vs. ERP. Företagen måsta sätta sig själva i förarsätet

Landstingsstyrelsens förvaltning SLL Juridik och Upphandling. Upphandlingsavdelningen Bilaga 1. Kravspecifikation

Martin Völcker, SLL & Suit

Transkript:

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