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

Størrelse: px
Starte visningen fra side:

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

Transkript

1 Dansk oversættelse af engelsk Foundation Syllabus V februar 1999 Pensum emne Beskrivelse Tid Testprincipper Test-terminologi Terminologilisten Dansk Testbegrebsliste anvendes. 5 Der findes ikke et generelt accepteret sæt testdefinitioner, som anvendes globalt af Software testere. BS udgør en kilde til testdefinitioner og er inkluderet i den danske testbegrebsliste, der er suppleret med almindeligt anvendte danske testfaglige begreber. Derfor er test en nødvendighed Definition af fejltagelse, fejl, afvigelse og pålidelighed; fejltagelser og hvordan de opstår; omkostninger ved fejltagelser; udtømmende test er umulig; test og risiko; test og kvalitet; test og kontraktmæssige krav; test og lovmæssige, regelbundne eller ufravigelige krav; hvor meget test er tilstrækkeligt 75 En fejltagelse er en menneskelig handling, der frembringer et ukorrekt resultat. En fejl er en manifestation af en fejltagelse i softwaren (også kaldet en bug). En opstået fejl i softwaren kan medføre en afvigelse, som er en fravigelse fra softwarens forventede leverance eller service. Pålidelighed er sandsynligheden for at softwaren ikke vil forårsage afvigelser i et system i løbet af en specificeret tidsperiode under specificerede omstændigheder. Fejltagelser opstår, fordi vi ikke er perfekte og selv om vi var det arbejder vi under krav og er underlagt begrænsninger, som for eksempel deadlines for levering. En enkelt afvigelse kan koste ingenting eller rigtig meget (f.eks. Venus-sonden). Software i sikkerhedskritiske systemer kan være årsag til dødsfald eller kvæstelser, hvis den svigter, så omkostningen ved afvigelser i et system af denne type kan være tab af menneskeliv. Udtømmende test ville i de fleste tilfælde kræve enorme ressourcer og er derfor generelt uigennemførlig. Omfanget af den gennemførte test afhænger af de risici der skal afværges. Der skal ligge en risikovurdering til grund for allokering af den tid, der afsættes til test og for valget af hvad, der skal testes og hvor vægten for test skal lægges. Test identificerer fejl, og rettelsen af disse hæver softwarens kvalitet ved at hæve softwarens potentielle pålidelighed. Test er en målestok for softwarens kvalitet. Vi måler i hvor høj grad vi har opnået kvalitet ved at teste relevante systemegenskaber som korrekthed, pålidelighed, brugervenlighed, vedligeholdelsesegnethed, genanvendelighed, testbarhed osv. Andre faktorer, der kan være medbestemmende for testen, kan være kontraktmæssige eller lovmæssige krav, normalt defineret i branchespecifikke standarder eller baseret på anerkendt best practice og bredt accepterede kvalitetsstandard. Det er vanskeligt at fastlægge, hvor meget test der er tilstrækkelig. Copyright DANSK IT, 2004.

2 Grundlæggende Testprocessen; vellykkede test afslører fejl; betydningen af testproces 45 testafslutningskriterier eller slutkriterier, dækningskriterier Den grundlæggende testproces omfatter testplanlægning, testspecifikation, testafvikling, testregistrering og testafslutning. Mere detaljeret beskrevet: Testplanlægning: Testplanen bør specificere, hvordan teststrategi og projektets testplan anvendes i forhold til softwaren under test. Planen bør omfatte en identifikation af samtlige undtagelser fra teststrategien og identifikation af al software som softwaren under test skal spille sammen med under testafviklingen, som f.eks. drivere og stubbe. Testspecifikation: Testcases bør designes ved hjælp af de testcase designteknikker, der blev valgt under testplanlægningen. Testafvikling: Hver testcase bør afvikles. Testregistrering: Testregistreringen for hver testcase bør indeholde klare identifikationer og versionsoplysninger om den testede software samt testspecifikationen. Det faktiske resultat skal registreres. Under henvisning til testregistreringen bør det være muligt at godtgøre, at samtlige specificerede testaktiviteter er blevet udført. Det faktiske resultat bør sammenholdes med det forventede resultat. Konstaterede uoverensstemmelser skal registreres som testhændelser og analyseres for at fastlægge årsagen og for at afgøre den tidligste testaktivitet, der skal gentages, f.eks. for at fjerne fejlen i testspecifikationen eller for at kunne afgøre om fejl i softwaren er blevet afhjulpet. Den testdækningsgrad, der er opnået, skal angives for de mål, der er listet som kriterier for testafvikling. Testafslutning: Testregistreringen skal sammenholdes med de allerede specificerede testafslutningskriterier. Hvis kriterierne ikke er blevet overholdt, skal den tidligste testaktivitet, som skal gentages for at opfylde afslutningskriterierne, identificeres, og testen skal genstartes fra dette punkt. Det kan være nødvendigt at gentage testspecifikationsarbejdet for at designe yderligere testcases for at overholde et givet mål for testdækning. Eftersom formålet med testen er at finde fejl, er en test vellykket, når den finder en fejl. Det er kontra-intuitivt, fordi fejl forsinker fremskridt: En vellykket test kan medføre forsinkelser. En vellykket test afslører en fejl, som hvis den var blevet opdaget senere ville have været mange gange dyrere at afhjælpe. Derfor er testen i det lange løb en fordel. Testafslutningskriterier anvendes for at afgøre, hvornår testen (uanset testfase) er fuldført. Kriterierne kan defineres baseret på omkostning, tid, fundne fejl eller testdækningsgrad. Testdækningsgrad Kriterier for testdækningsgrad defineres på basis af elementer, der er aktiveret gennem testsæt, herunder f.eks. forgreninger, brugerkrav, oftest gennemførte transaktioner osv Copyright DANSK IT, 2004.

3 Test for at finde fejl; forholdet mellem tester og udvikler; Psykologien i test uafhængighed Testaktiviteter udføres med det primære formål at finde fejl i softwaren snarere end for at bevise korrekthed. Test kan derfor opfattes som en destruktiv proces. Kravene til testerens tankegang er anderledes end til udviklerens. Der findes rigtige og forkerte måder at fremlægge fejl på over for ophavsmændene eller ledelsen (eksempler anføres). Det er vigtigt at udvikler og tester kommunikerer: F.eks. om ændringer i applikationen eller menustrukturer, der kan påvirke testarbejdet; eller hvor udvikleren mener, koden kan være fejlbehæftet; eller hvor det kan være vanskeligt at reproducere rapporterede fejl. Generelt anses objektiv, uafhængig test for at være mere effektiv. Hvis ophavsmanden tester, bringes bagvedliggende antagelser med ind i testarbejdet, for man ser jo ofte det, man gerne vil se. Der kan være følelser involveret og der kan være en personlig interesse i ikke at finde fejl. Niveauer for uafhængighed i testen kan således være: a) Testcases designes af de(n) person(er), som skriver den software, der skal testes; b) Testcases designes af en eller flere andre person(er); c) Testcases designes af en eller flere person(er) fra en anden afdeling; d) Testcases designes af en eller flere person(er) fra en anden organisation; e) Testcases vælges ikke af en person. Gentest og regressionstest Fejlrettelse og gentest; testens egnethed til gentagelse; regressionstest og automatisering; valg af testcases til regressionstest Når en fejl er opdaget og afhjulpet, bør softwaren testes igen, for at sikre at den oprindelige fejl virkelig er blevet rettet. Desuden bør det overvejes, om der skal testes for lignende eller beslægtede fejl. Test bør være egnet til gentagelse for at give mulighed for gentest / regressionstest. En regressionstest tester om ændringer har forårsaget uforudsete negative følger i den uændrede software (regressionsfejl) og sikrer, at det modificerede system stadig overholder kravene. Regressionstesten udføres altid, når softwaren eller dens miljø er blevet ændret. Testsæt til regressionstest køres mange gange og udvikler sig normalt langsomt. Derfor er regressionstest velegnet til automatisering. Er automatisering ikke mulig, eller er testsæt til regressionstest meget omfattende, kan det blive nødvendigt at trimme testsæt. Man kan udelade repetitiv test, nedbringe omfanget af test på allerede afhjulpne fejl, testcases kan kombineres, nogen test kan lægges ud til periodisk afvikling osv. En delmængde testsæt til regressionstest kan også anvendes til at teste akutte fejlrettelser. Forventede Identifikation af krævet adfærd resultater Forventet adfærd er ensbetydende med forventede resultater, men er ikke det samme som output. Er den forventede adfærd ikke blevet defineret, kan det ske, at et plausibelt, men fejlagtigt resultat tolkes som korrekt. Derfor skal den forventede adfærd defineres før testafviklingen. Orakel-postulatet går ud på at en tester rutinemæssigt kan identificere det korrekte resultat af en test. Oraklet kan f.eks. være det eksisterende system (for en benchmarkafprøvning), eller en specifikation eller en bestemt persons specialviden, men ikke selve koden Copyright DANSK IT, 2004.

