Software test i Socialstyrelsen af: Jan Kristensen Nov 2013 Introducer mig selv Erfaring som software tester (3 år) Test Manager (3 år) Projektleder (8) år

Agenda Lidt om Socialstyrelsen IT i Socialstyrelsen Software test QA Udviklingsmetode Agurkemetoden Test cases Test automatisering Afslutning

Lidt om Socialstyrelsen Hører under Social-, Børne- og Integrationsministeriet Hovedkontor i Odense Beskæftiger ca. 350 medarbejdere IT-afdelingen består af 25 medarbejdere Al teknisk drift, servere mv er outsourcet 14 systemer driftes, heraf 4 store Næsten al kodning købes ved underleverandører Baggrund for hvor jeg kommer fra

Dokumentation og Metode IT i Socialstyrelsen IT-drift er ansvarlig for system-drift Det betyder, at vi er bindeled mellem forretning og IT-leverandører Vi udvikler kun små opgaver selv Vi står for QA/test Dokumentation og Metode Metode IT-Drift Projekter Drift Vi laver: Leverandørstyring Server drift Dokumentation (teknisk) QA/ved-ligehold Support

IT i socialstyrelsen Forretningen IT-Drift: QA-team IT-leverandør Socialfaglig medarbejder Projektleder QA-ansvarlig Softwaretester, test manager Leverandør af IT-system IT-udvikler af fagsystem Socialfaglig medarbejder Forretningskonsulent Systemejer i forretningen henvender sig vedr kvalitetssikring af nyt system. Lidt forsimplet, da projektlederne ikke er tegnet med. QA-ansvarlige indsamler viden om forretningen. Undertiden får korretningskonsulenterne også lov at skrive test cases i cucumber. QA-ansvarlige rapportere til IT-leverandører og Projektleder fejl mv. IT-udvikler Automatisering af tests

Software test Testarbejder begynder, når projektet begynder Vi stiller krav til test hos udviklerne fra starten af projektet: Fx unittest, samt at koden senere kan testes automatisk Vi står for accepttest Afhængig af forløb og omfang, så kan vi købe hjælp til udvikling af test cases samt test management ved uafhængig leverandør. Automatisk test er langt fra enkelt. Se senere. Leverandørerne gøres opmærksomme på, at vi står fra accepttest. Der findes brådne kar i branchen, som undertiden sender ufærdig kode til test. Velvidende, at koden ikke er færdig, men blot for at vinde tid. De har ingen chance hos os. Hvis projektet er stort, har vi ikke ressourcer til at teste det selv. I så fald køber vi professionel hjælp fra et firma med speciale i test. - Tal lidt om hvad det betyder for jer som udviklere, når kunden stiller disse krav.

Software test - QA Afdækker forretningen og deltager gennem hele projektforløbet Test cases skrives mens koden udvikles (agilt) Tæt samarbejde med projektleder og leverandør for at sikre fodslag mellem test og kode

Software test - Cucumber Vi har valg at benytte Cucumber scripts Cucumber er det værktøj til at teste om softwaren opfører sig som forventet Test cases bliver skrevet i ”naturligt sprog” af dem som kender kravene Derefter bliver de afviklet direkte til kode til automatiserede tests Dette kaldes ”Behavior Driven Development” Cucumber fungerer sammen med Ruby

Software test - Fordele At skrive testscenarier/testcases i naturligt sprog giver bedre forståelse af softwaren til ikke tekniske medarbejdere. De tekniske medarbejdere, som skal afvikle koden får bedre og hurtigere overblik over hvilke krav systemet skal opfylde. Behavior Driven Developement har sin oprindelse i Test Driven Development(TDD) hvor udvikling starter med at skrive testen. 1: vigtigt i en organisation fuld af mennesker, som ikke har et forhold til IT 2: Vigtig egenskab ved værktøjet 3: TDD: Dette betragtes som en fordel da et af målene i Digitaliserings testprocesforbedring er nemlig tidlig test i udviklingsforløbet

Software test - Udviklingsprocessen Tæt samarbejde med projektleder og leverandør Agile metoder anvendes (typisk scrum-lignende) Vi bruger Statens IT-projektmodel (Prince2) Opbygning af realistiske testmiljøer

Test system setup Automatiseret test setup (VIAS): Brugere: Front end: Servicelag: Integrationer: Database: Testhus Cluster Webform Test 1 Test 2 CPR ESB Navision Test udføres i brugergrænsefladen af enten vores testere eller den server, som afvikler automatiserede test. Alle automatiserede test afvikles på dette system alene gennem brugergrænsefladen. Dette skyldes den måde systemet er bygge på. Der er forr.regler i brugergrænsefladen! I andre systemer kan aut. Test også ske på servicelaget eller direkte på integrationer. Setup i test afspejlet produktions setup. Dog er de andre systemer, som benytter ESB ikke tegnet på. Testhus-serveren kan afvikle test cases som natjob. Det tager ca 14 timer at køre alle test igennem. Det skyldes især vores Antivirus-program, de minutiøst scanner al Java. Vi kan ikke slå Antivirus fra pga sikkerhedspolitikken. Det ville reducere testtiden til 5 timer! Grunden til at det tager så lang tid er, at når du tester i brugergrænsefladen, så er du nødt til at være sikker på, at du venter indtil siden er bygget helt op. Ellers kan testen fejle! ESDH Database

