Test och kvalitetssäkring i Ladok3 Lisa Eliasson, Testsamordnare Göran Kero, Testarkitekt 2012-09-25

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

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

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

Olika typer av test i Ladok3

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)

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)

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

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

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)

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

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)

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

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

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.

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)

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

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

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

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)

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

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

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

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.

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

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

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

Leveranser

FRÅGOR? Lisa Eliasson, lisa.eliasson@du.se Göran Kero, goran.kero@adm.umu.se