4 Testomfang og begrænsede ressourcer; de vigtigste tests Prioritering af test først; prioriteringskriterier Der er aldrig tid nok til at udføre al ønsket test. Derfor skal der prioriteres. Test prioriteres på en sådan måde, at uanset hvornår testforløbet afbrydes, så er der blevet testet så godt som overhovedet muligt i den tid, der var til rådighed. Identificer de kriterier der danner grundlag for prioriteringen, f.eks.: alvor sandsynlighed synlighed for afvigelser prioritering af de krav, der skal testes kundens ønsker tilbøjelighed for ændring tilbøjelighed for fejl hvor kritisk området er for forretningen hvor kritisk området er i teknisk henseende kompleksitet Test igennem hele livscyklus Testmodeller Verificering, Validering og Test; V-model Definitioner af verificering, validering og test iflg. Dansk Testbegrebsliste. V-modellen for test viser, at den identificerer de baselines (både test- og udviklingsprodukter), der bør testes på hvert udviklingstrin (det vil sige, test igennem hele livscyklus). Testøkonomi Testdesign på et tidligt tidspunkt; hvordan forberedelse af test kan finde fejl i specifikationerne; omkostninger ved fejl versus omkostninger ved test. Omkostningerne ved fejl eskalerer efterhånden som produktet bevæger sig mod idriftsættelse. Opdages en fejl umiddelbart før produktet er klart til idriftsættelse, stiger prisen på arbejdet med at rette fejlen drastisk, fordi mere end et forudgående trin af design, kodning og test eventuelt skal gentages. Hvis fejlen viser sig når produktet er i drift, kan de potentielle omkostninger blive katastrofale. Hvis fejl i dokumentationen overses, kan udvikling baseret på denne dokumentation medføre mange afledte fejl, der mangedobler effekten af den oprindelige fejl. Testdesign på et tidligt tidspunkt kan forhindre denne mangedoblingseffekt. Analyse af specifikationerne under testforberedelsen bringer ofte fejl i specifikationerne frem i lyset. Omkostningerne ved test er som regel lavere end omkostninger forårsaget af alvorlige fejl (som f.eks. ringe produktkvalitet og/eller fejlrettelse), selv om kun få organisationer kan fremlægge tal der bekræfter dette Copyright DANSK IT, 2004.

5 Overordnet testplanlægning Fastlæggelse af testomfanget; risikoanalyse; testfaser; testopstarts- og testafslutningkriterier; krav til testmiljøet; testdatakilder; dokumentationskrav Nødvendige overvejelser i henhold til IEEE Test Plan Outline. 1. Testplan identifikator; 2. Introduktion; 3. Testgenstande; 4. Områder, der skal testes; 5. Områder, der ikke skal testes; 6. Fremgangsmåde; 7. Kriterier for hvorvidt afviklingen af et testområde kan godkendes eller har fejlet; 8. Kriterier for at afbryde og genoptage testen. 9. Test leverancer; 10. Testopgaver; 11. Krav til Testmiljø; 12. Ansvar; 13. Behov for bemanding og uddannelse; 14. Tidsplan;. Risici og beredskabsplan; 16. Godkendelser. Accepttest Brugeraccepttest, kontraktaccepttest, alfa- og betatest; Accepttest og brugertest. Disse testfaser kan være den eneste test, der udføres af, og er synlig for, kunden, når det drejer sig om en softwarepakke. Brugeraccepttest - Den sidste fase i valideringen. Kunden bør selv udføre testen eller være tæt involveret i den. Kunderne kan vælge at afvikle en hvilken som helst test de ønsker, normalt ud fra deres sædvanlige forretningsprocesser. Oftest sker det ved at indrette en kontormodel, hvor systemerne testes i et miljø, der ligger så tæt på realiteterne som muligt. I Danmark benyttes i praksis en V-model, hvor der skelnes mellem brugertest og accepttest, og brugeraccepttest betegner da den konkrete kombination af disse to testfaser: Accepttest: Den sidste fase i valideringen. Accepttesten er en demonstration af, at acceptkriterierne, som forinden bør være defineret i en kontrakt eller et aftalegrundlag, er indfriet. Typisk ser testen på tværs af system og forretningsgange på kundens/brugerens samlede oplevelse af en løsning. En godkendt accepttest er normalt en endelig godkendelse af en samlet leverance. Brugertest: En detaljeret test af, at et system lever op til brugernes forventninger og krav, som beskrevet i kravspecifikationen, samt test af at systemet fungerer i sammenhæng med brugernes forretningsgange, blanketter og anden brugerdokumentation. Kontraktaccepttest En demonstration af at acceptkriterierne, som vil være defineret i kontrakten, er opfyldt. Alfa- og betatest - Når softwaren virker stabil anvender brugere, der repræsenterer markedet, produktet på samme måde, som de ville gøre i den endelige version og videregiver deres kommentarer. Alfatest udføres på udviklerens lokation, betatest udføres på testerens lokation. Systemintegrationstest Test af integrationen af systemer og softwarepakker; test af grænsefladerne til eksterne organisationer (f.eks. PBS, EDI, Internet) Integration med andre (komplette) systemer. Identifikation af grænsefladerne til andre systemer og vurdering af risici i forbindelse med interaktion med disse. Inkrementel/ikke-inkrementel indfaldsvinkel til integration Copyright DANSK IT, 2004.

6 Ikke-funktionel systemtest Ikke-funktionelle krav; ikke-funktionelle testtyper: load, performance og stress; sikkerhed; brugervenlighed; lagring; volumen; installerbarhed; dokumentation; genoprettelse. Forklar at, ikke-funktionelle krav er lige så vigtige som funktionelle krav. Omtal kort hver af de anførte teknikker: Load, performance og stress, sikkerhed, brugervenlighed, lagring, volumen, installerbarhed, dokumentation og genoprettelse. Funktionel Funktionelle krav; kravbaseret test; forretningsprocesbaseret systemtest test Funktionelle krav iflg. IEEE-definitionen er krav, der specificerer en funktion, som et system eller en systemkomponent skal udføre. Kravbaseret test hvor brugerkravspecifikationer og systemkravspecifikationer (typisk anvendt i kontrakter) kan anvendes til at udlede testcases. Forretningsprocesbaseret test baseret på forventede brugerprofiler (f.eks. scenarier, use cases osv.) Komponentintegrationstest At samle komponenter til subsystemer; subsystemer til systemer; stubbe og drivere; big-bang, top-down, bottom-up, andre strategier Integrationstest afprøver grænseflader og interaktionen mellem komponenter/subsystemer. Stubbe og driveres rolle. Inkrementelle strategier inklusiv: Top-down, bottom-up og funktionel inkrementering. Ikke-inkrementel fremgangsmåde (big-bang). Komponenttest (Også kendt som enheds-, modul-, programtest); oversigt over BS Software component testing; komponenttest proces Komponenttesten afprøver individuelle softwarekomponenter. For uddybning se BS Vedligeholdelsestest Vedligeholdelsesproblemer; test af ændringer; risici ved ændringer og regressionstest Test af gammel kode med ringe/manglende specifikationer. Testomfanget med hensyn til ændret kode. En effektanalyse mht. følgefejl er vanskelig derfor større risiko ved gennemførelse af ændringer og vanskeligt at beslutte hvor meget regressionstest der skal udføres Copyright DANSK IT, 2004.

7 Dynamiske testteknikker Black- og Whitebox test Funktionel- eller black-box test; struktur-, white- eller glasbox test; trenden går fra white-box til black-box under livscyklus; teknikker og værktøjer Forklar terminologien: Black-box/funktionel og white-box/struktur/glas-box. Beskriv forskellen mellem black- og white-box teknikker. Forklar at, black-box er relevant hele livscyklus igennem, mens yderligere white-box generelt set er relevante for test af subsystemer (komponent, link), men bliver i stadig mindre grad anvendelige i forhold til system- og accepttest. System- og accepttestere fokuserer snarere på specifikationer og krav end på koden. Fremhæv brugen af systematiske testteknikker (og tilhørende målinger) for at skabe tillid. Forklar at, værktøjer øger produktivitet og kvalitet og især er nyttige til white-box test. Black-box testcase Black-box teknikker som specificeret i BCS standarden. 45 design teknikker List alle black-box teknikker i BS Beskriv og giv eksempel på brug af ækvivalensklasse og grænseværdianalyse samt en teknik mere. White-box testcase White-box teknikker som specificeret i BCS standarden. design teknikker Opstil alle white-box teknikker i BS på en liste. Beskriv og giv eksempel på instruktions- og forgrenings-/beslutningpunkttest iflg. BS Fejlgætning Brug af erfaring til at postulere fejl; brug af fejlgætning for at supplere andre testcase design teknikker Fejlgætning kan opdage visse fejl, som systematiske teknikker ikke opdager. Testcases udledes på baggrund af erfaring med, hvor fejltagelser tidligere er opstået, eller testeren kan have forståelse for, hvor fejltagelser sandsynligvis vil kunne opstå i fremtiden. Fejlgætning bør bruges som oprensningsmetode eller som supplement til systematiske teknikker, ikke som første teknikvalg Copyright DANSK IT, 2004.

