Testbilag til IT kontrakter
Grunner til å lage dette testbilaget Unngår å diskutere de samme problemstillingene i hver kontrakt testfaglige selvfølgeligheter blir landet av testfaglig personell en gang for alle Gir et forutsigbart rammeverk for testsamarbeidet Tydeliggjøre lover og forskrifter som kunden og dermed leverandøren må forholde seg til Bilaget må som regel tilpasses hver enkelt leveranse umulig å forutse alt Starter ofte testsamarbeidet med å gå gjennom bilaget og utdype problemstillingene i en felles teststrategi / overordnet testplan 2
Testbilagets innholdsfortegnelse nholdsfortegnelse 1 Testing og godkjenning 1.1 Innledning 1.2 Overordnet teststrategi 1.2.1 Mål for testingen 1.2.2 Leverandørens testnivåer i relasjon til Kundens 1.2.3 Testverktøy 1.2.4 Testdokumentasjon 1.2.5 Krav og kriterier i forbindelse med testgjennomføringen 1.2.6 Kategorisering av avvik (definisjon av feilnivåer) 1.2.7 Feilhåndtering 1.2.8 Testmiljøer 1.2.9 Testdata 1.2.10 Installasjon - Installasjonsdag 1.3 Akseptansetest og godkjenningsperiode 1.3.1 Kundens akseptansetest 1.3.2 Godkjenningsperiode Leveringsdag 3
Mål for testingen Leveransen skal testes og godkjennes slik det fremgår av dette vedlegget. Formålet er å verifisere at leveransen har de egenskapene som kravene og løsningsspesifikasjonen forutsetter. Kontrollere at leveransen tilfredsstiller de krav som er nedfelt i avtalen mellom Kunde og Leverandør Avdekke feil og mangler som måtte finnes i løsningen for der i gjennom å øke kvaliteten på løsningen Gi grunnlag til beslutningstakerne som skal fatte beslutning om akseptanse og driftssetting av løsningen 4
Leverandørens metodikk ift kundens Partene skal fortrinnsvis følge Kundens kvalitetssikringssystem. 5
Leverandørens metodikk ift kundens Partene skal fortrinnsvis følge Kundens kvalitetssikringssystem. Når leverandørens testmetodikk dekker kravene i Kundens kvalitetssikringssystem kan leverandøren følge egen testmetodikk. God praksis, dokumenter forskjeller og bli enige om godt nok Hvor mye skal kunden ha innsyn i (intellectual property)?? Kunde / Underleverandører Leverandør / Konkurrent problemstillinger 6
Krav til Leverandørens tester All nyutviklet kode skal være gjenstand for test (i ulike testnivåer). Med nyutviklet kode menes enten komponenter som er spesialutviklet for Kunden (tilpasninger), eller nyutviklede løsninger der Kunden er første bruker. Standardløsninger som allerede er produksjonssatt og tatt i bruk vil ikke være gjenstand for test. Unntaket her er hvis det i forbindelse med tilpasninger vil være behov for regresjonstest av hele eller deler av løsningen. 7
Ansvarsforhold Klart ansvar på alle testnivåer funksjonelt og ikkefunksjonelt: Eks: Enhetstest: Leverandørens ansvar: Leverandøren er ansvarlig for planlegging, forberedelse (herunder fremskaffelse av testdata), gjennomføring, oppfølging og dokumentering. Kundens ansvar: Intet, Leverandøren oppsummerer og overleverer testrapport på enhetstest/integrasjonstest, Testrapport kan være i form av sjekklister og/eller logg fra automatisert testverktøy. 8
Testverktøy Det er en fordel å benytte felles testadministrativt verktøy I tillegg er prefererte verktøy for ikke funksjonell testing dokumentert Hvem skal holde prosjektet med verktøy? Må vurdere praktisk gjennomføring i henhold til gjeldende lisensavtaler med verktøyleverandører! 9
Testdokumentasjon Dokumentene baseres på malverket til den av partene som er ansvarlig for å utarbeide dokumentet. Malene som benyttes skal være basert på IEEE 829 standard for testdokumentasjon Overordnet testplan utarbeides i samarbeid mellom Kunde og Leverandør i forkant av øvrig testplanlegging. Øvrig dokumentasjon utarbeides i forbindelse med hvert testnivå og avklarte ansvarsforhold slik disse er dokumentert i testbilaget 10
Krav og kriterier i forbindelse med gjennomføringen Startkriterier for testnivå Testplan for testene skal være utarbeidet Leverandøren skal på forespørsel fremlegge sin testrapport fra systemtest før Kunden starter sin akseptansetest Testmiljø skal være klart Testdata skal være tilgjengelig Alle testobjekter må være godkjent i tidligere testnivåer Avbruddsproblematikk Krav for avslutning av testnivå Alle testobjekter skal være testet. Krav til dekningsgrad skal være innfridd Krav til påviste, åpne feil av ulik alvorlighetsgrad 11
Kategorisering av avvik Nivå Kategori Beskrivelse A (1) Kritisk feil Feil som medfører at programvare og/eller utstyr stopper, at data går tapt eller at andre vesentlige funksjoner for Kunden ikke er levert eller ikke virker som avtalt. Feil ved dokumentasjonen som gjør at Kunden ikke kan bruke programvaren eller vesentlige deler av den som avtalt. B (2) Alvorlig feil Feil som fører til at funksjoner som er viktige for Kunden ikke virker som beskrevet i avtalen og som det er tids- og ressurskrevende å omgå. Dokumentasjon som er viktig for Kunden er mangelfull, upresis eller lett kan misforstås. C (3) Mindre alvorlig feil Feil som fører til at enkeltfunksjoner ikke virker som avtalt, men som Kunden relativt lett kan omgå. Dokumentasjon som er dårlig formulert eller kan misforstås. D (4) Kosmetiske feil Feil som ikke påvirker kundens bruk av applikasjonen E (5) Endring F (6) Åpent punkt Dersom det er uklart om det er en feil eller endring 12
Kundens akseptansetest Kunden skal utarbeide og ha ansvar for en plan som beskriver Kundens akseptansetest Omfang Frister fremgår av Prosjektplanen Alle feil skal kategoriseres Stopp og Restart av Akseptansetest A (1)-feil og B (2)-feil som gjør videre undersøkelse umulig Starter ikke igjen før Leverandøren har utbedret feilene. Protokoll for Kundens akseptansetest Kunden skal føre protokoll for hele akseptansetesten Godkjennelse av Kundens akseptansetest 13
Testmiljøer Enhetstester foregår i utviklingsmiljøet. Leverandøren har ansvar for å sette opp og administrere testmiljø for systemtest Nødvendig tilgang til Kundens egne applikasjoner Leverandøren skal tilgjengeliggjøre testmiljø for Kundens akseptansetest i akseptansetestperioden Testmiljøet skal være dimensjonert for å håndtere kapasitets- og stabilitetstester Lisenskostnader / leverandøravtaler 14
Testdata og innsynsproblematikk Testdata hvem leverer hva? Innsynsproblematikk ift personopplysningsloven Maskeringsproblematikk PCI compliance stiller også krav til testmiljøer og testdata 15
Det vi har oppnådd Avklarte forventninger til testgjennomføringen Færre overraskelser - mer forutsigbarhet Riktigere kostnadsdekning Bedre samarbeidsklima i prosjektene Mindre avhengighet til enkeltmedarbeideres samarbeidsevne Medarbeidere som kjenner seg igjen fra prosjekt til prosjekt Enklere hverdag for testledere 16
Godt samarbeidsklima er alltid viktig Testbilag eller ei vi må ha fokus på å samarbeide! Etterstreb å være løsningsorienterte og konstruktive! Vi må spille hverandre gode, vi sitter tross alt i samme båt! 17
Perform together Create effective and close partnerships with our customers Share your insight, build our knowledge Build strong and enthusiastic teams Be curious, open and have fun