Test och kvalitetssäkring i Ladok3

En presentation över ämnet: "Test och kvalitetssäkring i Ladok3"— Presentationens avskrift:

1 Test och kvalitetssäkring i Ladok3
Lisa Eliasson, Testsamordnare Göran Kero, Testarkitekt

2 Vilka är vi? Lisa Eliasson Göran Kero
Testsamordnare, Utforskande tester, Ladok3-projektet Kravsamordnare, Ladokkonsortiet Ladokansvarig, Högskolan Dalarna Göran Kero Testarkitet, Ladok3-projektet ITS, Umeå Universitet

3 Agenda Testöversikt Ladok3 Verksamhetstester
Testmiljöer, införandestöd och integration Lärosätenas delaktighet Frågor och diskussion

4 Hur arbetar Ladok3-projektet med kvalitet?
Syfte Stödja utveckling  Utvärdera produkten Förebyggande  Hitta buggar Bygga rätt produkt  Bygga produkten rätt Fokus Verksamhet  Teknik Ansats Verifiera  Utforska Mottagare Produktion  Förvaltning

5 Olika typer av test i Ladok3

6 Testöversikt Ladok3 Verksamhetsfokus Utvärdera produkten
Stödja utvecklingen Utvärdera produkten Verksamhetsfokus Tekniskt fokus (Brian Marick’s Agile Testing Quadrant – fritt översatt med vissa justeringar)

7 Testöversikt Ladok3 Verksamhetsfokus Utvärdera produkten
Stödja utvecklingen Utvärdera produkten Verksamhetsfokus Tekniskt fokus Enhetstester Interna integrationstester (Test-driven utveckling) (Brian Marick’s Agile Testing Quadrant – fritt översatt med vissa justeringar)

8 Enhetstester Vem? Utvecklingsteam När? Ständigt vid utveckling Hur?
Automatiska tester (JUnit) Perspektiv? Tekniskt Varför? Stödja utveckling Testa produktens beståndsdelar

9 Interna integrationstester
Vem? Utvecklingsteam När? Kontinuerligt Växer i takt med produkten Hur? Automatiska tester Perspektiv? Tekniskt helhetsperspektiv Varför? Stödja utveckling Säkerställa att produktens delar hänger ihop

10 Testöversikt Ladok3 Verksamhetsfokus Utvärdera produkten
Stödja utvecklingen Utvärdera produkten Verksamhetsfokus Tekniskt fokus Cucumbertester (Prototyper) (Beteende-driven utveckling) Enhetstester Interna integrationstester (Test-driven utveckling) (Brian Marick’s Agile Testing Quadrant – fritt översatt med vissa justeringar)

11 Cucumbertester Vem? Områdesproduktägare/domänexperter tillsammans med utvecklingsteam När? Vid domänanalys (detaljering av krav) Hur? Exempel formulerade i klartext Implementeras som automattester av utvecklingsteam Perspektiv? Verksamhet (krav) Varför? Säkerställa rätt funktionalitet Tydliggöra kraven Stöd vid förändring

12 Testöversikt Ladok3 Verksamhetsfokus Utvärdera produkten
Stödja utvecklingen Utvärdera produkten Verksamhetsfokus Tekniskt fokus Cucumbertester (Prototyper) (Beteende-driven utveckling) Utforskande tester Användbarhetstester Acceptanstester Enhetstester Interna integrationstester (Test-driven utveckling) (Brian Marick’s Agile Testing Quadrant – fritt översatt med vissa justeringar)

13 Utforskande tester Vem? Verksamhetstestare Utvecklingsteam När?
Kontinuerligt Hur? Manuella funktionella tester Planeras och dokumenteras strukturerat Perspektiv? Verksamhet Varför? Utvärdera produkten Hitta buggar

14 Användbarhetstester Vem?
Verksamhetsrepresentanter tillsammans med användbarhetsexpert När? Vid utvalda tillfällen Hur? Användargrupper Perspektiv? Verksamhet Varför? Tidigt bedöma om produkten är användarvänlig och uppmärksamma brister i användbarhet

15 Acceptanstester Vem? Mottagande förvaltning/lärosäten (i samarbete med projektet) När? Innan leverans till förvaltning Hur? Manuella tester Tvärsnitt av fullskalig produktion Perspektiv? Verksamhet Varför? Bedöma om produkten håller tillräckligt hög kvalitet för leverans Produktion och förvaltning Ta även upp dokumentation på denna punkt.

16 Testöversikt Ladok3 Verksamhetsfokus Utvärdera produkten
Stödja utvecklingen Utvärdera produkten Verksamhetsfokus Tekniskt fokus Cucumbertester (Prototyper) (Beteende-driven utveckling) Utforskande tester Användbarhetstester Acceptanstester Icke-funktionella tester (Prestanda, säkerhet etc) Test mot externa system Leveranstester Enhetstester Interna integrationstester (Test-driven utveckling) (Brian Marick’s Agile Testing Quadrant – fritt översatt med vissa justeringar)

