1 / 32

Test strategien

til matrixen med fordele og ulemper ved de to fremgangsmetoder. Test strategien. Fejlkategori ( Defectskategori ). Rækkefølge af tests. Ansvarsfordeling (roller og ansvar). Planlægger har ansvaret for ( Bilag 14: Prøver ) :. • Planlægning af testforberedelse

nasim-wong
Download Presentation

Test strategien

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. til matrixen med fordele og ulemper ved de to fremgangsmetoder Test strategien

  2. Fejlkategori (Defectskategori)

  3. Rækkefølge af tests

  4. Ansvarsfordeling (roller og ansvar)

  5. Planlægger har ansvaret for (Bilag 14: Prøver): • Planlægning af testforberedelse • Planlægning af testgennemførelse (#112) omfatter udarbejdelse af en testplan. Det skal præciseres,at der skal udarbejdes en testplan for hver test. Ejerskab af testplanen følger den der har ansvaret for at planlægge testen. • Planlægning af testgodkendelse • Ressourceplanlægning og bemanding i henhold til testorganisationen • Tilvejebringelse af alle forudsætninger for igangsætning og gennemførelse af testen, som beskrevet som startkriterier for hver test i Kapitel 2. • Udarbejdelse af Testbetingelser • Udarbejdelse af Testscenarier • Udarbejdelse af Testcase herunder Testscripts • Tilvejebringelse af nødvendige testværktøjer, herunder værktøj til defect/fejl/afvigelsesrapporteringogopfølgning.

  6. Gennemfører, har ansvaret for (Bilag 14: Prøver): • Løbende planlægning og opfølgning på testplan – herunder genplanlægning hvor testen ikke kan gennemføres som planlagt • Testgennemførelse • Afrapportering, opfølgning og løsning af defects/fejl/afvigelser. (#103) Det er altid Leverandørens ansvar at løsedefects/fejl/afvigelser. • Afrapportering af testresultater – blandt andet i henhold til afsnit 1.8 Opfølgning og afrapportering nedenfor.

  7. Godkender, har ansvaret for (Bilag 14: Prøver): • Foranstaltning af en godkendelsesproces i henhold til godkendelseskriterierne beskrevet i dette bilag, herunder tilvejebringelse af det nødvendige grundlag for at foretage godkendelsen. • Godkendelse af afrapportering jf. afsnit 1.9. • Godkendelse af alle testdokumenter i henhold til dette bilag og bilag 4: Dokumentation. • Opsamling på og udarbejdelse af handlingsplan for at imødekomme alle eventuelle betingelser forbundet med godkendelsen (ved en betinget godkendelse). • Afrapporteringtil projektledelsen, projektets styregruppeog andre af Kundens relevante interessenter.

  8. Test dokumentation

  9. Testdokumentation

  10. Teststrategi Formål Omfang Risikoområder ved afprøvning af Leverancen, samt forslag til begrænsninger af sådanne risici • Vurdering af behovet for afprøvning for at opnå en tilstrækkelig dækningsgrad (ift processer/krav??) • Metode og tilgang for opnåelse af tilstrækkelig dækningsgrad • Specifikation af krav til dokumentation for opnået dækningsgrad • Anvendelse af metoder, teknikker og værktøjer, herunder til automatiseret test • Vurdering af behovet for anvendelse af automatiseret test og forslag hertil Udarbejdelseoggodkendelse Dokumentet udarbejdes som en leverance i (#242) Designfasen. Godkendelsesprocessen for dokumentet fremgår af bilag 4. Dokumentet udarbejdes af Leverandøren og godkendes af Kunden. Dokumentet styrer alle underliggendedokumenterjf. Figur 6: Testdokumentationshierarki.

  11. Test drejebog - 1 Formål Tilhver test skal der udarbejdes en test drejebog, Drejebogen har tilformål at: • DokumentereLeverandørens konkrete operationelle tilgang for de aftalte test • Hvilke principper, metoder, værktøjer der skal anvendes • Forudsætninger for at kunne dokumentere at afprøvning af Leverancen har fundet sted Omfang • Konkrete handlinger for planlægning, gennemførelse og afrapportering for de test Leverandøren er ansvarlig for, samt anvisningertilhandlinger hos Kunden der er nødvendige • Overordnet tidsplan for Kundens deltagelse i hver test, samt estimerede ressourceindsats • Den konkrete brug af metode, teknikker og værktøjer for hver test • Anvendelse af automatisering for hver test m herunder omfang og forudsætninger • Den konkrete organisering hos såvelLeverandør som Kunde for hver test • Oversigt over hvilke testscenarier der skal testes indenfor hvert område af Systemet • Et detaljeret design over hvert testscenarium, herunder omfang, dækningogafhængighedermellem Testscenarier og øvrige projektaktiviteter

  12. Test drejebog - 2 Udarbejdelseoggodkendelse Dokumentet udarbejdes som en leverance i (#242) Designfasen. Godkendelsesprocessen for dokumentet fremgår af bilag 4. Dokumentet udarbejdes af Leverandøren og godkendes af Kunden. Dokumentet styrer alle underliggendedokumenterjf. Figur 6: Testdokumentationshierarki.

  13. TestPLAN - 1 Formål Dokumentet har til formål, at specificerer de testcases der skal udføres for at opnå den nødvendige dækning indenfor det område scenariet dækker eller forventes at dække. Dokumentet styrer alle underliggende dokumenter der ligger til grund for Afprøvning af Leverancen. Omfang En oversigt over hvilke testscenarier der er nødvendige for at opnå den nødvendige dækning ogafprøvning af Leverancen • Rækkefølgen af Testscenarier • Tidsplan for testforløb med milepæl • Testbemanding med angivelse af navngivne personer og testrolle i hvert testscenarium • Angivelse af tidspunkter for gennemførelse af hvert testscenarium • Specifikation af eventuelle fysiske hensyn som forudsætning for test • Specifikation af krav til miljøer, grænseflader, testdata • Plan for hvordan startkriterierne for den pågældende test tilvejebringes

  14. TestPLAN - 2 Udarbejdelseoggodkendelse Dokumentet udarbejdes som en leverance i Implementeringsfasen. Godkendelsesprocessen for dokumentet fremgår af bilag 4. Dokumentet udarbejdes af Leverandøren og godkendes af Kunden. Dokumentet styrer alle underliggendedokumenterjf. Figur 6: Testdokumentationshierarki.

  15. Testscenarium - 1 • Formål • Dokumentet har til formål, at specificere de testcases, der skal udføres indenfor det område det testscenarium, som tescasene vedrører, dækker eller forventes at dække. • Omfang • Dokumentet skal som minimum omfatteogbeskrivefølgende: • • En samlet oversigt over hvilke testcases, der udføres som en del af scenariet for at opnå en fyldestgørende afprøvning af det pågældende testscenarium jf. teststrategien • • En beskrivelse af hver Testcase, mht. formål og hvilke processer/krav der er omfattet, samt • Nummer • Titel på testscenariet • Beskrivelse (kort) • Testcyklus • Procesområde(r) (inkl. reference til procesmodellen) • Procesansvarlig (jvf. testorganisationen i Figur 1) • • Specifikation af afhængigheder mellem Testcases • Udarbejdelseoggodkendelse

  16. Testscenarium - 2 Udarbejdelseoggodkendelse Godkendelsesprocessen for dokumentet fremgår af bilag 4. Dokumentet udarbejdes af Leverandøren og godkendes af Kunden. Dokumentet styrer alle underliggendedokumenterjf. Figur 6: Testdokumentationshierarki.

  17. Testcase - 1 Formål Dokumentet har til formål, at specificere de konkrete testcases der skal udføres for at teste et eller flere konkrete krav tilLeverancen. Omfang Dokumentet skal som minimum omfatteogbeskrivefølgende: • En samlet oversigt over hvilke testcases, der udføres som en del af scenariet for at opnå en fyldestgørende afprøvning af det pågældende testscenarium, jf. teststrategien • En beskrivelse af hver testcase, mht. formåloghvilke processer/krav, testcasenomfatter • Specifikation af afhængigheder mellem testcases • En beskrivelse af formål, testbetingelser, inputdata, testbrugerroller, samt forventede resultater og acceptkriterier for hvert testcase, herunder: o Testfase (brugertest, overtagelsesprøve) o Testscenarium (Nr. + Titel) o Testcyklus (1, 2, 3) o Test case nummer o Test case titel o Beskrivelse (kort) o Referencetilprocesmodellen

  18. Testcase - 2 • Omfang - forsat • Udarbejdelse af test case: • Udarbejdet af (navn) • Udarbejdelsesstatus (Ikke påbegyndt, I gang, Afsluttet, Annulleret) • Udførelse af test: • Tester (navn) • Test status (Ikke påbegyndt, Klar til test, I gang, Stoppet pga. fejl, Afsluttet, Annulleret) • Testfremdrift (0%, 20%, 40%, 60%, 80%, 100%) • Kommentar (kort) • Test stamdata (hvilke kunder, etc. der anvendes) • Udarbejdelseoggodkendelse • Udarbejdelseoggodkendelse • Godkendelsesprocessen for dokumentet fremgår af bilag 4. • Dokumentet udarbejdes af Leverandøren og godkendes af Kunden. • Dokumentet styrer alle underliggendedokumenterjf. Figur 6: Testdokumentationshierarki.

  19. Testscript - 1 • Formål • Dokumentet anvendes til registrering af testresultater ved gennemførelse af en specifik testcase. • Omfang • Dokumentet skal som minimum omfatteogbeskrivefølgende: • • Beskrivelse af hver af de handlinger testpersoner skal udføre for at teste det/de pågældende krav, testbetingelser, inputdata der skal anvendes, samt mulighed for at noteretestresultater, herunder: • Nummer • Handling (hvad man skal udføre) • Input data • Test brugergruppe • Forventet resultat • Testbetingelsesnummer • Faktisk resultat (udfyldes under testen) • OK (Ja, Nej) (udfyldes under testen)

  20. Testscript - 2 Udarbejdelseoggodkendelse Godkendelsesprocessen for dokumentet fremgår af bilag 4. Dokumentet udarbejdes af Leverandøren og godkendes af Kunden. Dokumentet styrer alle underliggendedokumenterjf. Figur 6: Testdokumentationshierarki.

  21. Testrapport Formål Dokumentet anvendes til afrapportering for hvert gennemført testscenarium. Omfang Dokumentet skal som minimum omfatteogbeskrivefølgende: • En entydig referencetil det/de testscenarier som testrapporten omhandler • En kopi af listen over afvigelser konstateret undervejs, samt status for hver enkelt • Antallet af afvigelser per testcase og gennemførte korrigerende handlinger • Beskrivelse af om der har været foretaget re-test og hvor, samt resultat • Delkonklusion for hver testcase der er gennemført under testscenariet i forhold til acceptkriterierne for den pågældende test • En entydig konklusion af hvorvidt det afrapporterede testscenarium kan godkendes Udarbejdelseoggodkendelse Godkendelsesprocessen for dokumentet fremgår af bilag 4. Der skal udarbejdes en Testrapport per gennemført Testscenarium.

  22. Test Typer

  23. Brugervenlighedstest: xx.04.12 -XX.04.12 Start kriterier • Systembeskrivelse godkendt af Kunden. • Godkendt teststrategi. • Godkendt drejebog. • Godkendt plan for Testen. • Godkendt Scenarier for testen. • Kravene og områderne for testen specificeret. • Dokumentation for træning af Leverandørens testpersoner. • Godkendte acceptkriterier. • System bruger grænseflade har en færdiggørelses grad, så kunden kan navigere meningsfyldt rundt. Formål: Formålet med testen er at verificere, at Kundens krav til Systemets brugervenlighed er imødekommet. OMFANG • Dansk Systemets brugergrænseflade • logisk opbygget, overskuelig og intuitiv systemets brugergrænseflade • Entydige og forståelige elementerne på Systemets brugergrænseflade • Findes de nødvendige og relevante hjælpefunktioner/tekster i Systemets brugergrænseflade • Tydelige, entydige og forståelige fejlmeddelelser til brugeren fra Systemet • visuelt attraktiv systemets brugergrænseflade SLut kriterier • Systembeskrivelse godkendt af Kunden. • Test specificeret i godkendt teststrategi. • Testen specificeret i godkendt drejebog. • Godkendt plan for Testen. GoDKendelsesKrav: • GoDKendelse: •Testrapport skriftligt godkendt af kunden, prøven er bestået i hhtgodkendelse krav. Ansvarsfordeling: • Planlægger : Leverandør • Gennemfører : Kunden • Godkender : Kunden TEST PRODUKTER: • Testcases • Fejlrapporter • Testrapport (Brugervenlighedstest) MILJØ: • Testmiljø

  24. KOmponenttest: XX.XX.12 -XX.xX.12 Start kriterier • Test før denne skal være godkendt • Godkendt teststrategi • Godkendt drejebog for test • Godkendt testplan • Godkendt testscenarier • Godkendt testcase • Leverandøren kan fastsætte ydreligere start kriterier Formål: Formålet med testen er at Kunden verificerer, at hver komponent i Systemet er testet, at verificere, at Systemet er klar til igangsætning af systemintegrationstesten. Komponenttesten s kontrollerer funktionen af Programmel, og foretages, når den enkelte komponent er færdigudvikletogdokumenteretog kvaliteten er verificeret i henholdtilLeverandørenskvalitetssikring. OMFANG • Komponenttesten er en funktionelog teknisk test (White-box test) • Solution Considerations er opfyldt •teste integrationen af de komponenter, der har væsentligt indbyrdes samspil. • Komponentintegrationstest • • SLut kriterier • Systembeskrivelse godkendt af Kunden. • Test specificeret i godkendt teststrategi. • Testen specificeret i godkendt drejebog. • Godkendt plan for Testen. GoDKendelsesKrav: • • • GoDKendelse: • Testrapport skriftligt godkendt af kunden, prøven er bestået i hhtgodkendelse krav. Ansvarsfordeling: • Planlægger : Leverandør • Gennemfører : Leverandør • Godkender : Leverandør • Kunden har ret til at deltage som observatør TEST PRODUKTER: • Testcases • Fejlrapporter • Testrapport (Komponenttest) MILJØ: • Testmiljø

  25. Systemintegretionstest: XX.XX.12 -XX.xX.12 Start kriterier • Test før denne skal være godkendt • Godkendt teststrategi • Godkendt teststrategi • Godkendt testplan • Godkendt testscenarium • Godkendt testcase • Leverandøren kan fastsætte ydreligere start kriterier Formål: Formålet med testen er at Leverandøren før, levering af Systemet, verificerer, at den aftalte funktionalitet for Systemet opfylder alle Kundens krav til Leverancen. Systemintegrationstesten er en funktionel test samt en integrationstest, som skal verificere, at Systemet er klar til igangsætning af test, hvor Kunden er involveret og kan kommunikere med eksterne it systemer udenfor Kundens it-miljø, som forudsat i Leverancebeskrivelsen. SLut kriterier • Systembeskrivelse godkendt af Kunden. • Test specificeret i godkendt teststrategi. • Testen specificeret i godkendt drejebog. • Godkendt plan for Testen. GoDKendelsesKrav: • Ingen udestående defects (kritiske fejl, større fejl) i Systemet • skriftlig godkendt testrapport • Selve GoDKendelsen: • Testrapport skriftligt godkendt af kunden, prøven er bestået i hhtgodkendelse krav. OMFANG • Kravsopfyldelse fra Kontrakten, Kravspecifikationen, Systembeskrivelsen, godkendte ændringsønsker samt øvrige aftalte designbeslutninger i projektet. • Det integrerede System fungerer i henhold til kravene og afledte specifikationer • Alle komponenter er tilstedeogsnitfladernemellem dem fungerer i henholdtilkravene og deres afledte specifikationer. • Alle applikationskomponenter er tilstedeogsnitfladernemellem dem fungerer i henhold til kravene og deres afledte specifikationer. • Kommunikationen fra Systemet tileksterneit-systemerfungerer •Test af integrationen til andre systemer tester både snitfladerne til Systemet i og uden for løsningen samt de forretnings processer der måtte være implementeret i arbejdsgange som involverer andre Systemer i oguden for løsningen. MILJØ: • Testmiljø Ansvarsfordeling: • Planlægger : Leverandør • Gennemfører : Leverandør • Godkender : Leverandør • Kunden har ret til at deltage som observatør TEST PRODUKTER: • Testcases • Fejlrapporter • Testrapport (Systemintestration)

  26. Installationsprøve 1: XX.XX.12 -XX.xX.12 Start kriterier • Test før denne skal være godkendt • Godkendt teststrategi • Godkendt teststrategi • Godkendt testplan • Godkendt testscenarium • Godkendt testcase • Leverandøren kan fastsætte ydereligere start kriterier Formål: Formålet med testen er at sikre at det nødvendigeudstyrogProgrammel er tilstede i henholdtil Systembeskrivelsen. At systemet kan installeres på det i Systembeskrivelsen specificerede miljø. At konfiguration af Systemet kan gennemføres i henhold til Systembeskrivelsen samt at Installation af Systemet kan gennemføres i henhold til Installationsvejledningen OMFANG • Installationstest • overdragedeinstallationsmateriale (installationsmedie, dokumentation o.l.) afprøves • Afprøve Systemet af i et kundelignende miljø. • Verifikation af at platformen virker, herunder at operativsystem m.v. er funktionsdygtigt. • Afprøvning at netværk, sikkerhed (adgange og rettigheder), tilknyttede alarmer, monitorering, grænseflader, backup og storage, samt dataadgange fungerer, som specificeret. • Mulighed for at prøve applikationer under forskellige forholdf.eks. forskellige operativsystemer, div. office-pakker, hardwarekonfigurationer og/eller forskellige båndbredder o.l. SLut kriterier • Systemet kan installeres på det i Systembeskrivelsen specificerede miljø • Konfiguration af Systemet kan gennemføres i henhold til Systembeskrivelsen • Installation af Systemet kan gennemføres i henhold til Installationsvejledningen. • Skriftliggodkendt testrapport. GoDKendelsesKrav: • Ingen udestående defects (kritiske fejl, større fejl) i Systemet • skriftlig godkendt testrapport • Selve GoDKendelsen: • Testrapport skriftligt godkendt af kunden, prøven er bestået i hhtgodkendelse krav. MILJØ: • Testmiljø TEST PRODUKTER: • Testcases • Fejlrapporter • Testrapport (Systemintestration) Ansvarsfordeling: • Planlægger : Leverandør • Gennemfører : Leverandør • Godkender : Kunden • Kunden har ret til at deltage som observatør

  27. Konverteringsprøve 1: XX.XX.12 -XX.xX.12 Start kriterier • Test før denne skal være godkendt • Godkendt teststrategi • Godkendt teststrategi • Godkendt testplan • Godkendt testscenarium • Godkendt testcase • Dokumentation for træning af Leverandørens testpersoner foreligger • GodkendtKonverteringsanalyse • Godkendt Konverteringsstrategi •GodkendtKonverteringsdrejebog • Yderlige start kriterier kan fastsætte af Leverandør Formål: Formålet med testen er at sandsynliggøre, at Leverandørens løsning til konvertering af Kundens data lever optilkravenetil konvertering i henholdtilBilag 3 samt at sandsynliggøre Leverandørens beregninger af, hvilken tid der vil medgå til den endelige konvertering af data forud for idriftsættelsen. Herudover verificere at Leverandørens metoder, teknikkerogværktøjertil datakonvertering fungerer, Data som prøvekonverteres over i Systemet placeres korrekt i Systemet, Både stamdata og transaktionsdata er komplette og sammenhængende, således at alle Systemets funktioner kan anvendes uden fejl som følge af manglende /ukorrek-te data OMFANG • Afstemning af totaler, sumposter, antal m.v. for at teste kompletheden af data • Kontrol af konsistens i data sammenlignet med Kundens eksisterendesystemer (kildesystemer) • Kontrol af revisionsspor og transaktionsspor i form af logning på record-niveau og afstemningsrapporter • Funktionel test af data med hensyn til korrekthed, komplethed, samt Systemets anvendelse af disse data. SLut kriterier • Systemet kan installeres på det i Systembeskrivelsen specificerede miljø • Konfiguration af Systemet kan gennemføres i henhold til Systembeskrivelsen • Installation af Systemet kan gennemføres i henhold til Installationsvejledningen. • Skriftliggodkendt testrapport. GoDKendelsesKrav: • Konverteringener gennemført uden tab af data eller forvansket data. Dokumentation af at beregning af konverteringstidener korrekt og retvisende • skriftlig godkendt testrapport • Selve GoDKendelsen: • Testrapport skriftligt godkendt af kunden, prøven er bestået i hhtgodkendelse krav. MILJØ: • Testmiljø TEST PRODUKTER: • Testcases • Fejlrapporter • Testrapport (Systemintestration) Ansvarsfordeling: • Planlægger : Leverandør • Gennemfører : Leverandør • Godkender : Kunden • Kunden har ret til at deltage som observatør

  28. KE’s ønske om brugervenlighedstesten - 1 KE’s ønske En detaljeret gennemgang af Følgende områder, hhv før og efter udviklingen Efter udviking (55): Før udviking (8): Kundesager EMMA Opsætning af CICO Dokumentarktiv Service ordre Kundeportalen Flytninger i kundeservice Reporting services

  29. Definition af Tekniske test & funktionel test Tekniske test: Test af systemets interne struktur. Test som kun leverandøren kan udføre. Test som man ikke kan forvente at en kompetent bruger af systemet kan udfører. Test af tekniske kvalitets attributter, f.eks. ydeevne, sikkerhed etc. Test af de tekniske krav. Eksempler: test af krypteringer, OIO faktura, nem id Funktionelle test: Test baseret på en analyse af specifikationen af en komponent eller et systems funktionalitet.

  30. KE’s ønske om brugervenlighedstesten - 2 Efter udvikling:

  31. Test planen Alternativ 2: Simpel planlægning Alternativ 1: Produkt risikoanalyse Udvikling Test Produkt Risiko Analyse Planlægning af test 26.10.2012 08.2012 Udvikling Test (17 uger) Overtagelses prøve Go live 26.10.2012 01.03.2013 25.03.2012

  32. PRA: fordele og ulemper

More Related