Test cases: Test historier Leverance rekvireres Der logges på leverancen Leveranceaftalen ændres (forslag) Leveranceændring godkendes Leverance færdigmeldes Økonomiskema indsendes Økonomiskema godkendes Årsdeling af leverancen Næste års budget Første års budget 1A Opret år 2 rammer og priser (ikke aktive) Kør job: Åben rammedisponering 2A Luk for disponeringer, år 1 3A 4A 5A 6B 7B 8B 9B 10A 10B 11A 11A 12A 13B 14B 15B 16B 17B 18B 19A 20B Forklar principperne i testen. Brug god tid til at komme rundt omkring Bemærk, at der udvikles kode til at gennemføre hver eneste test. Hver test er sin egen test case. En test case er en del af en historie (forløbet for en leverance). Symbolerne er udtryk for forskellige handlinger. Der er tale om komplicerede handlinger, der lægger en helt række forskellige test data ind i systemet. Omfanget af kode der skal til hver enkelt test er derfor betydeligt. Men genbruget er stort. En af udfordringerne ved test i brugergrænsefladen er, at feltnavne ofte navngives dynamisk at udviklingsværktøjet. Det er gift for din automatiserede test, fordi navnene er ændret efter næste build. Vi har løst det ved at sætte ID’er på hvert felt, styret af kompileringen. Det letter søgningen efter feltet, men tabeller, særligt dynamiske grids, er ALTID en udfordring. Opret økonomisk ramme Opret leverandører Tilknyt ydelser Opret sager Forberedelse Måned 1 Måned 2 Måned 3 Måned 4 Måned 5 År 1 År 2

Ex fra system - budgetskema

Test Cases: Planlægning af data Regnearket viser alle tests og deres individuelle resultater.

Test cases – cucumber 1 Forudsætninger # Egenskabet er udarbejdet i forbindelse med test af VIAS' Økonomi. # Session 1-2 # År 1 # Leverandør A # Beskrivelse: Leveranceforløb, som starter i session 1-2 med en budgetopdatering og godkelnedelse. Leverancen færdigmeldes i session 1-3. Der logges forbrug på det gamle år i session 2-1 hvor leverancen afsluttes. # Fortsætter i TC_10A_S1-3, TC_10A_S2-1 Egenskab 10A_S1-2 Baggrund Givet Leverandør A er blevet oprettet Og der er oprettet en sag af VISO-konsulent Og sagen er blevet forberedt til rekvirering af leverance Scenarie Rekvirer leverance Givet jeg logger på som VISO-konsulent Og jeg opretter en leverance for leverandør A Og jeg rekvirerer leverancen Så leverancens status ændres til "visitation anmodet" Og Jeg lukker browseren Og jeg logger ud Forudsætninger Bemærk betingelser og handlinger. Hvis betingelser ikke er opfyldt, så kan TEST CASE ikke gennemføres.

Test cases – cucumber 2 Husk: Linien med inputdata Scenarie Ja tak til leverance Givet jeg logger på som Leverandør A Og leverancen er blevet rekvireret Så jeg finder sagen i min forside i listen "Afventer accept" Og jeg åbner den rekvirerede leverance Og jeg siger ja tak til sagen Så Leverancens status ændres til "I gang" # Visitation= 12,0; Udredning= 22,0; Rådgivning= 30,0; Kørsel(timer= 15; km= 800; udgift= 5000,00) Scenarie Opdatering af budgetskema Givet Jeg er logget på som leverandør A Og Jeg laver ændringer i Budgetskemaet. Når Jeg beder om accept af ændringer Så jeg ser at knappen "Bed om Accept af ændringer" forsvinder Og jeg logger ud Scenarie Godkendelse af ændringer Givet Jeg er logget på som VISO-konsulent Og leverancens budgetændringer er blevet sendt til godkendelse Når Jeg finder sagen i min HOTLISTE på Min forside Og jeg Godkender ændringerne i leverancens budget Så jeg ser at status ændres fra Foreslået til Aftalt Husk: Linien med inputdata Der indføres en ændring Data kommer fra databasen Validering er indbygget

Erfaringer Test automatisering tager tid Det er en forudsætning, at der er styr på alle andre dele af test management Du skal først automatisere test, når systemet når en vis modenhed. At automatisere test er faktisk at starte et udviklingsforløb: Miljøkendskab Sikkerhed Tester testen rigtigt? 1: Ofte undervurderes omfanget. Kig lige en ekstra gang på kompleksiteten… 2: Fortrolighed med at skrive test cases og styre testprocessen er et must. 3: Regn med en betydelig indkøringstid. 4: Miljø: Der går nemt nogle dage med at finde ud af hvorfor en simpel handling, fx tryk på en knap i en browser, bare ikke lige vil… Sikkerhed. Nem-Id kan ikke automatiseres. Lav evt omvej i testsystemet.

Erfaringer Ledelsen skal brænde fingrene! 1: Ofte undervurderes omfanget. Kig lige en ekstra gang på kompleksiteten… 2: Fortrolighed med at skrive test cases og styre testprocessen er et must. 3: Regn med en betydelig indkøringstid. 4: Miljø: Der går nemt nogle dage med at finde ud af hvorfor en simpel handling, fx tryk på en knap i en browser, bare ikke lige vil… Sikkerhed. Nem-Id kan ikke automatiseres. Lav evt omvej i testsystemet.

Afslutning Hermed to links om Behaviour Driven Developement og Cucumber, samt bogen i PDF format: http://www.sitepoint.com/smelly-cucumbers/ http://cukes.info/ bogen ”The Cucumber Book” i PDF.