8 Statisk test Reviews og Hvorfor, hvornår og hvad skal reviewes? Omkostninger og testprocessen fordele ved reviews Hvorfor reviews er kendt for at være omkostningseffektiv. Ethvert dokument kan reviewes. F.eks. kravspecifikationer, designspecifikationer, kode, testplaner, brugervejledninger osv. Reviews bør starte så tidligt som muligt. Omkostningerne løbende reviews koster ca. % af udviklingsbudgettet. Omkostninger ved reviews omfatter aktiviteter som selve reviewprocessen, analyse af metrikker og procesforbedring. Fordelene omfatter områder som forbedringer af udviklingsproduktivitet, reducerede udviklingstider, testomkostninger og tidsreduktion, reduktion af levetidsomkostninger, lavere fejlniveau osv. Typer af reviews Review typer; mål, udførte aktiviteter, roller og ansvar, produktleverancer, faldgruber Forklar ligheder/forskelle mellem walkthroughs, inspektioner, uformelle reviews og tekniske reviews, som hver især kan identificeres ud fra følgende egenskaber: Walkthroughs brugsmønstre, prøvekørsler, gruppe af kolleger under forfatterens ledelse. Inspektioner ledet af uddannet moderator (ikke forfatter), defineret roller, inkluderer metrikker, formel proces baseret på regler og checklister med start- og slutkriterier. Uformelle reviews udokumenteret, men nyttig, billig, meget udbredt. Tekniske reviews (betegnes også som kollega-reviews) dokumenteret, defineret fejlfindingsproces, omfatter kolleger og tekniske eksperter, ingen deltagelse fra ledelsen. Mål validering og verificering i forhold til specifikationer og standarder (og procesforbedringer). Opnå enighed. Aktiviteter planlægning, oversigtsmøde, forberedelse, reviewmøde og opfølgning (eller lignende). Roller og ansvarsfordeling moderatorer, forfattere, reviewansvarlige/inspektører og ledere (planlægningsaktiviteter) Leverancer produktændringer, ændringer i kildedokumenter og forbedringer (både review og udvikling). Faldgruber manglende uddannelse, manglende dokumentation, mangel på opbakning fra ledelsen (og mangel på succes med forbedring af processer) Copyright DANSK IT, 2004.

9 Statisk analyse Simpel statisk analyse; compiler-genererede informationer; dataflow-analyse; kontrolflow-grafer, kompleksitetsanalyse; Forklar at, statisk analyse ikke indebærer nogen dynamisk eksekvering og kan afsløre mulige fejl som f.eks. utilgængelig kode, ikke-definerede variable, mis-match i parameter typer, funktioner og procedurer der ikke bliver kaldt, mulige array overskridelser. Forklar at, enhver fejl, der er fundet af compilere, er fundet igennem statisk analyse. Compilere finder fejl i syntaksen. Mange compilere giver også information om variabel anvendelse, som er nyttig under vedligeholdelse. Forklar at, dataflow-analysen ser på anvendelse af data på stier igennem koden, idet der kigges efter mulige uregelmæssigheder, som f.eks. definitioner uden mellemliggende anvendelse og anvendelse af en variabel, efter at den er blevet slettet. Forklar anvendelsen med eksempler på produktionen af kontrolflow-grafer for et program. Introducer kompleksitetsmetrikker, inklusive cyklomatisk kompleksitet. Styring af test (Test management) Organisation Organisatoriske strukturer for test; sammensætning af team Forklar at, der kan være forskellige struktureringer for test i forskellige organisationer: Testafvikling kan være udviklerens ansvar eller kan være teamets ansvar (par-test). Det kan også være en person i teamet, som er tester, der kan være et dedikeret testteam (som ikke har med udvikling at gøre) eller der findes interne testkonsulenter, der rådgiver i forbindelse med projekter. Endelig kan der også findes en separat organisation, som udfører testarbejdet. Normalt er der brug for et multidisciplinært team med specialkundskaber. Der er brug for følgende rollefordeling: Testanalytiker til at forberede strategier og planer, eksperter i testautomatisering, database administrator eller designer, brugergrænseflade-eksperter, testmiljøstyring osv. Typiske symptomer på dårlig konfigurationsstyring; Konfigurationsstyring konfigurationsidentificering: konfigurationskontrol; statusrapportering; konfigurationsrevision Typiske symptomer på dårlig konfigurationsstyring beskrives, som f.eks. når det ikke er muligt at matche kilde- og objektkode, identificere hvilken version i en compiler der genererede objektkoden, identificere ændringerne i kildekoden, der er udført i en bestemt softwareversion, samt når samtidige ændringer er udført af forskellige udviklere i samme kildekode (og ændringer derved er gået tabt). Konfigurationsidentificering kræver at alle konfigurationsobjekter og deres versioner i testsystemet er kendte. Konfigurationskontrol betyder vedligeholdelse af delene i en konfiguration i et bibliotek og vedligeholdelse af en log over hvordan delene i konfigurationen er blevet ændret i løbet af tiden. Statusrapportering er den funktion, der opsamler og gør det muligt at følge op på problem-/fejlrapporter, ændringsønsker osv. Konfigurationsrevision er den funktion, der kontrollerer indholdet i biblioteker osv. med hensyn til f.eks. deres overensstemmelse med standarder Copyright DANSK IT, 2004.

10 Konfigurationsstyring kan være meget kompliceret i miljøer med blandede hardware- og softwareplatforme, men der findes stadig flere sofistikerede platformuafhængige værktøjer til konfigurationsstyring. Testestimering, Testestimering; Testopfølgning; Teststyring -opfølgning og -styring Testestimering forklar at, den indsats, der kræves for at udføre aktiviteterne i en overordnet testplan, skal være udarbejdet i forvejen og at der skal tages højde for at noget testarbejde skal gentages. Testopfølgning beskriv nyttige mål til registrering af fremdrift (f.eks. antal testgennemløb, test godkendt/fejlet, opståede og afhjulpne fejl, gentest osv.). Forklar, at den testansvarlige kan være tvunget til at indrapportere afvigelser fra projekt-/testplanerne som f.eks. mangel på tid, før testafslutningskriterierne er opfyldt. Teststyring forklar at, omfordeling af testressourcer kan være nødvendig, f.eks. ændringer i testtidsplanen, testmiljøet, antallet af testere osv. Hvad er en testhændelse ; testhændelser og testprocessen; Testhændelser rapportering af testhændelser; sporing og analyse En testhændelse er enhver signifikant, ikke planlagt begivenhed, der sker under testforløbet og som kræver efterfølgende undersøgelse og/eller rettelse. Hændelser skal registreres, når forventede og faktiske testresultater er forskellige fra hinanden. Testhændelser kan forekomme både i relation til dokumentation, i kode eller i et system under test. Testhændelser kan analyseres for at overvåge testprocessen og for at understøtte forbedringer af testprocessen. Testhændelser bør rapporteres, når en anden en ophavsmanden til et produkt under test udfører testen. Typisk vil informationen, der rapporteres om en hændelse, omfatte: forventede og faktiske resultater testmiljøet den testede softwares ID testerens/testernes navn(e) alvor omfang prioritet enhver anden information, der måtte være relevant for at genskabe og afhjælpe den potentielle fejl. Testhændelser bør kunne spores fra deres opståen igennem de forskellige trin helt ud til de er rettet og lukket. Teststandarder Standarder for kvalitetssikring; industrispecifikke standarder; teststandarder 5 Forklar at, standarder for kvalitetssikring blot specificerer at test skal afvikles, mens industrispecifikke normer specificerer niveauet for test, og test standarder specificerer måden, hvorpå test skal afvikles. Ideelt set bør teststandarder baseres på de to sidste (niveauet og måden). Eksempler på de forskellige standarder er ISO 9000, Railway Signalling standard, BS , BS Værktøjer til støtte for test (CAST) Typer af testværktøjer Kravtest; statisk analyse; testdesign; testdataforberedelse; karakterbaseret testafvikling; GUI testafvikling; test harness, drivere og simulatorer; performancetest; dynamisk analyse; debugging; sammenligning; teststyring; testdækningsmåling Copyright DANSK IT, 2004.