17 Icke-funktionella tester (ex prestanda, säkerhet, installerbarhet etc)
Vem? Utvecklingsteam Specifik testkompetens När? Delvis kontinuerligt Delvis vid behov/”när det är klart” Hur? Tekniska tester, till stor del med verktygsstöd Perspektiv? Tekniskt Varför? Minimera risken för allvarliga incidenter

18 Test mot externa system
Vem? Utvecklingsteam i samarbete med ansvariga för det externa systemet När? Då den aktuella kopplingen är tillräckligt klar Vid behov (ex förändringar på någon sida) Hur? Simulering av verkligheten Perspektiv? Tekniskt/verksamhet Varför? Säkerställa att produkten fungerar tillsammans med sin omvärld

19 Leveranstester Vem? Utvecklingsteam (CM/Sysadmin/DBA) När?
Vid release av ny version Hur? Automatiska och manuella tester Perspektiv? Tekniskt Varför? Upptäcka om någon kritisk funktion fallerar

20 Testöversikt Ladok3 Verksamhetsfokus Utvärdera produkten
Stödja utvecklingen Utvärdera produkten Verksamhetsfokus Tekniskt fokus Cucumbertester (Prototyper) (Beteende-driven utveckling) Utforskande tester Användbarhetstester Acceptanstester Icke-funktionella tester (Prestanda, säkerhet etc) Test mot externa system Leveranstester Enhetstester Interna integrationstester (Test-driven utveckling) (Brian Marick’s Agile Testing Quadrant – fritt översatt med vissa justeringar)

21 Utforskande tester A program is a collection of opportunities for things to go wrong

22 Utforskande tester För att utvärdera produkten
Som ett komplement till alla andra tester Används för att hitta fel som inte hittas med vanliga maskinella tester. Varför används utforskande tester? -Utforskande tester är ett brett sätt att testa För att utvärdera produkten Att den inte är direkt felaktig har föregående tester kollat av. Är det den produkt vi var ute efter? Är den ”tillräckligt” bra att släppa? Som ett komplement till andra tester Som Göran visat tidigare Används för att hitta fel som inte hittas med vanliga maskinella tester Vissa fel och brister uppstår vid handhavandet – inte direkt av programmet

23 Utforskande tester Man testar inte samma sak på riktigt samma sätt två gånger Testfall som utvecklas hela tiden Testarna uppfinner sina testfall – utifrån givna ramar -Man testar inte samma sak på riktigt samma sätt två gånger -Ett maskinellt test kan missa samma fel om och om igen och aldrig hitta det, eftersom det inte är konstruerat för att hitta just det felet. -I ett utforskande test används den mänskliga faktorn -Testfallen utvecklas då hela tiden och nya fel och brister kan hittas -Testarna kan också snabbt växla till ett nytt prioriterat område -Testarna uppfinner sina testfall – utifrån givna ramar -utifrån en given ram kan testaren fritt utforska hela området och hitta stickspår att följa direkt eller senare

24 Utforskande tester Utförs av testare från den verksamhet som ska använda systemet. Vi kan testa STORT och vi kan testa smått Vi kan testa brett eller smalt Vi kan testa funktion eller upplevelse Här trycker jag extra på VI – jag är ju en representant för verksamheten -Utförs av testare från den verksamhet som ska använda systemet. - De kan relatera till hur systemet funkar i den dagliga verksamheten. De har god insyn i studieadminstration idag och hur vad som kommer att förändras i och med Ladok3 -Vi bygger våra test utifrån det som kommer fram i sprintarna, men är inte helt beroende av dem. Vi kan välja att under en viss period testa de små nya delarna för att sedan övergå till att testa hur det nya påverkar det gamla och då testa hela flödet.

25 Ytterligare tester Test av informationskonverterare
I samarbete med införandeprojektet Test av integrationer hos lärosäten Tillhandahålla ändamålsenliga testmiljöer Testdata av god kvalitet Stötta lärosätenas tester Samla generella (återkommande) spörsmål Bidra till samverkan

26 Projektets interna testmiljöer
Kontinuerlig integration Intern test inom sprintar Sprintdemo Verksamhetstester Test av informationskonvertering Prestandatester Nämna om testmijöernas uppgift

27 Externa testmiljöer Utvärderingsmiljö för REST-tjänster
Hösten 2012 MIT – Migrerings- och integrationstestmiljö Fr o m våren 2013 Test av lärosätenas integrationer Informationskonvertering Acceptanstestmiljö Väldigt preliminär planering

28 Leveranser

29 FRÅGOR? Lisa Eliasson, lisa.eliasson@du.se
Göran Kero,