10 spørgsmål der vil hjælpe dig med dine testcases

Relaterede dokumenter
CV Jakob Niemann. Resumé: Nøglekvalifikationer. Personlighed. Født: 24/

Udbud af RIPA-Syd. Underbilag 14.A - Definitioner og testtype katalog

Teststrategi for DataHub Engrosmodellen End-to-End (E2E) test

Underbilag 14 C: Afprøvningsforskrifter til prøver og tests

FRA USECASE TIL TESTCASE HP TEST BRUGERKONFERENCE, 10. APRIL 2014

Agil-model versus V-model set i lyset af en testers dilemmaer

Mobiltest typiske udfordringer og deres løsninger

Udbud af Telemedicinsk løsning til hjemmemonitorering. Bilag 14 - Prøver

Teststrategi Engrosmodellen

Bias Reducing Operating System - BROS -

Overvågning TestHusets servere og hjemmeside

Software test i Socialstyrelsen. af: Jan Kristensen. Nov 2013

Struktureret Test og Værktøjer Appendiks til bogen Struktureret Test

The LEGO Journey: Building an agile test foundation one brick at the time. Casper Gaardland Englund. Stephan Hjelmdal Nielsen The LEGO Group l

Procedure for systemtest

Teksten i denne instruktion er ikke en del af Kontrakten og vil blive fjernet ved kontraktindgåelse.

BILAG 5.D DOKUMENTATION

SOLRØD KOMMUNE ESDH. Afprøvning. Bilag 6

10 informationer som gør din fejlrapport selvforklarende for både forretningen og programmørerne

Ledelse af test. et whitepaper om at holde styring på testforløb. Henrik Timm

Plan for præsentationen

Dynamisk hverdag Dynamiske processer

Bilag 14 Prøver INSTRUKTION TIL TILBUDSGIVER:

Bilag 14: Prøver. Udbud om levering, installation, implementering, support, drift og vedligehold af Borgeradministrativt System (BAS)

OPTION TIL RM OG RN BILAG 12 TIL KONTRAKT OM EPJ/PAS PRØVER

E2E Teststrategi Engrosmodellen

Anvendelse af BPT til manuel test

Accelerate Agil implementering fra EG NeoProcess

Idékatalog Planlægning og brug af test i statslige it-projekter

Bilag 6 Afprøvninger Version

Bilag 10. Afprøvning

Softwaretest. - også af "ikke testbar" software. DAPUG erfamøde 7. marts 2012 Thomas Vedel, Thomas Vedel Consult thomas@veco.

BANNERSPECIFIKATIONER - MOBIL FOR BERLINGSKE MEDIA 2015

ID Risikoårsag Risikohændelse Effekt Mitigerende handling Ansvarlig. Store dele af den tværgående test går i stå eller forsinkes.

Agil test tilgang - erfaringer fra projekter

Vores særlige kompetencer billedligt talt

Guide til opdatering af Navision Stat med ny funktionalitet - nye objekter, datakonvertering, automatisk indlæsning af datafiler.

Procedure vedrørende leverandørog institutionssamarbejde om nye studieadministrative løsninger

VEJLEDNING I ARBEJDSPROCESSEN VED INSTALLATION AF BACNET IP ENHEDER

Koncept for systemforvaltning af den fælles open source kode, herunder procedure for opfølgning på software-versioner af OpenTele

[Navn på Tilbudsgiver] Udbudsmateriale. Dato: Bilag 14. Version: 1.0. Bilag 14. Prøver. Bilag 14 Prøver Side 1 / 36

Pensumbeskrivelse for ISEB Softwaretest foundation Certificering (Grundlæggende certificering for softwaretestere) Version 1.0

Bilag 14. Hovedtestplan. Udbud af Medical Device Information Collection

Succesfuld implementering af automatiseret test

Problem Projekterne statusrapporterer forud for hvert møde i styregruppen. Styregruppen skal forholde sig til programmets og projekternes status.

Kvartalsrapport vedr. fase 1 af SKATs systemmodernisering for 1. kvartal 2008

Bilag C.1 Kundens opgavebeskrivelse

Dagsorden til møde i styregruppen for Program for digital almen praksis

Vurdering af kvalitet en note af Tove Zöga Larsen

Introduktion til SAS macro language

Ud af krisen. Software på tværs, 15. juni 2009

[A20] Kick off document and process description. 1 of 5

Testplan - Snitflade-, Integrations- og anvendertest Bilag C: Organisering og ansvarsfordeling