11 Værktøjer til kravtest yder automatiseret støtte til verificering og validering af kravmodeller, som f.eks. konsistenskontrol og animering. Værktøjer til statisk analyse giver information om softwarens kvalitet ved at undersøge koden i stedet for at køre testcases igennem koden. Værktøjer til statisk analyse måler normalt softwarens forskellige karakteristika på objektiv måde, fx cyklomatiske kompleksitetsmålinger og andre kvalitetsparametre. Værktøjer til testdesign genererer testcases ud fra en specifikation, der normalt opbevares i en database i et CASE værktøj eller genereres fra formelt specificerede krav, gemt i selve værktøjet. Nogle værktøjer genererer testcases på baggrund af en kodeanalyse. Værktøjer til testdataforberedelse gør det muligt for testdata at blive valgt fra bestående databaser eller blive oprettet, genereret, manipuleret og redigeret til brug for test. De mest sofistikerede værktøjer kan behandle mange forskellige fil- og databaseformater. Værktøjer til karakterbaserede testafvikling giver optage-/afspilningsfaciliteter for applikationer til karakterbaserede terminaler. Værktøjerne simulerer brugerindtastninger på terminalerne og optagelse af skærmbilleder til senere sammenligning. Testforløbene optages normalt i et programmerbart scriptsprog, testdata, testcases og forventede resultater kan fastholdes i separate test-databaser. Værktøjerne bruges ofte til at automatisere regressionstest. Værktøjer til GUI-testforløb giver optage-/afspilningsfaciliteter for applikationer til grafiske brugergrænseflader (GUI). På engelsk anvendes også betegnelsen WIMP (Windows, Icons, Mouse, Pointer)- interface applikationer. Værktøjerne simulerer musebevægelser, knap-klik og tastaturinput og kan genkende GUI-objekter som vinduer, felter, knapper og andre kontroller. Objekttilstande og bitmapbilleder kan optages til senere sammenligning. Testforløbene optages normalt i et programmerbart scriptsprog, testdata, testcases og forventede resultater kan gemmes i separate test-databaser. Værktøjerne bruges ofte til at automatisere regressionstest. Testharness og testdrivere anvendes ofte til eksekvering af software under test, hvis softwaren ikke har nogen brugergrænseflade eller for at køre grupper af bestående, automatiserede testscripts, som kan styres af testeren. Der findes nogle værktøjer på det kommercielle marked, men også specialskrevne programmer hører til i denne kategori. Simulatorer anvendes til at understøtte test, når kode eller andre systemer enten ikke er til rådighed eller upraktisk at anvende (f.eks. test af software til at tackle atomkernenedsmeltning). Værktøjer til performancetest har to hovedegenskaber: Belastningsgenererings- og testtransaktionsmåling. Belastningsgenerering (generering af load) finder sted ved enten at køre applikationen igennem brugergrænsefladen eller ved hjælp af testdrivere, der simulerer den belastning som applikationen generer på arkitekturen. Antallet af eksekverede transaktioner registreres. Køres applikationen via brugergrænsefladen, foretages og registreres der tidsmålinger for udvalgte transaktioner. Værktøjer til performancetest frembringer normalt rapporter på basis af de registrerede testtransaktioner og grafik over belastningen i forhold til svartider. Værktøjer til dynamisk analyse giver run-time informationer om status for eksekvering af software. Værktøjerne anvendes almindeligvis til overvågning af allokeringen, anvendelsen og deallokering af hukommelse, markering af hukommelseslæk, åbne pointere, pointeraritmetik og andre fejltagelser, som er vanskelige at finde på statisk vis. Værktøjer til debugging bruges hovedsageligt af programmører til at genskabe fejl og undersøge programmernes tilstand. Debuggers gør det muligt for programmøren at eksekvere programmet linje for linje, standse programmet på en vilkårlig programinstruktion og sætte og undersøge programvariable. Værktøjer til sammenligning anvendes til at opdage forskelle mellem faktiske resultater og forventede resultater. Selvstændige sammenligningsværktøjer kan normalt håndtere en række forskellige fil- og databaseformater. Værktøjer til testafvikling har normalt indbyggede sammenligningsfunktioner, der behandler karakterskærmbilleder, GUI-objekter eller bitmapbilleder. Disse værktøjer kan ofte filtrere, således at rækker eller kolonner af data eller områder på skærmbilleder kan ignoreres. Værktøjer til teststyring kan have flere egenskaber. Styring af testmaterialer omfatter oprettelse, styring og kontrol af testdokumentationen, f.eks. testplaner, -specifikationer og resultater. Nogle værktøjer understøtter testforløbets projektstyringsaspekter, f.eks. testtidsplanlægning, registrering af testresultater samt styringen af Copyright DANSK IT, 2004.

12 testhændelser, der er opstået under testen. Testhændelsesværktøjer kan også indeholde workflow-orienterede faciliteter til at følge og styre allokering, fejlretning og gentest af fejl. De fleste teststyringsværktøjer indeholder udstrakte rapporterings- og analysemuligheder. Værktøjer til testdækningsmåling (eller -analyse) indeholder muligheder for objektiv måling af den strukturelle testdækning under testafvikling. De programmer, der skal underkastes test, instrumenteres før compileringen. Instrumenteringskoden registrerer dækningsdata dynamisk i en logfil, uden at funktionaliteten af det program, der testes, bliver påvirket. Efter eksekvering analyseres logfilen og der fremlægges en dækningsstatistik. De fleste værktøjer udarbejder statistikker over de mest almindelige dækningsmål som instruktions- eller forgreningsdækning. Valg og implementering af værktøj Hvilke testaktiviteter kan automatiseres? Krav til CAST værktøjer; hvilke værktøjstyper skal bruges? Testprocessens modenhed og CAST parathed ; udvælgelsesprocessen; værktøjer, platforme og CAST integration; pilotprojekter og udrulning Mange testaktiviteter kan automatiseres og testafviklingsværktøjer er ikke nødvendigvis første og eneste valg. Undersøg testaktiviteterne med henblik på, hvor værktøjer kunne være en fordel og prioriter de områder, der anses for at være de vigtigste. Det kan være vigtigere, hvordan værktøjet passer ind i testprocessen end at vælge det værktøj, der har mest funktionalitet - når det skal besluttes, om der er brug for et værktøj og hvilket det så i givet fald skal være. Testværktøjernes nyttevirkning afhænger normalt af et systematiseret og disciplineret afviklet testproces. Forløber testen kaotisk, kan værktøjerne vise sig ikke at have nogen nytte, og tværtimod være en hindring for testen. Der skal allerede eksistere en god testproces eller der skal være en erkendelse af, at testprocessen skal forbedres samtidigt med implementeringen af testværktøjer. Den grad af lethed, hvormed testværktøjer kan implementeres, kan betegnes som CAST parathed. Testværktøjer kan indeholde interessant funktionalitet, der dog ikke nødvendigvis er til rådighed på den aktuelle platform. F.eks. kører på forskellige versioner af UNIX-systemer, men ikke dit. Nogle testværktøjer, f.eks. performancetestværktøjer kræver egen hardware. Derfor bør anskaffelsesprisen for denne hardware tages med i rentabilitetsberegningerne. Hvis der allerede er værktøjer til rådighed, skal det overvejes på hvilket niveau disse skal integreres med andre værktøjer og om det i det hele taget giver mening. Typisk vil spørgsmålet være om et testafviklingsværktøj skal integreres i det bestående teststyringsværktøj eller omvendt. Nogle udbydere tilbyder integrerede testværktøjssæt, f.eks. testafvikling, teststyring og performancetest som samlet pakke. Integrationen af nogle testværktøjer kan medføre store fordele, men der findes også tilfælde hvor integrationen alene er kosmetisk. Når der først er enighed om kravene til automatisering, er der fire trin tilbage i udvælgelsesprocessen: 1. Oprettelse af en liste af udvalgte potentielle testværktøjer 2. Afholdelse af demoer 3. Evaluering af valgt(e) værktøj(er) 4. Review og valg af værktøj. Før man forpligter sig til at implementere testværktøjet på tværs af alle projekter, gennemføres der normalt et pilotprojekt for at sikre, at fordelene ved anvendelsen af testværktøjet virkelig kan opnås. Pilotprojektets mål er at få en vis erfaring med anvendelsen af testværktøjerne, identificere nødvendige ændringer i testprocessen og anslå de faktiske omkostninger og fordele ved implementeringen. Udrulning af testværktøjet bør basere sig på en succesrig evaluering af pilotprojektet. Udrulning kræver normalt et stort engagement blandt testværktøjets brugere og de nye projekter, da der altid er startomkostninger forbundet med anvendelse af ethvert værktøj i nye projekter Copyright DANSK IT, 2004.

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

Underbilag 14 C: Afprøvningsforskrifter til prøver og tests Underbilag 14 C: Afprøvningsforskrifter til prøver tests Udbud om levering, installation, implementering, support, drift vedligehold af Borgeradministrativt System (BAS) Indhold underbilag 14 C Afprøvningsforskrifter

Læs mere

Nye testteknikker fra ISTQB - direkte fra hylderne. Ole Chr. Hansen

Nye testteknikker fra ISTQB - direkte fra hylderne. Ole Chr. Hansen Nye testteknikker fra ISTQB - direkte fra hylderne Ole Chr. Hansen TestExpo 29. Januar 2015 Præsentation Ole Chr. Hansen Managing Consultant Fellow SogetiLabs Global Innovation Team Blog - http://ochansen.blogspot.com

Læs mere

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

Struktureret Test og Værktøjer Appendiks til bogen Struktureret Test Struktureret Test og Værktøjer Appendiks til bogen Struktureret Test Struktureret Test og Værktøjer... 1 Appendiks til bogen Struktureret Test... 1 1. Definition og formål... 2 2. Kategorisering... 2 2.1

Læs mere

BILAG 5.D DOKUMENTATION

BILAG 5.D DOKUMENTATION BILAG 5.D DOKUMENTATION INDHOLDSFORTEGNELSE 1. Indledning...4 2. Kundens krav til Leverancedokumentation...4 Side 2 of 10 Instruktion til besvarelse af bilaget: Teksten i denne instruktion er ikke en del

Læs mere

Dansk testbegrebsliste version 1.0

Dansk testbegrebsliste version 1.0 Dansk testbegrebsliste - med udgangspunkt i Glossary Dansk testbegrebsliste version 1.0 Der findes ikke én internationalt anerkendt testbegrebsliste, men den europæiske terminologi henter generelt inspiration

Læs mere

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

Idékatalog Planlægning og brug af test i statslige it-projekter Idékatalog Planlægning og brug af test i statslige it-projekter Januar 2014 INDHOLD 1. INDLEDNING...1 2. TYPER AF TEST...2 3. PLANLÆGNING AF TEST I FASERNE...6 3.1 IDÉFASEN...6 3.2 ANALYSEFASEN...7 3.3

Læs mere

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

Testprocesser og målinger i test. Jesper Schultz, Nykredit 19. november 2009 Testprocesser og målinger i test Jesper Schultz, Nykredit 19. november 2009 Agenda TMM måling og vores arbejde med at måle kvaliteten af den test der køres i projekter i Nykredit TMMi 2009 Baggrund Resultater

Læs mere

CV Jakob Niemann. Resumé: Nøglekvalifikationer. Personlighed. Født: 24/02 1976