TESTAUTOMATISERING. Præsentation af: BPT anvendt til automatiseret test. HP test brugerkonference november 2008

Sådan får du anvendt dit kursus i praksis. - Guide til at maksimere dit udbytte så du får størst værdi ud af dit kursus

Pakkeoversigt: Ejerskifte Annonce Brochure Roll-up Banner PowerPoint Film Still film

Prækvalifikation vedrørende leverance af ny informationsarkitektur, ny søgefunktion samt nyt design og layout til Ballerup.dk

Statistisk databaseret automatisk test. Jesper Mortensen / Erik Dargsdorff

Kontrakt om Drift, Videreudvikling, Support af tilskuds- og kontroladministrative. Bilag 9 Dokumentation

Mere robot. Mere effekt. Stabschef Camilla Staal Axelsen. Digitaliseringsmessen den 28. September BEDRE VELFÆRD

Ved aftaleindgåelse drøftes de konkrete behov for specificering af app en med afsæt i nedenstående.

Fælles test i GD1-GD2-GD7 - Behovsundersøgelse

Generel projektbeskrivelse

Struktureret system udvikling Minimodul 1: Introduktion, UML og use cases

VEJLEDNING. Tilbudsgiver bedes kvalificere bilaget ved at tilføje: Testplaner

Kontrakt om Videreudvikling, Vedligeholdelse og Support af IMK2- systemet

Miljøplan: Indhold: 1. Miljøstyring. 1.1 Generelt. 1.1 Overordnet styring af miljøarbejdet (hvem gør hvad, hvornår) 1.2 Plan for miljøstyring

Test af Chromalex-løsning til borgere med demens på plejecentre i Aalborg Kommune

Testprocesser og målinger i test. Jesper Schultz, Nykredit 19. november 2009

Dansk testbegrebsliste version 1.0

dfgfdhsjfgdghjghfkfhgkfhjsrt Hvad skal en kontrakt indeholde om kvalitetssikring og test? Niels Chr. Ellegaard Plesner Advokatpartnerselskab

Dynamic Line Management Branchemøde d. 3 september september 2014 Torben Weihe Dam

Service Desken. Med brug af SCRUM og KANBAN

IKT TEKNISK KOMMUNIKATIONS- SPECIFIKATION

Bilag 1 Tidsplan Version

Fælles retningslinjer for REST webservices

Nets Rettighedsstyring

Automatisering af dataarbejde 2.2

DataHub Engrosmodel E2E-test på regional møder juni 2015 Mogens Juul og Helene Schmidt

Bilag 1: Tidsplan. Udbud af E-rekrutteringssystem

Vejledning til interessenthåndtering

Procedure vedrørende leverandørog institutionssamarbejde om nye studieadministrative løsninger

VEJLEDNING I ARBEJDSPROCESSEN VED INSTALLATION AF ADGANGSKONTROL ENHEDER

Vejledning: Side 2 af 36 Bilag 11

Kontrakt om Testressourcer. Bilag 1a - Situationsbeskrivelse. 23. oktober Version 1.0

UNDERBILAG 3A.1 TIL KONTRAKT OM EOJ-SYSTEM. Use case Opfølgning

Accepttest Specifikation For. Gruppen

Spil indhold - i forhold til bæredygtige byudvikling

Visual Studio Team System. Team Build en grundpille i søgen efter it-projektproduktivitet?

Prøverne gennemføres som henholdsvis en Idriftsættelsesprøve, en Driftovertagelsesprøve og en. Prøve Delprøve Delprøve

Secure O matic. Gruppe 5 2. SEMESTERPROJEKT. Udgave. Accepttest-specifikation

Seminar om kvalitetssikring og CE-mærkning

STRATEGI FOR DANMARKS DOMSTOLE

NETTILSLUTNINGSPROCES

Adresseprogrammet - Fælles teststrategi

Software Dokumentation

Bilag 1: Tidsplan. Udbud af løn- og personalesystem

Lean gammel vin på nye flasker SCKK Excellence om Lean og arbejdsgange

Transkript:

10 spørgsmål der vil hjælpe dig med dine testcases

Hvad er en testcase En testcase designes ud fra et eller flere test formål, som f.eks. at teste en speciel funktionalitet eller kvalitetsegenskab for et system eller en komponent. Testcase specifikationen beskriver hvad der skal testes, hvilke forudsætninger der skal være opfyldt, hvilke input der skal foretages under testen og de forventede resultater af disse input.

1. Hvem skal skrive testcases? Alle kan skrive en testcase. Men for at give din testcase det rigtige indhold og detaljering, kræver det en indsigt i formålet med testcasen. Den gode analyse og det rigtige testdesign kan udføres af en professionel tester, som herefter kan skrive en tilsvarende testcase. 2. Hvilke testcases skal skrives først? De første testcases bør afspejle risikoen og de enkelte afhængigheder, således at de vigtigste og mest kritiske testcases også er de testcase, som først er klar til at blive eksekveret. Prioriteringen bør fremgå af testplanen og den tilhørende tidsplan, således at testcases for de højt prioriterede områder skrives først. 3. Hvilken testcase syntaks skal benyttes? Eventuelle inputværdier og forventet resultat skal fremgå tydeligt. Test projektet bør anvende fælles sprogbrug igennem de forskellige testcases. Deltaljeringen af testcasen skal tilpasses dens brug. Skal testcasen udføres af andre, skal testcasen kun udføres én gang og er der specielle krav til dokumentation er alle spørgsmål, som skal afklares. Afhængig af testmodenheden, kan testcases deles op i testcases og testprocedurer. Testprocedurer kan genbruges på tværs er testcases, men i langt de fleste projekter vil en testcase terminologi være tilstrækkelig.

4. Hvor skal testcases opbevares? Testcases bør opbevares et sted hvor de er let tilgængelig for alle interessenter, der vil have glæde af testcases.kan med fordel opbevares i et testværktøj som understøtter testcase design og eksekvering, samt muligheden for at versionsstyre testcases og levere metrikker om teststatus og fremdrift. 5. Hvem/hvad skal eksekvere testcases? Testcases eksekveres normalt af testere, men kan ligeledes udføres af forrentning, udviklere eller andre med relation til et testprojekt. Den enkelte tester har forskelligt perspektiv. Der kan være forskel på om testen eksekveres i forbindelse med en accepttest eller under et sprint i et agilt setup. Nogle testcases kan være kandidater til test automatisering og regression tests, men disse testcases må først transformeres til det valgte værktøj, således testcasen er nem at vedligeholde og eksekvere i et automatisk testværktøj. 6. Hvem skal vedligeholde testcases? Ved ændringer til systemet under test, kan der være behov for vedligeholdelse af testcases. Dette er især vigtigt for testcases som anvendes til regressionstest. Testcases vedligeholdes af test designer eller ansvarlig tester. Det vigtige er, at vedligeholdelse af testcases er et naturlig del af et projekt, på lige fod med vedligeholdelse af kode.

7. Hvad er forudsætningerne for den enkelte testcase? Forudsætningerne for en testcase beskriver de betingelser, som skal være opfyldt før en testcase kan eksekveres, f.eks. at der i testmiljøet findes data af en bestemt værdi eller objekter i en særlig tilstand. Nogle testcases kan derfor forudsætte at en anden testcase er eksekveret umiddelbart inden. Såfremt der er krav til forudsætningerne, er det væsentligt at disse er dokumenteret, således at den enkelte tester er opmærksom på disse ved gennemførsel. 8. Hvordan skal jeg navngive min testcase? Testcasens navn skal angives kort, præcist og letforståeligt. Overvej hvilke krav der til traceability. Er det vigtigt, at der henvisning til testbasis. Der kan med fordel angives hvilke(t) krav, der er dækket af testcasen. 9. Hvilke handlinger skal der foretages? Testcasens sæt af input beskriver de handlinger der skal foretages for at eksekvere testcasen. De enkelte steps skal have tilstrækkelig information, således testcasen kan eksekveres af testeren. Handlingerne skal sikre, at det forventede resultat vil forblive det samme ved gentagne afviklinger af testcasen. 10. Hvad er det forventede resultat på testcasen? En testcase skal have et forventet resultat. I en testcase kan der forekomme forventet resultater undervejs i afviklingen af en testcase. Altså ud for hvert teststep kan der være et forventet resultat. Forventet resultat er et svar på formålet med testcasen. Det skal give et sikkert svar på, at en funktion eller et krav er opfyldt eller opfører sig som forventet.

Spørgsmål og kontakt Du skal altid være velkommen til at kontakte os, hvis du har nogle spørgsmål. TestHuset A/S Lautruphøj 1-3 2750 Ballerup +45 44 979 979 info@testhuset.dk