CV Jakob Niemann. Resumé: Nøglekvalifikationer. Personlighed. Født: 24/02 1976 Jakob Niemann IT Konsulent Født: 24/02 1976 Rosendalsgade 11, 2. TV. 2100 København Ø Tlf: +45 2859 9808 JakobNiemann@gmail.com Resumé: Test og Quality Manager med mere end 15 års IT erfaring. Har stor

Læs mere

Succesfuld implementering af automatiseret test

Succesfuld implementering af automatiseret test Succesfuld implementering af automatiseret test Forudsætningerne og faldgruberne John Fodeh john.fodeh@hp.com 2006 Hewlett-Packard Development Company, L.P. The information contained herein is subject

Læs mere

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

10 spørgsmål der vil hjælpe dig med dine testcases 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

Læs mere

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

Agil-model versus V-model set i lyset af en testers dilemmaer Agil-model versus V-model set i lyset af en testers dilemmaer 1 Præsentation Foredragsholder Ane Clausen: Cand.Scient i Datalogi Københavns Universitet, Danmark Gift, 3 børn 25 års erfaring med IT: 12

Læs mere

Certified Tester Pensum for Foundation-niveauet

Certified Tester Pensum for Foundation-niveauet Certified Tester Frigivet Version 2011 International Software Testing Qualifications Board (Dansk udgave release oktober 2011) Copyright-bestemmelser Dette dokument må kopieres i sit fulde omfang eller

Læs mere

Hos Lasse Ahm Consult vurderer vi at følgende supplerende krav i de enkelte kravelementer er væsentlige at bemærke:

Hos Lasse Ahm Consult vurderer vi at følgende supplerende krav i de enkelte kravelementer er væsentlige at bemærke: ISO 9001:2015 (Draft) Side 1 af 9 Så ligger udkastet klar til den kommende version af ISO 9001. Der er sket en række strukturelle ændringer i form af standardens opbygning ligesom kravene er blevet yderligere

Læs mere

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

Softwaretest. - også af ikke testbar software. DAPUG erfamøde 7. marts 2012 Thomas Vedel, Thomas Vedel Consult email: thomas@veco. Softwaretest - også af "ikke testbar" software DAPUG erfamøde 7. marts 2012 Thomas Vedel, Thomas Vedel Consult email: thomas@veco.dk Hvorfor softwaretest? Software er sjældent fejlfri Test sikrer at softwaren

Læs mere

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

OPTION TIL RM OG RN BILAG 12 TIL KONTRAKT OM EPJ/PAS PRØVER OPTION TIL RM OG RN BILAG 12 TIL KONTRAKT OM EPJ/PAS PRØVER INSTRUKTION TIL LEVERANDØR VED UDNYTTELSE AF OPTIONEN: Teksten i dette afsnit er ikke en del af Kontrakten og vil blive fjernet ved kontraktindgåelse.

Læs mere

Au Aarhus Universitet. Aarhus Universitet AU på STADS Teststrategi Version 1.0

Au Aarhus Universitet. Aarhus Universitet AU på STADS Teststrategi Version 1.0 Aarhus Universitet AU på STADS Teststrategi Version 1.0 Version Dato Version Udarbejdet af Godkendt af Beskrivelse 15-10-2009 0.1 LBA Første udkast 16-11-2009 0.2 GST Revideret udkast 18-12-2009 0.3 GST

Læs mere

Bias Reducing Operating System - BROS -

Bias Reducing Operating System - BROS - Bias Reducing Operating System - BROS - Accepttestspecifikation Projektgruppe 3: Rasmus Lund Jensen (11111) Nicolai Glud(11102) Jacob Roesen(10095) Mick Holmark(11065) Johnny Kristensen(10734) 1 Versionshistorik

Læs mere

Bilag 14 Prøver INSTRUKTION TIL TILBUDSGIVER:

Bilag 14 Prøver INSTRUKTION TIL TILBUDSGIVER: Bilag 14 Prøver INSTRUKTION TIL TILBUDSGIVER: Bilag 14 skal udfyldes af tilbudsgiver som del af tilbuddet. Udfyldelse skal ske i overensstemmelse med nedenstående retningslinjer. 2 14. INDLEDNING... 3

Læs mere

Bilag 6 Afprøvninger Version 1.0 23-02-2015

Bilag 6 Afprøvninger Version 1.0 23-02-2015 Bilag 6 Afprøvninger Version 1.0 23-02-2015 Indhold 1 VEJLEDNING TIL TILBUDSGIVER... 7 2 INDLEDNING... 8 2.1 TERMINOLOGI... 8 2.2 TESTOMFANG... 8 2.3 TESTORGANISATION... 10 2.4 ANSVARSFORDELING (ROLLER

Læs mere

Certified Tester Foundation Level Syllabus

Certified Tester Foundation Level Syllabus Version 2007 Dansk udgave Copyright 2007, ophavsmændene (Thomas Müller (formand), Dorothy Graham, Debra Friedenberg og Erik van Veendendal). Copyright 2005, ophavsmændene (Thomas Müller (formand), Rex

Læs mere

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

Udbud af Telemedicinsk løsning til hjemmemonitorering. Bilag 14 - Prøver Udbud af Telemedicinsk løsning til hjemmemonitorering Bilag 14 - Prøver 2 Indholdsfortegnelse 14. Prøver 4 14.1 Indledning 4 14.2 Afprøvningsprogram 5 14.2.1 Generelle krav til afprøvningsprogrammet 5

Læs mere

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

Teksten i denne instruktion er ikke en del af Kontrakten og vil blive fjernet ved kontraktindgåelse. BILAG 10 PRØVER Indholdsfortegnelse 1. Prøver... 4 2. Fælles regler for afprøvning... 4 2.1 Afklaringsproces og udarbejdelse af test cases... 4 2.2 Beskrivelse af afklaringsproces og udarbejdelse af test

Læs mere

Hos Lasse Ahm Consult vurderer vi at følgende krav i de enkelte kravelementer er væsentlige at bemærke:

Hos Lasse Ahm Consult vurderer vi at følgende krav i de enkelte kravelementer er væsentlige at bemærke: ISO 9001:2015 Side 1 af 8 Så ligger det færdige udkast klar til den kommende version af ISO 9001:2015. Standarden er planlagt til at blive implementeret medio september 2015. Herefter har virksomhederne

Læs mere

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

[Navn på Tilbudsgiver] Udbudsmateriale. Dato: Bilag 14. Version: 1.0. Bilag 14. Prøver. Bilag 14 Prøver Side 1 / 36 [Navn på Tilbudsgiver] Udbudsmateriale Dato: 02-05-2012 Bilag 14 Version: 1.0 Bilag 14 Prøver Bilag 14 Prøver Side 1 / 36 1 Indledning... 6 2 Teststrategi for projektet... 7 2.1 Udarbejdelse af teststrategi...

Læs mere

Indhold. Forord... 11

Indhold. Forord... 11 Indhold Forord................................................ 11 1 Indledning.......................................... 13 1.1 Definitioner........................................ 15 1.2 Formålet med

Læs mere

DE BEAR TECHNOLOGY. o Processer, metoder & værktøjer. e-mail: info@dbtechnology.dk WWW.DBTECHNOLOGY.DK

DE BEAR TECHNOLOGY. o Processer, metoder & værktøjer. e-mail: info@dbtechnology.dk WWW.DBTECHNOLOGY.DK Mission Critical o Projekt Information management o Processer, metoder & værktøjer. Side 1 of 11 Projekt information Projekt information management inkluderer alle de processer, som er nødvendige for at

Læs mere

Vejledning: Side 2 af 36 Bilag 11

Vejledning: Side 2 af 36 Bilag 11 Bilag 11 Prøver Vejledning: Afprøvning af Leverancen sker ved en fabriksprøve, overtagelsesprøve og driftsprøve. Såfremt Leverancen er opdelt i delleverancer, gennemføres der tillige delleveranceprøver

Læs mere

Copyright 2010 Netcompany A/S. Alle rettigheder forbeholdes.

Copyright 2010 Netcompany A/S. Alle rettigheder forbeholdes. Version: 1. Status: Godkendt Godkender: Niels. Alle rettigheder forbeholdes. Elektronisk, mekanisk, fotografisk eller anden gengivelse, oversættelse eller kopiering af dette dokument

Læs mere

Automation Projektledelse Networking GAPP. GAPP kravspecifikation

Automation Projektledelse Networking GAPP. GAPP kravspecifikation GAPP GAPP kravspecifikation Kravspecifikation - formål Kategorisere, vurdere og samle krav i logisk og funktionelle grupper for at: Øge overblikket Undgå overlappende og modstridende krav Skærpe de enkelte

Læs mere

E2E Teststrategi Engrosmodellen

E2E Teststrategi Engrosmodellen E2E Teststrategi Engrosmodellen Et overblik over metode og proces Ver. 1.00 FRE August 2013 1 Kort om: End to End (E2E) Test Generelt om End-to-End (E2E) Test Formålet med at gennemføre en E2E test er

Læs mere

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

Secure O matic. Gruppe 5 2. SEMESTERPROJEKT. Udgave. Accepttest-specifikation Udgave 2 2. SEMESTERPROJEKT Gruppe 5 Secure O matic Accepttest-specifikation Benjamin Sørensen, 02284 Tomas Stæhr Hansen, 03539 Stefan Nielsen, 02829 Mubeen Ashraf, 9279 Hussein Kleit, 9281 SECURE O MATIC

Læs mere

Forberedelse og planlægning af GMP Audit

Forberedelse og planlægning af GMP Audit Forberedelse og planlægning af GMP Audit Juli, 2014 Indledning I de kommende sider får du nogle hurtige tips og råd til din forberedelse og planlægning af en GMP audit. Dette er ikke en komplet og grundig

Læs mere

Scope Management ITU 11-09-2013 @janhmadsen #ituscpmgt

Scope Management ITU 11-09-2013 @janhmadsen #ituscpmgt Scope Management ITU 11-09-2013 @janhmadsen Dagsorden Oplægsholder Projektstyring Scope Management i en fælles kontekst Definitioner Scope Management - styring af omfang ved projektets start under projektets

Læs mere

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

10 informationer som gør din fejlrapport selvforklarende for både forretningen og programmørerne 10 informationer som gør din fejlrapport selvforklarende for både forretningen og programmørerne Introduktion Uanset hvor mange informationer man tilføjer en fejlrapport er det vigtigt, at man beslutter

Læs mere

Mobiltest typiske udfordringer og deres løsninger

Mobiltest typiske udfordringer og deres løsninger Mobiltest typiske udfordringer og deres løsninger Side 1 af 6 Introduktion Ved test af mobile løsninger, er det vigtigt at man forholder sig til en række faktorer og udfordringer, ud over dem man kender

Læs mere

Test i Danmark 2014. Undersøgelse på TestExpo 2014

Test i Danmark 2014. Undersøgelse på TestExpo 2014 Test i Danmark 2014 Undersøgelse på TestExpo 2014 Indledning I forbindelse med TestExpo-konferencen (www.testexpo.dk) den 30/1 2014 i Bella Center i København blev der foretaget en spørgeskemaundersøgelse.

Læs mere

Statistisk databaseret automatisk test. Jesper Mortensen / Erik Dargsdorff

Statistisk databaseret automatisk test. Jesper Mortensen / Erik Dargsdorff Statistisk databaseret automatisk test Jesper Mortensen / Erik Dargsdorff Oversigt: Præsentation Baggrunden Kompetencekløften Mål med testen Typer af test der blev anvendt Hvad er statistisk databaseret

Læs mere

Virksomheden bør udvikle, implementere og konstant forbedre de rammer, der sikrer integration af processen til at håndtere risici i virksomhedens:

Virksomheden bør udvikle, implementere og konstant forbedre de rammer, der sikrer integration af processen til at håndtere risici i virksomhedens: DS/ISO 31000 Risikoledelse ISO 31000 - Risikoledelse Virksomheden bør udvikle, implementere og konstant forbedre de rammer, der sikrer integration af processen til at håndtere risici i virksomhedens: overordnede

Læs mere

FAT test kan kun undtagelsesvis overføres, et eksempel kunne være verifikation af tag nummerering og el-diagrammer, som kræver en adskilt maskine.

FAT test kan kun undtagelsesvis overføres, et eksempel kunne være verifikation af tag nummerering og el-diagrammer, som kræver en adskilt maskine. Kontraktbilag 8 Prøver 1 FAT og SAT FAT og SAT skal sikre at systemet er klar til kvalificering, dvs. alle test fra IQ, OQ og PQ bør kunne genfindes. Testmateriale udarbejdet af leverandør i forbindelse

Læs mere

Secure O matic. Gruppe 5 2. SEMESTERPROJEKT. Udgave. Testspecifikation

Secure O matic. Gruppe 5 2. SEMESTERPROJEKT. Udgave. Testspecifikation Udgave 1 2. SEMESTERPROJEKT Gruppe 5 Secure O matic Testspecifikation Benjamin Sørensen, 02284 Tomas Stæhr Hansen, 03539 Stefan Nielsen, 02829 Mubeen Ashraf, 9279 Hussein Kleit, 9281 SECURE O MATIC Testspecifikation

Læs mere

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

FRA USECASE TIL TESTCASE HP TEST BRUGERKONFERENCE, 10. APRIL 2014 FRA USECASE TIL TESTCASE HP TEST BRUGERKONFERENCE, 10. APRIL 2014 LIDT OM MIG SELV Erfaring NIELS-HENRIK HANSEN 35+ års samlet IT erfaring 15+ år som test manager Certificeret Inspection Leader ISEB Foundation

Læs mere

Styring af testmiljøer almindelig god praksis

Styring af testmiljøer almindelig god praksis White paper Styring af testmiljøer almindelig god praksis Søren Beyer Nielsen Ph.D., M.Sc. Pragmatic Consult A/S v. 1.2 Pragmatic Consult A/S Stadagervej 42 2730 Herlev Danmark Tel: 44 92 23 77 Fax: 44

Læs mere

High performance maksimér potentialet. En måling er bedre end 100 mavefornemmelser. Per Hartlev ph@whitebox.dk 30/9-2015

High performance maksimér potentialet. En måling er bedre end 100 mavefornemmelser. Per Hartlev ph@whitebox.dk 30/9-2015 High performance maksimér potentialet En måling er bedre end 100 mavefornemmelser Per Hartlev ph@whitebox.dk 30/9-2015 Release-styring Hjælpe værktøjer Kvalitets sikring Leverandør kontrakter Kurser Opgave

Læs mere

Hos Lasse Ahm Consult vurderer vi at følgende krav i de enkelte kravelementer er væsentlige at bemærke:

Hos Lasse Ahm Consult vurderer vi at følgende krav i de enkelte kravelementer er væsentlige at bemærke: ISO 9001:2015 Side 1 af 8 Så blev den nye version af ISO 9001 implementeret. Det skete den 23. september 2015 og herefter har virksomhederne 36 måneder til at implementere de nye krav i standarden. At

Læs mere

Spillemyndighedens certificeringsprogram. Generelle krav SCP DK.1.1

Spillemyndighedens certificeringsprogram. Generelle krav SCP DK.1.1 SCP.00.00.DK.1.1 Indhold Indhold... 2 1 Indledning... 3 1.1 Spillemyndighedens certificeringsprogram... 3 1.2 Definitioner... 3 1.3 Lovmæssigt grundlag for certificeringsprogrammet... 4 1.4 Version...

Læs mere

Sikkerhedsanbefaling. Forholdsregler ved ophør af serviceopdateringer til Windows XP Embedded

Sikkerhedsanbefaling. Forholdsregler ved ophør af serviceopdateringer til Windows XP Embedded Sikkerhedsanbefaling Forholdsregler ved ophør af serviceopdateringer til Windows XP Embedded Juli 2014 Indledning Microsoft har annonceret, at selskabet den 31. december 2016 frigiver den sidste serviceopdatering

Læs mere

Test i Danmark. Undersøgelse på. TestExpo

Test i Danmark. Undersøgelse på. TestExpo Test i Danmark Undersøgelse på 2015 TestExpo 1 Indledning Velkommen til anden udgave af Test i Danmark rapporten. Test i Danmark har til formål at undersøge softwaretest og QA tendenser i Danmark og dets

Læs mere

Kvalitetssikring af IT udvikling hos TDC

Kvalitetssikring af IT udvikling hos TDC Kvalitetssikring af IT udvikling hos TDC Kvalitetsrevisor Henning Sams Har være ansat hos TDC siden 1976 og har arbejdet med kvalitet i ca. 10 år, primært som QAér og Proceskonsulent. Underviser bl.a på

Læs mere

Brugerskabte data en national service (BSD) - produktbeskrivelse

Brugerskabte data en national service (BSD) - produktbeskrivelse - 1 Brugerskabte data en national service (BSD) - produktbeskrivelse Brugerskabte data en national service (BSD) - produktbeskrivelse...1 Indledning...1 Formål...1 Beskrivelse...1 Basale krav til det bibliotek/website

Læs mere

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

Prøverne gennemføres som henholdsvis en Idriftsættelsesprøve, en Driftovertagelsesprøve og en. Prøve Delprøve Delprøve Bilag 12 Afprøvning Side 1 af 9 Bilag 12 Afprøvning I forbindelse med etablering af EPJ skal der gennemføres kvalitetsstyringsaktiviteter jf. bilag 10, herunder afprøvning og evaluering af den samlede

Læs mere

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

Struktureret system udvikling Minimodul 1: Introduktion, UML og use cases Struktureret system udvikling Minimodul 1: Introduktion, UML og use cases Rasmus L. Olsen, 27 februar 2008 Introduktion Kursets hjemmeside http://www.kom.aau.dk/~rlo/ Kursus holder Rasmus L. Olsen Færdiguddannet

Læs mere

Infoblad. ISO/TS 16949 - Automotive

Infoblad. ISO/TS 16949 - Automotive Side 1 af 5 ISO/TS 16949 - Automotive Standarden ISO/TS 16949 indeholder særlige krav gældende for bilindustrien og for relevante reservedelsvirksomheder. Standardens struktur er opbygget som strukturen

Læs mere

Innovationens Syv Cirkler

Innovationens Syv Cirkler Innovationens Syv Cirkler Med denne gennemgang får du en kort introduktion af Innovationens Syv Cirkler, en model for innovationsledelse. Dette er en beskrivelse af hvilke elementer der er betydende for

Læs mere

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

Bilag 14: Prøver. Udbud om levering, installation, implementering, support, drift og vedligehold af Borgeradministrativt System (BAS) Bilag 14: Prøver Udbud om levering, installation, implementering, support, drift og vedligehold af Borgeradministrativt System (BAS) Indhold bilag 14 Prøver 14. Prøver... 3 14.1 Indledning... 3 14.2 Afprøvningsprogram

Læs mere

Projektlederens roller og kompetencer. Cases til Projektlederens roller og kompetencer

Projektlederens roller og kompetencer. Cases til Projektlederens roller og kompetencer Cases til Projektlederens roller og kompetencer Palle Ragn 1/9 Bibliografiske oplysninger Kursus: Lokalitet: Afgangsprojekt, Diplom uddannelsen i ledelse JCVU, Århus, Danmark Forfatter: Palle Ragn, 160364

Læs mere

Load Test. Projektet afgår om få minutter fra SPOR 3

Load Test. Projektet afgår om få minutter fra SPOR 3 Load Test Projektet afgår om få minutter fra SPOR 3 Vision Testforberedelse Testens troværdighed afhænger meget nøje af den overensstemmelse der er mellem testen og virkeligheden, eller sagt på en anden

Læs mere

Teststrategi Engrosmodellen

Teststrategi Engrosmodellen Teststrategi Engrosmodellen Et overblik over metode og proces Vers. 1.1 Maj 2014 1 Målet med test af Engrosmodel Sikre at Engrosmodellen funktionelt fungerer efter hensigten i samspil med aktørernes it-systemer

Læs mere

It-sikkerhedstekst ST8

It-sikkerhedstekst ST8 It-sikkerhedstekst ST8 Logning til brug ved efterforskning af autoriserede brugeres anvendelser af data Denne tekst må kopieres i sin helhed med kildeangivelse. Dokumentnavn: ST8 Version 1 Maj 2015 Logning

Læs mere

Risikovurdering af Engrosmodelprojektet

Risikovurdering af Engrosmodelprojektet Risikovurdering af Engrosmodelprojektet Godkendt af dialogforum d. 2. Oktober 2014 Dok. 14/23107-6 Oktober 2014 1 Vurdering af risici - generelt Proces for udarbejdelse af fælles risikovurdering Deltagere

Læs mere

Om fejl. Appendiks til bogen Struktureret Test

Om fejl. Appendiks til bogen Struktureret Test Om fejl Appendiks til bogen Struktureret Test Om fejl... 1 Appendiks til bogen Struktureret Test... 1 1. Hvad er den rigtige fejl?... 2 2. Hvornår er en fejl alvorlig?... 2 3. Taksten på reparation af

Læs mere

Risikovurdering. Dialogforum 2. Oktober 2014. Dato - Dok.nr. 1

Risikovurdering. Dialogforum 2. Oktober 2014. Dato - Dok.nr. 1 Risikovurdering Dialogforum 2. Oktober 2014 Dato - Dok.nr. 1 Risikovurdering før mitigering Risiko Risikonavn Afklaring vedr. opkrævning af elafgifter er ikke på R01 plads. Bekendtgørelser fra Energistyrelsen

Læs mere

Bilag 14. Prøver. Til Kontrakt. Den Nationale Henvisningsformidling

Bilag 14. Prøver. Til Kontrakt. Den Nationale Henvisningsformidling Bilag 14 Prøver Til Kontrakt OM Den Nationale Henvisningsformidling Bilag 14 Prøver Side 1/25 INSTRUKTION TIL TILBUDSGIVER: Bilag 14 skal gennemarbejdes af Tilbudsgiver som del af tilbuddet. Udfyldelse

Læs mere

0-fejl udvikling. Appendiks til bogen Softwaretest

0-fejl udvikling. Appendiks til bogen Softwaretest 0-fejl udvikling Appendiks til bogen Softwaretest 0-fejl udvikling... 1 Appendiks til bogen Softwaretest... 1 1. Muligheder og forudsætninger... 2 2. Udgifter ved 0-fejl... 2 3. Indtægter ved 0-fejl...

Læs mere

Den bedste løsning er den som bliver anvendt

Den bedste løsning er den som bliver anvendt Den bedste løsning er den som bliver anvendt RISMA Vi er dedikeret til din succes Pålidelig rettidig information spiller en nøglerolle for succes i dagens omskiftelige forretningsverden. Samtidigt har

Læs mere

Audit beskrivelser for PL

Audit beskrivelser for PL 3-4-1 V01 3-4-1 V02 3-4-1 V03 3-4-1 V04 3-4-1 V05 Er der etableret et system til regelmæssig kontrol af processerne? Punktet er opfyldt, hvis der er en synlig regelmæssig måling for processen med acceptgrænser.

Læs mere

Den bedste løsning. er den som bliver anvendt. RISMAexecution

Den bedste løsning. er den som bliver anvendt. RISMAexecution Den bedste løsning er den som bliver anvendt RISMAexecution RISMA Vi er dedikeret til din succes Pålidelig rettidig information spiller en nøglerolle for succes i dagens omskiftelige forretningsverden.

Læs mere

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

Ledelse af test. et whitepaper om at holde styring på testforløb. Henrik Timm Ledelse af test et whitepaper om at holde styring på testforløb af Henrik Timm Indholdsfortegnelse 1 INDLEDNING... 3 1.1 FORMÅL... 3 1.2 UDFORDRINGER... 4 1.3 TESTPOLITIK OG STRATEGI... 4 1.4 TEST FORLØB...

Læs mere

Bilag 4: Dokumentation

Bilag 4: Dokumentation Bilag 4: Dokumentation Udbud af løn- og personalesystem Side 1 Indhold bilag 4 Bilag 4 Dokumentation... 3 4.1 Indledning... 3 4.2 Overordnede dokumentationskrav... 3 4.3 Dokumentation af leverance... 3

Læs mere

Agil test tilgang - erfaringer fra projekter

Agil test tilgang - erfaringer fra projekter Agil test tilgang - erfaringer fra projekter af Michael Roar Borlund November 2011 Image Area Agenda Introduktion Agil test Fremtidsvision Agil test tilgang Agil opbygning i QC Resumé og Spørgsmål 2 Introduktion

Læs mere

Branchens perspektiv på den gode indkøbs organisation. En måling er bedre end 100 mavefornemmelser. Per Hartlev

Branchens perspektiv på den gode indkøbs organisation. En måling er bedre end 100 mavefornemmelser. Per Hartlev Branchens perspektiv på den gode indkøbs organisation En måling er bedre end 100 mavefornemmelser Per Hartlev ph@whitebox.dk 7/11-2016 Release-styring Hjælpe værktøjer Kvalitets sikring Leverandør kontrakter

Læs mere

Fælles teststrategi for Ejendomsdataprogrammet og Adresseprogrammet

Fælles teststrategi for Ejendomsdataprogrammet og Adresseprogrammet Grunddataprogrammets delaftale 1 og 2 om effektiv ejendomsforvaltning og genbrug af ejendomsdata under den Fællesoffentlige Digitaliseringsstrategi 2012 2015 Fælles teststrategi for Ejendomsdataprogrammet

Læs mere

PRINCE2 med tusind ord. Andy Murray, PRINCE2 (2009) lead author og direktør for Outperform UK Ltd. AXELOS.com. The Stationery Office 2011

PRINCE2 med tusind ord. Andy Murray, PRINCE2 (2009) lead author og direktør for Outperform UK Ltd. AXELOS.com. The Stationery Office 2011 PRINCE2 med tusind ord Andy Murray, PRINCE2 (2009) lead author og direktør for Outperform UK Ltd AXELOS.com White Paper September 2011 Indhold 1 Hvad er PRINCE2? 3 2 Fordele ved PRINCE2 3 3 Principper

Læs mere

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

TESTAUTOMATISERING. Præsentation af: BPT anvendt til automatiseret test. HP test brugerkonference november 2008 TESTAUTOMATISERING Præsentation af: BPT anvendt til automatiseret test HP test brugerkonference november 2008 Foredragsholdere Cand.Scient fra DIKU Har arbejdet 22 år med IT heraf 8 år med Test 2 år med

Læs mere

Aktuel driftsstatus for IndFak

Aktuel driftsstatus for IndFak Aktuel driftsstatus for IndFak Side 1 af 5 Der er på nuværende tidspunkt 72 institutioner, som anvender IndFak. Der er fortsat forskellige driftsmæssige problemer samt uhensigtsmæssigheder i systemet.

Læs mere

Bilag 9, Kvalitetssikring

Bilag 9, Kvalitetssikring Bilag 9, Kvalitetssikring Version Ændringer Dato 2.1 Ændret i: 06-02-2014 - Punkt 1 - Punkt 2 - Krav 9.1 - Krav 9.2 - Krav 9.3 - Krav 9.5 - Krav 9.6 - Krav 9.7 - Krav 9.8 - Tilføjet krav 9.14 - Tilføjet

Læs mere

Underbilag 14 B: Oversigt over prøve- og testtyper. Udbud om levering, installation, implementering, support, drift og vedligehold af BAS

Underbilag 14 B: Oversigt over prøve- og testtyper. Udbud om levering, installation, implementering, support, drift og vedligehold af BAS Underbilag 14 B: Oversigt over prøve- og testtyper Udbud om levering, installation, implementering, support, drift og vedligehold af BAS Indhold underbilag 14 B Oversigt over prøve- og testtyper 14 B Oversigt

Læs mere

10 gode råd. Vælg den rette model. af konsulent Morten Korsaa, DELTA

10 gode råd. Vælg den rette model. af konsulent Morten Korsaa, DELTA 10 gode råd af konsulent Morten Korsaa, DELTA Vælg den rette model SKI rammekontrakten giver mulighed for at bruge to udviklingsmodeller den klassiske og den nye. Dit valg er afgørende for succes. Den

Læs mere

DSDW, Jobindsats og Refusionsløsningen

DSDW, Jobindsats og Refusionsløsningen Bilag 0 Definitioner Indhold 1. Definitioner... 3 Bilag 0: Definitioner Side 1 af 9 Vejledning til Leverandøren: Leverandøren må ikke tilføje eller ændre noget i bilaget. Bilag 0: Definitioner Side 2 af

Læs mere

Nyheder i Remote Support Platform 3.0

Nyheder i Remote Support Platform 3.0 Nyheder Remote Support Platform for SAP Business One Dokumentversion: 1.0 08.10.12 Alle lande Typografiske konventioner Typografi Eksempel Ord eller tegn citeret fra skærmbilledet. Disse omfatter feltnavne,

Læs mere

Projekt DAF. Digitale annonceordrer og fakturaer Funktionel kravspecifikation Infrastruktur

Projekt DAF. Digitale annonceordrer og fakturaer Funktionel kravspecifikation Infrastruktur IT & Operational Developement Projekt DAF Digitale annonceordrer og fakturaer Funktionel kravspecifikation Infrastruktur Politiken Jyllandsposten Berlingske Tidende OMD Carat Mediaedge:CIA Mediacom Initiative

Læs mere

Generel projektbeskrivelse

Generel projektbeskrivelse 02121 Ingeniørarbejde Softwareteknologi Januar 2010 1 Introduktion Generel projektbeskrivelse Formålet med programmeringsprojektet er at give deltagerne erfaring med at designe og konstruere et simpelt

Læs mere

"SAP" betyder det SAP-selskab, med hvem du indgik kontrakt om tjenesten.

SAP betyder det SAP-selskab, med hvem du indgik kontrakt om tjenesten. Serviceaftaleprogram for Ariba Cloud Services Garanti for Tjenestens tilgængelighed Sikkerhed Diverse 1. Garanti for Tjenestens tilgængelighed a. Anvendelighed. Garantien for tjenestens tilgængelighed

Læs mere

Bilag 6 Afprøvninger Version

Bilag 6 Afprøvninger Version Bilag 6 Afprøvninger Version 0.8 26-06-2015 Indhold 1 VEJLEDNING TIL TILBUDSGIVER... 7 2 INDLEDNING... 8 2.1 TERMINOLOGI... 8 2.2 TESTOMFANG... 8 2.3 TESTORGANISATION... 10 2.4 ANSVARSFORDELING (ROLLER

Læs mere

Revideret Miljøledelsesstandard

Revideret Miljøledelsesstandard Revideret Miljøledelsesstandard ISO 14001:2015 Ændringer ift. DS/EN ISO 14001:2004 Dokumentationskrav i ny ISO 14001 GREENET- Revideret ISO 14001 1 MiljøForum Fyn - Revideret ISO 14001 2 1 Termer og definitioner

Læs mere

Automatisk Vandingssystem

Automatisk Vandingssystem Automatisk Vandingssystem Projektdokumentation Aarhus Universitet Gruppe 6-3. Semester - F15 vejleder: Michael Alrøe dato: 28-05-2015 Lærke Isabella Nørregård Hansen - 201205713 - IKT Kasper Sejer Kristensen

Læs mere

STUDIEORDNING. professionsbachelor i softwareudvikling

STUDIEORDNING. professionsbachelor i softwareudvikling STUDIEORDNING for professionsbachelor i softwareudvikling Revideret 9. juni 2017 Indhold 1. Uddannelsens mål for læringsudbytte... 2 2. Uddannelsen indeholder fire nationale fagelementer... 3 2.1. Udvikling

Læs mere

Studieordning Professionsbachelor i softwareudvikling National del

Studieordning Professionsbachelor i softwareudvikling National del Studieordning Professionsbachelor i softwareudvikling National del 1. Indholdsfortegnelse 1. Indholdsfortegnelse... 0 2. Uddannelsens mål for læringsudbytte... 1 3. Uddannelsen indeholder fire nationale

Læs mere

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

Teststrategi for DataHub Engrosmodellen End-to-End (E2E) test Teststrategi for DataHub Engrosmodellen End-to-End (E2E) test Et overblik over metode og proces Version 2.0, maj 2015 Maj 2015, dok.nr. 13-100790-2 E2E Teststrategi 1 Målet med E2E test af Engrosmodel

Læs mere

Behov for mere indsigt i softwaretest? Anvend testmetrikker!

Behov for mere indsigt i softwaretest? Anvend testmetrikker! Behov for mere indsigt i softwaretest? Anvend testmetrikker! Ole Chr. Hansen April 2011 2 Hvem er jeg? Ole Chr. Hansen Training Delivery Manager & Managing Consultant Blog - http://ochansen.blogspot.com

Læs mere

Certificeret Tester. Advanced Test Manager Pensum

Certificeret Tester. Advanced Test Manager Pensum Certificeret Tester Advanced Test Manager Pensum Dansk version 2012 ing Copyright-bestemmelser Dette dokument må kopieres i sit fulde omfang eller i uddrag, så længe kilden er angivet. Advanced niveau

Læs mere

DD110 - Detaljeret projektplan

DD110 - Detaljeret projektplan Version: 1.3 Status: Godkendt Godkender: Dokumenthistorik Version Dato Navn Status Bemærkninger 1.0 9-11-2007 Endelig Initiel version 1.1 22-11-2007 Godkendt 1.2 28-11-2007

Læs mere

Kontrakt om Videreudvikling, Vedligeholdelse og Support af IMK2- systemet

Kontrakt om Videreudvikling, Vedligeholdelse og Support af IMK2- systemet Kontrakt om Videreudvikling, Vedligeholdelse og Support af IMK2- systemet Bilag 1 Definitioner 12.05.2016 Version 1.0 [Vejledning til tilbudsgiver: Bilaget er i sin helhed at betragte som et mindstekrav

Læs mere

KORT OM PROJEKTPORTEFØLJESTYRING. Af Jacob Kragh-Hansen, Execution Consulting Group

KORT OM PROJEKTPORTEFØLJESTYRING. Af Jacob Kragh-Hansen, Execution Consulting Group KORT OM PROJEKTPORTEFØLJESTYRING Af Jacob Kragh-Hansen, Execution Consulting Group KORT OM PROJEKTPORTEFØLJESTYRING INDHOLD 1 PROJEKTPORTEFØLJESTYRING 2 TYPISKE UDFORDRINGER 3 RATIONALE & GEVINSTER 4 ANBEFALET

Læs mere

Opgrader til nyeste Dynamics AX version og profiter af løbende opdateringer

Opgrader til nyeste Dynamics AX version og profiter af løbende opdateringer INDLÆG 13 : DYNAMICS AX Opgrader til nyeste Dynamics AX version og profiter af løbende opdateringer Tonny Bybæk, Lau Bøgelund Larsen Opgrader til nyeste Dynamics AX version og profiter af løbende opdateringer

Læs mere

- Erfaringer med implementering af MES løsninger. SESAM RAMBØLL, d 31. marts. 2011 DC Produktions IT Projekt Afdelingen Arne Boye-Møller

- Erfaringer med implementering af MES løsninger. SESAM RAMBØLL, d 31. marts. 2011 DC Produktions IT Projekt Afdelingen Arne Boye-Møller - Erfaringer med implementering af MES løsninger SESAM RAMBØLL, d 31. marts. 2011 DC Produktions IT Projekt Afdelingen Arne Boye-Møller DC Projektorganisation Arne J. Boye-Møller, Produktions IT, Projektafdelingen

Læs mere

Kaizenevent En introduktion til metoden

Kaizenevent En introduktion til metoden : LEANREJSEN - Kaizenevent En introduktion til metoden Adobe full screen: Ctrl + L Brugerlicens DI ejer alle rettigheder til denne præsentation For filer i formatet Adobe giver DI en brugerlicens til alle

Læs mere

Certificeret Tester. Advanced Test Analyst Pensum

Certificeret Tester. Advanced Test Analyst Pensum Certificeret Tester Advanced Test Analyst Pensum Dansk version 2012 Copyright-bestemmelser Dette dokument må kopieres i sit fulde omfang eller i uddrag, så længe kilden er angivet. Copyright ing (herefter

Læs mere

Bilag 6: Servicemål. Udbud af E-rekrutteringssystem. Side 1 af 9

Bilag 6: Servicemål. Udbud af E-rekrutteringssystem. Side 1 af 9 Bilag 6: Servicemål Udbud af E-rekrutteringssystem Side 1 af 9 Indhold Bilag 6 Servicemål 3 6.1 Indledning 3 6.2 Systemets normale driftstid 3 6.3 Svartider 3 6.3.1 Krav til svartider 3 6.3.2 Måling af

Læs mere

Bilag 6: Servicemål. Udbud af løn- og personalesystem. Side 1 af 9

Bilag 6: Servicemål. Udbud af løn- og personalesystem. Side 1 af 9 Bilag 6: Servicemål Udbud af løn- og personalesystem Side 1 af 9 Indhold Bilag 6 Servicemål... 3 6.1 Indledning... 3 6.2 Systemets normale driftstid... 3 6.3 Svartider... 3 6.3.1 Krav til svartider...

Læs mere

Procedurer for styring af softwarearkitektur og koordinering af udvikling

Procedurer for styring af softwarearkitektur og koordinering af udvikling LEVERANCE 2.3 Procedurer for styring af softwarearkitektur og koordinering af udvikling Procedurerne vil omfatte: Planlægning af udfasning af gamle versioner af OpenTele Planlægning af modning af kode

Læs mere