Indhold. Forord... 11
|
|
- Elias Mortensen
- 8 år siden
- Visninger:
Transkript
1 Indhold Forord Indledning Definitioner Formålet med test fejl udvikling Tidlig gentagbar og evig tekst Nytten af registreringer Nyudvikling eller systemvorvaltning Kvikstart Testens faser Indledning Komponenttest Integrationstest Systemtest Brugertest Alfatest Betatest Accepttest De grundlæggende teststrategier Kvikstart Testen i de tidlige faser Hvad er tidlig test? Test af foranalysen Test af analysen Test af design Test af konstruktion Modelbaseret test UML (Unified Modeling Language) Klassediagram Use case-model Den enkelte use case (brugsmønster) indhold 5
2 3.11 Sekvensdiagram Kollaborationsdiagram Aktivitetsdiagram Tilstandsdiagrammer Opsummering på UML Kvikstart Systemegenskaber Indledning Et færdigt sæt egenskaber Komplethed Nøjagtighed Robusthed Ensartethed Brugervenlighed Testbarhed Forvaltningsegnethed Genbrugsmulighed Ydeevne Sikkerhed Flytbarhed Hvornår defineres målet for en egenskab Hvornår testes en egenskab Kvikstart Testteknikker Indledning Formålet med testteknikker Whitebox-teknikker Test af programkode Dækningstyperne Metrics Maskinel støtte til whitebox-test Kvalitetsstyring af den fysiske kode Whitebox-test på andet end kode Blackbox-teknikker Dækning Datadrevet indhold
3 5.4.3 Drevet af forventninger Scenarier som testenhed Hændelser som testenhed Funktioner som testenhed Transaktioner som testenhed Drevet af risici Tilstande som testenhed Entiteter som testenhed Klasser som testenhed I/O som testenhed Lede lister drevet af skepsis Use cases Krav til testenheden Greybox-teknikker Hvad er det Greybox bringer folk sammen Hvornår kan det betale sig Opsummering på testteknikker Kvikstart Reviews Indledning Walk-through Play-through Fortolkende review Inspektion Godkendende review Review af underleverancer Kritiske succesfaktorer Afledte fordele ved reviews Kvikstart Planlægning og styring Behovet IEEE-modellen Specifikationen Grovplanen Testaktiviteter indhold 7
4 7.6 Detailplanen Testcases Drejebog Estimater Planlægningsseminar Gennemførelse af testen Opfølgning på testen Kriterier for at stoppe testen Udviklingsstrategiens betydning Kvikstart Organisation Det menneskelige testmiljø Kritiske succesfaktorer Opgaver, ansvar og kompetence Projekt eller løbende forvaltning? Testere i forskellige testfaser Kvikstart Portaler og websider Indledning Kategoriseringer Testområder Testfaserne Reviews og inspektioner Værktøjer Checklister Kvikstart Exploratory testing udforskende test Indledning, definition Elementerne i en udforskende test Typer af udforskende test Grundlaget Fordele og risici ved udforskende test Udforskende test kontra planlagt test Processen Exploratory testing og agile processer
5 10.9 Afsluttende bemærkninger Kvikstart Agile Testing Indledning Karakteristika for Agile Testing Marick s matrix Eksempel: Handelssystemet Testerrollen Kvikstart Links og litteratur Register indhold 9
6 10 kapitel 6
7 Forord Test som aktivitet Test er en omfattende aktivitet, målt i tid, og det gælder både når der nyudvikles i et projekt og videreudvikles i releases. Test dækker ofte % af det samlede tidsforbrug. Der er derfor brug for at strukturere testen for at få det optimale udbytte af timerne. Teststrategi og testplaner er midlet til den gode strukturering. Test er dermed vokset fra at være spontan og uplanlagt, til at være styret og organiseret. Testens nødvendighed Accepten af fejl i software har været støt nedadgående de sidste mange år. Der accepteres i dag ikke alvorlige fejl. De kritiske og daglige funktioner skal fungere fra første færd, og kun mindre betydende fejl kan accepteres. Kendte fejl skal være dokumenterede, sammen med forslag til hvordan systemet skal bruges med skyldig hensyntagen til fejlen. En voksende del af ny software bruges direkte af kunder. Både når det er webapplikationer, betjening via telefon, eller en af de utallige andre måder, hvor den endelige bruger af systemet forudsætter, at det fungerer uden ubehagelige konsekvenser. I sådanne situationer har virksomheden, der stiller systemet til rådighed, en særlig interesse i at det fungerer uden væsentlige fejl. Dels fordi brugeren bedømmer virksomheden i forhold til systemet, men også fordi fejl kan skade virksomheden selv. Testens resultat En god test sørger for at levere et system uden væsentlige fejl, og som er velegnet til sit formål. Omkostningerne, der er forudsætningen for at nå dertil, er som oftest mindre end ved at rette fejl efter levering. Og i de tilfælde hvor det viser sig, at systemet ikke er velegnet til sit formål, er regnestykket klart til fordel for det gode testforløb. Nye kapitler denne udgave Der er kommet nye kapitler i denne udgave. Det er kapitel 9 om portaler, der er en udvidelse og erstatning af det tidligere appendiks om webtest, der var tilgængeligt på Desuden kapitel 10 om Exploratory Testing og kapitel 11 om test i forbindelse med extreme Pro- forord 11
8 gramming. Kapitel 3 er desuden udvidet betydeligt med modelbaseret test baseret på UML. Certificering Efter at ISEB certificering har været mulig i nogle år, men kun på engelsk, er den nu tilgængelig på danske. Det er muligt at blive certificeret gennem Dansk IT. Det er en tilfredsstillende udvikling. Kvikstart Hvert kapitel slutter med nogle linier om, hvordan man kan komme hurtigt i gang med emnet i praksis. De kan bruges, når handling er vigtigere end diskussion. Henvisninger En stor del af informationen om, hvad der rører sig i testverdenen, skal findes via nettet. Brug derfor venligst Den indeholder links, referencer til seminarer, artikler om test, omtale af erfagrupper, m.v. Supplerende materiale Supplerende materiale til denne bog er tilgængeligt på ved at vælge Mine bøger på forsiden og bruge de links der står umiddelbart til højre for bogens forside. Med venlig hilsen Poul Staal Vinje 12 forord
9 INDLEDNING Definitioner Formålet med test fejl udvikling Tidlig gentagbar og evig test Nytten af registreringer Nyudvikling eller systemvorvaltning Kvikstart 26 13
10 14 k a p i t e l 1
11 1.1 Definitioner Bogen bruger ofte begreberne test, fejl, rettelser, verifikation og validering. Der er ingen grund til at føje nye begreber til rækken, så vi vil i stedet se på deres historiske udvikling. Denne udvikling illustrerer samtidig nogle forskellige holdninger til test. Hvad er test Definitionen af begrebet test er ikke triviel. Den har betydning for, hvordan testen planlægges og gennemføres, og dermed har den også afgørende betydning for resultatet. En test er en proces til at sandsynliggøre, at et program eller et system fungerer korrekt. William Hetzel En test er en proces til at finde fejl. Glen Myers En test er en proces til at vurdere et program eller systems egenskaber og formåen, så det kan afgøres, om det giver et forventet resultat. William Hetzel En test er en proces til manuelt eller maskinelt at vurdere et system for at afgøre, om det opfylder specifikationerne, og hvis ikke, til at identificere differencen mellem det forventede og det aktuelle resultat. IEEE ordbog, med den gældende definition Myers definition afslører flere fejl end den første af Hetzel. Det skyldes, at mennesker normalt forsøger at løse den opgave, de bliver stillet. Ved at bruge Hetzels første definition, vil testeren kun teste systemet ud fra en specifikation over systemets forventede indhold. Testen er afsluttet, når alle dele er fundet, og det kan påvises, at de virker i henhold til specifikationen. Ved i stedet at følge Myers definition søger testeren at finde eksempler, der viser, at systemet indeholder fejl. Testen fortsætter, så længe testerne har fantasi til at påvise flere fejl. Myers påstand er, at man får, hvad man beder om. Han mener også, at holdninger er så vigtige for resultatet, at de skal bruges aktivt. Et testforløb, der ikke har i n d l e d n i n g 15
12 afsløret fejl, skal man derfor betragte som en fiasko. Når en test afslører fejl, er det glædeligt, og en tester, der finder fejl, skal belønnes. I dag ser man stadigvæk, at Hetzels første definition bliver anvendt, specielt i store og forsinkede projekter, hvor det til sidst blot handler om at påvise en given funktionalitet. Det sker ganske uanset, at der let kan påvises fejl ved at bevæge sig lidt uden for den slagne vej med hensyn til funktionalitet, ved at bruge skæve testdata eller blot trylle lidt med rækkefølgen. IEEE s formulering har sin styrke i, at den er bredere. Den taler både om specifikationer, manuel og maskinel test, og om at identificere forskelle. IEEE s definition lægger op til, at systemets indhold og egenskaber er aftalt forud for testen. Arbejdet med at klarlægge forventningerne og planlægningen af, hvordan opfyldelsen af dem testes, bliver dermed en vigtig del af specifikationen. Et godt eksempel på dette er test af brugervenlighed, hvor kriterierne for at godkende eller forkaste brugervenligheden i et system bliver en vigtig del af systemspecifikationen. Hvad er en fejl Også på dette område kan der være forskellige holdninger. Tag blot den ældste definition: En fejl er en afvigelse fra specifikationen. William Hetzel Det lyder måske umiddelbart meget fornuftigt, men overvej så denne definition: Der optræder en fejl, når software ikke opfører sig på en måde, som en bruger med rimelighed kan forvente. Glen Myers Myers åbner dermed mulighed for, at specifikationen kan være forkert ved at tage højde for brugerens forventninger. Det giver i øvrigt en naturlig anledning til at involvere brugere aktivt i testen. Det er muligt at påvise fejlfrihed, hvis et givet resultat tilsvarende kan påvises at være enten rigtigt eller forkert. Det kan for eksempel være en beregning, som skal give et bestemt resultat eller data, der skal registreres et givet sted i en tabel. På andre områder er det imidlertid 16 k a p i t e l 1
13 vanskeligere at beskrive en objektivt sand løsning. Har et skærmbillede for eksempel kun ét rigtigt udseende? Er en hjælpetekst formuleret korrekt? I disse tilfælde skal forventningerne specificeres og testen baseres på, at der er mange løsninger, som kan være rigtige set ud fra det at opfylde forventningerne. To fejl Den rette indstilling til at teste, kommer til udtryk i begrebet to fejl. Formuleringen hentyder til, at en fejl opdaget hos brugeren i virkeligheden er resultatet af to fejl. Disse kan være vidt forskellige i deres oprindelse/årsag, i omkostningerne ved at fjerne dem, og i beskrivelsen af det faktuelle indhold. Den ene fejl er den, der konkret er begået, uanset om det er en banal programmeringsfejl eller en omfattende analysefejl. Den anden fejl er, at fejlen overhovedet er sluppet ud til brugeren. Årsagerne er typisk vidt forskellige. En banal programmeringsfejl kan skyldes, at en uerfaren programmør har misforstået en detalje i programmeringssproget, og en sådan fejl kan undgås fremover ved passende undervisning. Den anden type fejl kan skyldes manglende ressourcer, eller at alle muligheder ikke er tænkt igennem. Man kan komme ud for, at den sidste type fejl i testen betegnes som en brist, snarere end som en fejl. Hvad man end vælger at kalde dem, kan fejlene kun undgås ved at gøre det bedre næste gang. De to slags fejl bør i øvrigt registreres på hver sin fejlrapport og analyseres særskilt i et eventuelt efterfølgende Post Mortem. Hvad er en rettelse En rettelse er en reparation, altså en udbedring af en skade eller mangel. Man kan vælge at være glad, hvis det er muligt at udbedre skaden ved blot at tilføje en manglende del. I de tilfælde, hvor det ikke er muligt at udføre reparationen perfekt, men hvor der bliver tale om en lap eller noget andet uholdbart, er der imidlertid grund til at være utilfreds. Denne slags reparationer forringer systemet ved at forøge kompleksiteten og dermed forhøje risikoen for nye fejl. I sidste ende forkorter det levetiden og dermed nytteværdien af investeringen. Rettelser har forskellig konsekvens afhængig af tidspunktet i forløbet. Tidlige rettelser kan ofte udføres med et vist held; men undervejs i forløbet bliver de stadigt vanskeligere at udføre elegant, og rettelser efter idriftsættelsen bliver naturligt nok påvirket både af tidspresset og i n d l e d n i n g 17
14 måske yderligere af et behov for at reparere data. Der bør altså fra alle sider udvises stor opmærksomhed for at få rettet fejl så tidligt som muligt, og det forudsætter en tilsvarende tidlig iværksættelse af test. Verifikation og validering Lad os afslutte definitionerne med de to begreber verifikation og validering, som til dagligt forkortes V&V. Verifikation er en proces til at afgøre, om en given fases produkter opfylder de krav, der er defineret i den foregående fase, om de overholder gældende standarder, og at produkterne er fremstillet på den rigtige måde. Validering er en proces til at vurdere om en given software er i overensstemmelse med kravspecifikationen. V&V anvendes hånd i hånd for at sikre, at det rigtige produkt bliver fremstillet på den rigtige måde. Det er imidlertid værd at skelne mellem de to begreber for at sikre sig, at begge dele tænkes ordentligt igennem. Eksempler på verifikation Kontrakten eller kravspecifikationen skal verificeres med hensyn til struktur og følge vedtagne standarder. Verifikationen omfatter også kontrol af, at de forretningsmæssige mål er 100 % forstået af udviklerne, og at projektlederen kontrollerer, at målene kan opfyldes inden for budgettet. Hvis man vil have en opskrift på, hvordan det gøres, kan man bruge et kontraktreview med det indhold, der er defineret i standarden ISO En testspecifikation kan verificeres med hensyn til sin struktur og med, at indholdet af hvert afsnit er helt og fuldt forstået. Funktions- og datamodeller skal verificeres med hensyn til, om de fuldstændig afspejler kravspecifikationen. Designerne skal kunne afgøre, om der mangler eller er tilføjet noget. Desuden skal verifikationen benyttes til at afgøre, om modellerne er opbygget efter gældende standarder, for eksempel at datamodeller er korrekte som datamodeller betragtet. Konstruktører og designere skal verificere, at koden er en korrekt afbildning af design og specifikationer, og at koden er skrevet efter gældende standarder. Skærmbilleder skal verificeres imod en standard. Verifikation er ganske enkelt vigtig hele vejen igennem. Det er afgørende både at få en teknisk korrekt objektmodel og at få fremstillet de 18 k a p i t e l 1
15 fysiske komponenter i en kvalitet, der gør dem lette at vedligeholde. Eksempler på validering Brugere og/eller opdragsgivere skal validere, at kravspecifikationen omfatter de rigtige forretningsmæssige mål. Det er samtidig en god mulighed for at involvere brugere tidligt i processen. Senere valideres de funktioner og data, der er resultatet af systemanalysen. Frem til dette punkt i et testforløb går valideringen dog som regel ret smertefrit, fordi både brugere og købere kan læse og forstå de produkter, som de validerer. Prototyper har til formål at validere specifikationen og analysen, før designet begynder. Det er af mindre betydning for testeren, om prototyperne derefter kan bruges i det videre arbejde eller blot skal smides væk. Den store gevinst ligger i, at systemet allerede på et tidligt tidspunkt er valideret. Validering er specielt vigtig i begyndelsen af et forløb. Hvis valideringen er vellykket dér, betyder det, at systemet er grundlæggende rigtigt, og at det bliver let at rette op på småfejl senere. Validering af designet kan give problemer. Det kan være svært at afgøre, om moduldesign og databaser giver den funktionalitet, som er aftalt. Valideringen foregår ofte indirekte ved at brugere opstiller nogle eksempler på forretningsmæssig brug, og at disse eksempler tænkes igennem sammen med designerne som en walk-through på overordnet niveau. Valideringen af det færdige fysiske system kan have forskellig sværhedsgrad. Skærmbilleder kan for eksempel blot valideres for, om de indeholder de rette data og giver den forventede funktionalitet. Validering af det færdige system sker som en traditionel sluttest med en maskinel system- og brugertest. Fælder Det er let at falde i den fælde kun at sørge for de lette dele i et V&V-forløb. Det er derfor nødvendigt i sin testplanlægning at afgøre hvilke dele, der er nødvendige. Hvis nogle dele er besværligere at gennemføre end andre, må man starte med den detaljerede planlægning af netop dem. Når man taler om en tidlig test, er det som regel validering, man ønsker, men det kan let ende med, at det er en verifikation, der bliver gennemført. F.eks. er en datamodel ikke valideret, blot fordi den er reviewet af IT-folk. Hvis det er brugere, der udfører valideringen, kan man argumentere for at den er foretaget, hvis de til fulde kan afgøre, om da- i n d l e d n i n g 19
16 tamodellen opfylder kontrakten og kravspecifikationen. Validering af datamodeller er dog ofte tidkrævende og problematisk. Man må ikke springe over verifikation af konstruktionen. Programmerne skal leve op til den vedtagne standard. Det kan afgøres af andre konstruktører, eller ved hjælp af et værktøj. Det kan ikke ske ved hjælp af brugere, som validerer ved hjælp af walk-throughs. 1.2 Formålet med test Det overordnede mål er at levere et fejlfrit system til kunden til de lavest mulige omkostninger, herunder med færrest mulige reparationer, fordi reparationer påvirker de samlede levetidsomkostninger. Et velplanlagt testforløb har dog flere mål og søger at opnå flere fordele. Her er nogle af de væsentligste. 1. Fejl begås ikke/færre fejl. 2. Fejl opdages og korrigeres så tidligt som muligt. 3. Risici, omkostninger og tidsfrister er som forventet. 4. Systemets kvalitet og pålidelighed er optimal. 5. Ledelsen får bedre mulighed for at følge arbejdet. 6. Konsekvensen af ændringsønsker kan hurtigt vurderes. 7. Forvaltningsomkostningerne reduceres. De fleste af målene er hentet fra IEEE s standarder for test, men listen kan let udvides. Andre mål kunne for eksempel være, at udviklerne selv fik bedre styr på processen, og at vedtagne standarder i virksomheden blev overholdt. Men først lidt mere om de enkelte punkter. 1. Fejl begås ikke/færre fejl Hvis dette mål kan realiseres, er der selvsagt opnået meget. Det er enklest, hvis man helt kan undgå fejl. For at opnå dette mål er der brug for at teste, og det kræver testere, der har dette som deres eneste opgave. I praksis kan det opnås ad mange forskellige veje, hvoraf nogle tilmed er gratis. En af vejene er at fremrykke det tidspunkt, hvor man skriver testdata. Hvis vi antager, at brugerne skriver testdata til en brugertest før designet, eller i det mindste før konstruktionen, er disse testdata tilgængelige for udviklerne, hvilket giver færre fejl og hurtigere udvikling. Det 20 k a p i t e l 1
17 er ikke en mirakelmedicin; men det er et eksempel på, at der med samme indsats af ressourcer kan opnås bedre resultater. 2. Fejl opdages og korrigeres så tidligt som muligt Omkostningerne til test er direkte afledt af den tid der går, mellem en fejl begås, og til den findes og rettes. Hvis en fejl begås i analysefasen, men først opdages og rettes i designfasen, er de samlede omkostninger omtrent dobbelt så store, som hvis fejlen var blevet fundet og rettet i analysefasen. Hvis en fejl, der begås i analysefasen, ikke findes og rettes før modultesten, er de samlede omkostninger omkring ti gange så store, som hvis fejlen var blevet fundet med det samme. 3. Risici, omkostninger og tidsfrister er som forventet Der kan være mange grunde til, at udviklingsarbejde forsinkes og fordyres i forhold til det forventede. En meget almindelig grund er, at der ikke er afsat tilstrækkelig tid og ressourcer til test. Gennemførelse af testen vil da i sig selv opleves som en forsinkelse. Værre bliver det, hvis man ser på den tid, der afsættes til fejlretning og fornyet test. Det kan ofte virke, som om man planlægger ud fra den forudsætning, at systemerne fra begyndelsen er fejlfri - eller i det mindste 98 % i orden. Det kan dog være tilfældet, hvis der er aktiviteter, som sikrer 0-fejl udvikling. Et ordentligt planlagt og velgennemført testforløb kan bidrage til, at det samlede udviklingsforløb kan afsluttes til tiden, og med det forventede resultat - både med hensyn til kvalitet og pris. 4. Systemets kvalitet og pålidelighed er optimal Testen skal medvirke til at opnå både kvalitet og pålidelighed. Hvis de penge, der afsættes til test, alene bruges på at rette fejl og/eller til at justere det færdige produkt, er testen ikke med til at skabe merværdi. Bedre systemer er en markant sidegevinst ved at teste bedre. For at opnå testbare systemer skal systemerne opbygges bedre, enklere og mere pålideligt. Alene dét, at der arbejdes aktivt med test gennem hele udviklingsforløbet, gør udviklerne mere opmærksomme på kvaliteten af både deres egen arbejdsindsats og af deres produkter. 5. Ledelsen får bedre mulighed for at følge arbejdet Der er behov for at følge op både på udviklingsarbejdets fremdrift og på dets færdiggørelsesgrad. Så længe et produkt ikke er testet, kan man i n d l e d n i n g 21
18 kun følge op på hvor langt udviklingen er nået. Først når testen er gennemført, kan man måle en egentlig færdiggørelsesgrad. Testen sørger for, at man ikke alene kan måle, hvor meget der er produceret, men også hvor godt det er. Hvis ledelsen skal have mulighed for at gribe ind med produktivitetsfremmende foranstaltninger, kan man derfor ikke nøjes med en traditionel test ved afslutningen af projektet. Råderum og reaktionsmuligheder er blevet for små på dette tidspunkt. Man kan dog diskutere, om testen skal bruges til ledelsesformål. Nogle vil hævde, at det er at misbruge i stedet for at bruge testen, og at der er tale om kontrol i negativ betydning. Imidlertid er systemer ikke udviklernes private ejendom. Derfor bør testen også anvendes til at få kendsgerningerne på bordet, så man kan få et objektivt grundlag at lede ud fra. 6. Konsekvensen af ændringsønsker kan hurtigt vurderes Hvis det er et krav, at der skal tages hensyn til ændringer, stiger behovet for at gentage tidligere test. Der bliver også behov for at estimere hvor megen test, der vil være nødvendig at gentage. Det er mest indlysende, hvis opgaven allerede er nået til konstruktionsfasen. Efter gennemførelse af en ændring er der behov for at teste, om resten af systemet stadigvæk opfører sig korrekt, eller om ændringen har givet uventede konsekvenser eller bivirkninger. Der er imidlertid et lige så stort behov for test af ændringer, hvis de optræder i de andre faser, selv hvis arbejdet kun er nået til foranalyse- eller analysestadiet. Et færdigt design, der ændres, skal helt eller delvist gennemgå en ny test. Forudsætningen for, at man let og pålideligt kan estimere de testmæssige konsekvenser af en ændring, er, at der findes en formel testplan. Jo bedre testen er planlagt, jo hurtigere vil konsekvenserne kunne beregnes. 7. Forvaltningsomkostningerne reduceres Systemet bliver lettere at vedligeholde, hvis det er testbart og forvaltningsegnet. De forhold, der gør det muligt at teste et system, er de samme, som gør det lettere at vedligeholde i løbet af dets levetid. Produktiviteten ved vedligeholdelse udtrykkes som mængden af Function Points, der kan vedligeholdes løbende per år per hele forvaltningsressource. Testbare systemer og et fuldstændigt testmiljø øger produktiviteten for vedligeholdelse. Der opnås en gevinst hver gang systemet skal ændres, og det er realistisk at regne med en gennemsnitlig reduktion af de samlede forvaltningsomkostninger i løbet af levetiden på op til 30 %. 22 k a p i t e l 1
19 1.3 0-fejl udvikling Mon ikke alle kan enes om, at det ville være rart med fejlfri produkter og få en fast procedure for udvikling af produkter uden fejl, såkaldt zero-defect development. Den almindelige holdning er vel, at det godt vil kunne lade sig gøre men at det også skal stå mål med omkostningerne og dermed underforstået, at det er dyrt at undgå fejl. Det er imidlertid helt forkert. Det er langt dyrere at finde og reparere fejl, end det er at undgå dem, men det er svært at diskutere emnet generelt, så hver enkelt virksomhed må undersøge de opståede fejl og vurdere, om det ikke ville have været billigere at undgå end udbedre. Det skal så søges gjort fremover, fordi det at gentage fejl, som ville være billigere helt at undgå, er en fejl på et mere overordnet niveau. Det er nemlig en fejl i organisationens måde at lære på. Men hvad er så 0-fejl udvikling? Og hvad vil det sige at levere et fejlfrit produkt? Er de to ting det samme? Nej, de er ikke det samme. Lad os tage et eksempel med et mødereferat, som vil være et fejlfrit produkt, hvis alle modtagere er enige i indholdet, og der ikke er stavefejl. Alligevel kan der godt være begået fejl undervejs. Der kan være tastet og stavet forkert, men det er blot blevet rettet. Nogle rettelser er blevet udført med det samme af den, der har tastet, mens andre er blevet rettet ved en efterfølgende korrekturlæsning. Der kan for eksempel være mailet et udkast til mødelederen eller til en af deltagerne for at kontrollere, om indholdet kan accepteres. Alt i alt kan der altså være foretaget mange rettelser og brugt megen tid på at få referatet fejlfrit. Der kan tilmed være brugt mere tid, end det er økonomisk forsvarligt, for at få det fejlfrit. Men det er fejlfrit. Den anden mulighed er at benytte sig af 0-fejl udvikling, hvor det handler om at få det rigtigt første gang. For eksempel ved at spørge, hvis der er noget, man er usikker på; ved at referenten skriver referatet under mødet; ved at konkludere åbent, før der sættes noget på prent og ved at lade deltagerne høre det foreløbige resultat, før mødet afsluttes. I efterproduktionen kan der også gøres meget. Hele referatet kan disponeres, før detaljerne kommer på plads og sætninger kan formuleres færdigt i hovedet, før de skrives. Alt sammen sker det for at undgå at begå fejl, og hvis man er utålmodig, synes man formentlig, at denne fremgangsmåde tager for lang tid. Men spørgsmålet er faktisk, om det er tidsspilde. i n d l e d n i n g 23
20 Det er let at fremstille fejlfri produkter, for det er kun et spørgsmål om at bruge den nødvendige tid og tilstrækkeligt mange penge. Det er ulige sværere at undgå fejl. Begrebet test i denne bog omfatter altså både at finde fejl, og helt at undgå at begå dem. I eksemplet med mødereferatet blev slutresultatet det samme, nemlig et fejlfrit produkt; men man skal bestemme sig på forhånd, hvis det skal ske i en fejlfri proces. Specielt skal man være sikker på, at der er tid til at rette fejl, hvis det er blevet strategien, så der ikke bliver tale om her-og-nu reparationer. Hvis der ikke er tid til at undgå fejl, er der vel ret beset heller ikke tid til at rette dem. 1.4 Tidlig, gentagbar og evig test Disse begreber kan ikke defineres entydigt. Det er mere tale om strategier, der benyttes for at opnå succes sammenlignet med investeringen. Normalt forstår man det, som fremgår af det følgende, når man benytter dem. Tidlig test udføres på projektets mellemresultater. Desuden omfatter begrebet tidlig planlægning af den maskinelle test, og fremstilling af testmateriale. For kodningens vedkommende er der bred enighed om, at testdata bør skrives før de programmer, som de skal teste. Det samme synspunkt er ved at vinde frem for andre produkters vedkommende. Tidlig test kræver ofte en revision af den udviklingsmodel, som organisationen anvender. En svaghed ved mange af de eksisterende modeller er nemlig, at test beskrives som en afgrænset fase, der er placeret sidst i forløbet. Testen af et produkt kan starte samtidig med udviklingen ved at være aktiv allerede i specifikationsfasen, mens man endnu diskuterer, hvad systemet skal kunne. Testen kræver planlægning, og det er en vigtig del af den præventive test, at testdata udarbejdes før udviklingen af dét, der skal testes med dem. Derfor må vi allerede nu kundgøre vores tro på, at: En test, der begynder direkte på maskinen, er som at programmere uden forudgående analyse og design. Gentagbar test er også en fornuftig metode. En god test er en test, der kan gentages 100 %. Det er en hjælp i udviklingsprojekterne, og er des- 24 k a p i t e l 1
21 uden på det nærmeste en kritisk faktor for succes i forvaltningsarbejdet. Det forudsætter værktøjer, der kan køre alle test automatisk med maskinel sammenligning af uddata, skærmbilleder og så videre. Evig test er vejen frem til stabile systemer. Det indebærer, at et system testes jævnligt i hele sin levetid. Ganske uanset om der er ændret i programmerne eller ej, kan omverdenen og de øvrige systemer have forandret sig. Forhold, der måske ikke var kritiske, da systemet blev sat i drift, kan være blevet afgørende senere. Ved jævnlig test, hvor man anvender både de oprindelige testcases og tilføjer nye på kritiske områder, kan man forebygge mange fejl og undgå megen brandslukning. 1.5 Nytten af registreringer Naturligvis er det primære formål med at finde fejl, at de bliver rettet. Men ved desuden at registrere det, der sker undervejs, kan der opnås flere fordele. Her er eksempler på nogle få faktorer. Det akkumulerede antal fundne fejl i et projektforløb kan registreres og afbildes i forhold til antallet af gennemførte testcases eller i forhold til den tid, der bruges på test. Kurven skal meget gerne flade markant ud som tegn på, at der efterhånden findes færre fejl. Sker det ikke, er det tegn på, at systemet er alvorlig sygt - og det vil ikke hjælpe bare at teste videre. Det er også en vigtig oplysning hvor fejlene optræder. Den samlede mængde fejl vil sjældent være jævnt fordelt. Størsteparten vil samles omkring design holes det vil sige moduler eller dele af systemet, der ikke er tænkt 100 % til bunds i løbet af udviklingsarbejdet. Indsatsen kan optimeres ved at identificere design holes tidligt, og det vil ofte bedst kunne betale sig at udvikle de berørte dele forfra. Det er ligeledes formålstjenligt at foretage registrering af First Passes, altså at testeren beregner hvor stor en del af testdata, der går rigtigt igennem i første forsøg. Områder med lav First-Pass godkendelsesrate er ensbetydende med mange rettelser og øger sandsynligheden for flere fejl senere. Omvendt vil områder med høj»first Pass«give færrest problemer senere. En analyse og registrering af fejlkilder kan bruges både i det aktu- i n d l e d n i n g 25
22 elle testforløb og af organisationen generelt. Når en fejlkilde er identificeret, bliver det nemmere at finde samme type fejl i andre systemer. 1.6 Nyudvikling eller systemforvaltning Uanset hvor lille en opgave er, vil der altid være brug for at overveje alle aspekter af test. Men jo mindre opgaven er, jo mere skal der vælges fra. Det drejer sig ikke om bestemte dele, så man kan ikke bygge sig en lille generel testmodel for små opgaver, og en udvidet model for større. Alle aspekter skal overvejes og vælge fra eller til for hver opgave. Et nyt udviklingsprojekt indebærer mange aspekter af test, mens billedet er mere broget for forvaltningsopgaver. Opgaven kan både være lettere og sværere, fordi man er meget afhængig af, hvad der er sket tidligere. Hvis principperne for aktiv systemforvaltning har været overholdt, vil der findes et testsystem. Hvis der kun har været udført passiv vedligeholdelse, kan der være dele af testen, som må falde bort, fordi en enkelt opgave ikke tidsmæssigt og økonomisk kan bære at etablere det manglende testsystem. Derfor er det bedst at samle et antal mindre opgaver sammen og etablere testfaciliteter som en del af opgaven. 1.7 Kvikstart Vedtag at test er en investering og ikke blot en omkostning. Beslut formålet med testen, offentliggør det, og mål løbende under testforløbene hvordan det går. 26 k a p i t e l 1
23 TESTENS FASER Indledning Komponenttest Integrationstest Systemtest Brugertest Alfatest Betatest Accepttest De grundlæggende teststrategier Kvikstart 109 t e s t e n s f a s e r 27
24 28 k a p i t e l 1
25 2.1 Indledning Et testforløb bygger på disse testfaser: Komponenttest Integrationstest Systemtest (funktionstest) Brugertest Alfatest Betatest Accepttest Komponenttesten finder fejl i de enkelte programmer; men kan imidlertid ikke finde alle tværgående fejl, fordi den tester hver komponent for sig. Alle programmeringsfejl kan imidlertid findes og rettes. Integrationstesten finder fejl i grænsefladerne mellem komponenterne og i grænsefladerne til andre systemer. Systemtesten skal vise, at hver funktion er til stede og fungerer. Systemtest går også under navnet funktionstest. Brugertesten tester, hvordan systemet opfører sig, når det bruges i forhold til scenarier og brugsrelevante hændelsesforløb. Alfatesten viser, hvordan systemet opfører sig i virkeligt brug. Et udvalg af virkelighedens scenarier afprøves i stabilt testmiljø, ofte i leverandørens organisation og driftsmiljø. Betatesten viser, hvordan systemet opfører sig i virkelig brug. Nogle udvalgte brugere anvender systemet i deres daglige arbejde. Accepttesten er en endelig godkendelse af systemet til generelt brug. I et udviklingsprojekt vil alle testfaser blive brugt. I et integrationsprojekt er det måske kun integrations- og accepttest, der er brug for, og også for andre typer af opgaver kan man vælge de testfaser, der er brug for. Ved køb af et standardsystem vil testen begynde med en brugertest, t e s t e n s f a s e r 29
26 fulgt op med en omfattende og længerevarende alfatest, og til sidst en omfattende og længerevarende betatest. Teststrategier Dette kapitel gennemgår indholdet af testfaserne uden at tage stilling til teststrategien. Den kan være et traditionelt forløb med testen placeret sidst, en mere offensiv V-model med tidlig planlægning, eller endda en radikal 0-fejl model med både tidlig planlægning og gennemførelse. Hvis dette kapitel læses uden særlige tanker om strategien, kan det virke, som om der lægges op til et traditionelt forløb. Det skal imidlertid ikke forstås anderledes, end at faserne beskrives i den rækkefølge, der er mest kendt, og med planlægning og gennemførelse umiddelbart efter hinanden. Sidst i kapitlet beskrives de tre hovedstrategier. Figur 2.1 viser et traditionelt testforløb. I hver udviklingsfase fremstilles nogle produkter, der er grundlag for den næste fase. I testfaserne fremstilles der ligeledes et produkt i form af et stedse mere testet system. Hver testfase skal planlægges og gennemføres. Planlægning betyder med jævne ord blot, at testen skrives ned, før den udføres. Man beskriver det ønskede forløb, og man dokumenterer de testdata, der skal bruges. I dagligdags testforløb kan man lægge mere eller mindre vægt på planlægning i forhold til gennemførelse. Ambitionsniveauet i hver af disse to hovedaktiviteter varierer ligeledes. Hvis testen overhovedet ikke planlægges, men kun gennemføres, betyder det, at testeren skal hitte på relevante testforløb og -data undervejs ved gennemførelsen. Hvis alt derimod planlægges og dokumenteres (inklusive alle testdata), er der ikke behov for testere til gennemførelsen som andet end ressourcer til at udføre det planlagte, og sammenligne med det dokumenteret forventede resultat. Testens dækning En testfase afsluttes, når den ønskede dækning er nået. Dækningen defineres forskelligt for hver testfase. I komponenttesten skal der dækkes en fastsat mængde af de mulige veje i komponenten. Integrationstesten skal opnå den fastsatte dækning af kald og variationerne i kald. I systemtesten skal der opnås en givet dækning af funktioner. Brugertesten skal dække brugssituationer, og accepttesten skal dække alle de definerede kriterier for accept. 30 k a p i t e l 2
27 Processen Produktet der udvikles Testprocessen Foranalyse Kravspecifi kation Analyse Løsning: Data og funktioner Design Udformning af systemets data, programmer og udseende Konstruktion Kode i programmer og skærmbilleder Komponenttest Dækning af kode i programmer og skærmbilleder Integrationstest Test af grænsefl ader Systemtest System Test af funktioner og data Brugertest System Test af scenarier og brugsrelevante forløb Alfa- og betatest System Test med virkelige scenarier og/eller virkelig brug Accepttest System Godkendelse til igangsætning Figur 2.1: Testfaserne t e s t e n s f a s e r 31
28 I tilfælde hvor der ikke er tid til at dække alt, eller i tilfælde som brugertesten, hvor der i princippet er et uendeligt antal mulige test, skal der suppleres med, at det er den kritiske dækning, der skal opnås. En dækning på 60 % kan være i orden, hvis det er netop de 60 % der betyder, at der ikke kan ske fejl af betydning. Et testforløb kan ende med en godkendt dækning som denne: Komponenttesten: 70 % af vejene Integrationstesten: 100 % af grænsefladerne og 80 % af de mulige dataværdier i kaldene Systemtesten: 100 % af funktionerne Brugertesten: 100 % af de scenarier, der omfatter kritiske funktioner, og 60 % af de øvrige Testens effektivitet Man kan betragte en testfase som et filter. Hver fase opfanger flere eller færre fejl, afhængigt af hvor meget der gøres ud af testen. Man skal gøre sig klart, at en given testfase kun finder bestemte typer fejl. For eksempel finder integrationstesten fejl i grænseflader, men ikke i funktionaliteten som en systemtest til gengæld gør. En fases effektivitet måles som den procentdel af fejlene, den finder. Det kendes i testverdenen som test efficiency, og hvis målet er 70 % betyder det, at man ønsker at finde 70 % af de fejl, der er i produktet, når testfasen starter. Ved at lade hver testfase finde 70 % af de fejl der er tilbage, nås frem til, at der kan releases med kun få resterende fejl. Man kan selvsagt ikke måle hvor mange af den samlede mængde fejl, man har fundet. Man kender først de resterende fejl efter idriftsættelse, men der skal alligevel arbejdes med procesforbedring på dette grundlag, selvom resultatet påvises med en vis forsinkelse. Aktiviteterne i planlægning og gennemførelse De to hovedaktiviteter, planlægning og gennemførelse af test, kan deles op i mindre aktiviteter. Planlægning af en testfase: Udpeg testere til planlægning af testfasen Opstil mål for dækningen Opdel testfasen i testaktiviteter, og beskriv hver aktivitet 32 k a p i t e l 2
29 Opstil detailplan for fasen ved hjælp af testaktiviteterne Udarbejd testcases for hver testaktivitet Gennemførelse af en testfase: Udpeg testere til gennemførelse af testfasen Vælg fra detailplanen hvad der kan og skal testes Gruppér eventuelt flere testaktiviteter til en testsession Opsæt testmiljøet Fremfind testcases til den eller de valgte testaktiviteter Gennemfør testcases, det vil sige indtastning eller igangsætning af job Sammenlign med det forventede resultat Skriv nye fejlrapporter Opdater de gamle fejlrapporter, der indgår i testsessionen Opdater fejlloggen/testloggen Skriv en samlet statusrapport med aftalte mellemrum Metoder, værktøjer og teknikker Testen kan i høj grad have nytte af værktøjer. Før man påbegynder en fase, skal der tages stilling til både metoder, værktøjer og teknikker. I den følgende gennemgang af hver testfase nævnes de væsentligste muligheder. Dokumentationsstandarden Bogens kapitel Planlægning og styring indeholder beskrivelser af de dokumenter, der refereres til i dette kapitel. Det gælder for eksempel detailplan, testaktivitet, testlog og så videre. Der er eksempler på brugen af dem i dette kapitel. Niveauer i prioritering Når der i teksten refereres til kritiske funktioner eller kritiske systemer, er der tænkt på denne opdeling i niveauer efter vigtighed: Niveau 1: Life-critical systemer Kan skade mennesker i betydelig grad i tilfælde af fejl. Niveau 2: Mission-Critical systemer Styrer irreversible processer, for eksempel produktionen på en fabrik, t e s t e n s f a s e r 33
30 der i sagens natur ikke kan gøres om. Niveau 3: MIS (Management Information Systems) Eller på jævnt dansk administrative systemer, hvor der i princippet kan rettes op på resultatet af brugen ved at foretage en omkørsel til en billig, eller i hvert fald acceptabel, pris. Niveau 4: List systemer Producerer information på serviceniveau, hvor fejlen ikke går videre i andre systemer. Risikoprofil og risikopoint I stedet for niveauer kan man anvende en formel model for risikoanalyse. Resultatet af analysen er en række mulige risici, der hver får point for sandsynlighed og konsekvens. Sandsynligheden defineres ofte således: 1= Der vil sandsynligvis ikke opstå problemer, men det er dog muligt 2= Det er lige så sandsynligt, at det sker, som at det ikke gør 3= Der vil sandsynligvis opstå problemer Konsekvens defineres ofte således: 1 = Konsekvensen kan opsuges med planens nuværende aktiviteter 3 = Der skal gøres noget for at afbøde konsekvensen 10 = Planen skrider, hvis dette sker Risikopointene kan nu regnes ud som sandsynlighed gange konsekvens. Se mere i Projektledelse af systemudvikling, jf. litteraturlisten. Det højeste antal point er således 30; men det er fornuftigt med en regel om at interessere sig for tocifrede risikopoint. 2.2 Komponenttest Formål Formålet er at teste hver komponent. Komponenten skal dækkes så grundigt i testen, at den både opfører sig som forventet, og er stabil i de efterfølgende testfaser. 34 k a p i t e l 2
31 Det handler om koden i programmer på mainframe og servere. Der kan desuden ligge kode i skærmbillederne på en eventuel klient. Det sidste er ofte tilfældet, når der udvikles med Visual C++, C# og Visual Basic i.net komponenter, Delphi, eller lignende. Komponenterne består primært af kode; men data testes også i en komponenttest, da brugen af dem indgår i hver test. I figur 2.1 er komponenterne resultatet af udviklernes arbejde i konstruktionsfasen. Tidligere kaldtes komponenttesten for programtest, og den blev som oftest udført ved at lade programmørerne selv teste. Komponenttesten var dermed en integreret og underforstået del af udviklingsarbejdet. I et moderne testforløb tages der mere bevidst stilling til, hvor formelt komponenttesten skal planlægges og gennemføres. Der tages også bevidst stilling til, hvem der skal være den ansvarlige tester. Komponenter med indhold, der er life critical eller mission critical, skal testes af andre end konstruktøren. Figur 2.2 (se næste side) viser elementerne i komponenttesten. Figuren viser en række komponenter, der indgår i testen; men det skal forstås, som at det typisk sker for en enkelt eller nogle få komponenter ad gangen. Komponenttesten skal sørge for, at koden prøves af. Det handler om at opnå en høj dækning af de fysiske veje i komponenterne. Jo flere veje i koden, jo mere omfattende bliver komponenttesten. Komponenttestens mulige omfang måles altså ikke i funktioner, men i veje (stier). En varieret komponenttest øger til stadighed dækningen af vejene. Kært barn har i øvrigt mange navne: programtest, modultest, unittest, komponenttest - det er alt sammen betegnelser for det samme. Planlægning af komponenttesten Udpeg testere til planlægning af komponenttesten Lad os slå fast med det samme: det er ikke en naturlov, at komponenttestens indhold planlægges af udvikleren selv, således som det har været reglen før i tiden. Der er brug for en mere nuanceret opfattelse. Rent teknisk-fagligt er der intet i vejen for, at planlægningen kan foretages af andre end konstruktøren. Hvis den skal planlægges som en whitebox-test, med krav om at nå en specifik dækning af veje, skal testeren blot have tilsvarende tekniske færdigheder. Der er brug for en konstruktør, der kan læse koden. Hvis testen planlægges som en blackboxtest, hvor der blot er krav om, at programmet i sin helhed opfører sig t e s t e n s f a s e r 35
32 Testere med teknisk indsigt Krav til komponenten Detailplan Fx. Gantt-skema Teknikker: Whitebox Værktøjer: statisk analyse dynamisk analyse Testaktivitet pr komponent Komponenter med kode Testcases Kode Komponenttest testmiljø Fejlrapporert Fejllog Testrapport med dækning af koden Figur 2.2: Elementerne i en komponenttest 36 k a p i t e l 2
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 mereOm 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 mereProcedure for systemtest
LANDBRUGS- OG FISKERISTYRELSEN Procedure for systemtest Retningslinjer for hvordan test udføres i LFST Kontrakt om Testressourcer Underbilag 1c 23. oktober 2017 Version 1.0 En beskrivelse af hvordan test
Læs mereHoldninger. Appendiks til bogen Struktureret Test
Holdninger Appendiks til bogen Struktureret Test Holdninger... 1 Appendiks til bogen Struktureret Test... 1 1. Holdningers betydning... 2 2. Holdninger generelt, der fremmer test... 2 3. De enkelte aktører...
Læs mere0-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 mereKontrakt om Videreudvikling, Vedligeholdelse og Support af IMK2- systemet
Kontrakt om Videreudvikling, Vedligeholdelse og Support af IMK2- systemet Bilag 8 Test 12.05.2016 Version 1.0 [Vejledning til tilbudsgiver: Bilaget er i sin helhed at betragte som et mindstekrav (MK).
Læs mereUnderbilag 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 mereBias 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 mereKontrakt om Testressourcer. Bilag 1a - Situationsbeskrivelse. 23. oktober Version 1.0
Kontrakt om Testressourcer Bilag 1a - Situationsbeskrivelse 23. oktober 2017 Version 1.0 [Vejledning til tilbudsgiver: Leverandøren skal ikke besvare dette bilag og anmodes om ikke at ændre i bilaget eller
Læs mereAgil-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 mereIdé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 mereVurdering af kvalitet en note af Tove Zöga Larsen
Vurdering af kvalitet en note af Tove Zöga Larsen Kvalitet... 2 Test... 2 Hvordan finder man testdata?... 2 Dokumentation af test... 3 Review... 3 Vurderingskriterier... 3 Gennemførelsen af et review...
Læs mereCase til opgaven: Evaluering som belutningsmodel for forandring. Case til opgaven: Evaluering som beslutningsmodel for forandring.
Case til opgaven: Evaluering som beslutningsmodel for forandring. Palle Ragn 1/6 Introduktion til casen Casen beskriver et forløb for implementering af et system for en af Stibo s kunder. Efter casen har
Læs mereSecure 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 merePlan for præsentationen
Rejsen på vej til Test Drevet Udvikling i Uddannelses- og Forskningsministeriet Præsenteret af Klaus Olsen Willy Kofoed kontorchef i Uddannelses- og Forskningsministeriet Kenneth B Andersen IT Minds På
Læs mereInfoblad. 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 mereLEVERANCE 1.3. Model for kvalitetssikring
LEVERANCE 1.3 Model for kvalitetssikring Udarbejdelse af kvalitetssikringsmodel, krav til open source kode og dokumentation og godkendelsesprocedurer m.v. Samt fokus på understøttelse af CE-mærkning. 1
Læs mereCV 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 mereStatistisk 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 mereTestprocesser 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 mereFind det rigtige, hurtigere og billigere ved hjælp af prototyper
GRANYON WHITE PAPERS: PROTOTYPING Find det rigtige, hurtigere og billigere ved hjælp af prototyper Prototyper i forskellig udformning gør det muligt at afprøve og teste den e-handels løsning, webside,
Læs mereDE 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 mereHassansalem.dk/delpin User: admin Pass: admin BACKEND
Hassansalem.dk/delpin User: admin Pass: admin BACKEND 1/10 Indledning Dette projekt er den afsluttende del af web udvikling studiet på Erhvervs Lillebælt 1. semester. Projektet er udarbejdet med Del-pin
Læs mereIndholdsfortegnelse Afprøvning af Leverancen Fællesregler for afprøvning Fejl! Bogmærke er ikke defineret. Installationsprøve Delleveranceprøve
Bilag 11 Prøver Indholdsfortegnelse 1. Afprøvning af Leverancen 3 2. Fællesregler for afprøvning 3 2.1 Prøvens gennemførelse 3 2.2 Prøveplan 3 2.3 Rapportering 4 2.4 Godkendelse af en prøve 4 2.5 Leverandørens
Læs mere10 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 mereBilag 2 - UDKAST - Cover
Bilag 2 - UDKAST - Cover 15. september 2016 BRAHA Revideret plan for test og idriftsættelse af GD1 og GD2 Problem Der er behov for en ny tidsplan for test, implementering og idriftsættelse af GD1 og GD2.
Læs mereSuccesfuld 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 mereVærktøj 2 - Milepælsplan
Værktøj 2 - Milepælsplan Formål Ved at udarbejde en milepælsplan for projektet deles projektet op i mindre og mere håndterbare bidder. Formålet er bl.a. at sikre, at de leverancer og delleverancer, som
Læs mere7. Referencer til andre værktøjer. 8. Sammenhæng med internationale standarder. 9. Referencer til Projektledelse Teori og praksis. 10.
Projektlederens værktøj 7. Referencer til andre værktøjer Nr. Navn Sammenhæng med Kritisk sti (CPM) 4.3.3 Tidsplan Udarbejdelse af tidsplan er forudsætningen for at kritisk sti kan findes 4.4.2 Successiv
Læs mereBILAG 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 mereOmfang af beføjelser til at træffe beslutninger (for eksempel anbefaling eller implementering)
Skema til brug ved oprettelse af et team Formålet med teamet Forventede aktiviteter Tilsigtede resultater Tilgængelige ressourcer Begrænsninger Nødvendige færdigheder og kvaliteter Forventede teammedlemmer
Læs mereDrejebog for tilslutningsprøve OIO sag
Drejebog for tilslutningsprøve OIO sag Indholdsfortegnelse Ændringer i forhold til forrige version... 3 1 Indledning... 4 1.1 Formål med drejebogen... 4 1.2 Mål med tilslutningsprøven... 4 2 Overordnet
Læs mereArtikler
1 af 5 09/06/2017 13.47 Artikler 26 artikler. persontilstand Generel definition: tilstand hos en person, der vurderes i forbindelse med en indsats Persontilstanden vurderes og beskrives ud fra den eller
Læs merePrø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 mereFormål. Brug. Fremgangsmåde
Værktøj 5.1 Milepælsplanen Formål Ved at udarbejde en milepælsplan for projektet, deles projektet op i mindre og mere håndterbare bidder. Formålet er bl.a. at sikre, at de mellem- og slutresultater, som
Læs mereBilag 16. Den Iterative Model. Til Kontrakt. Den Nationale Henvisningsformidling
Bilag 16 Den terative Model Til Kontrakt OM Den Nationale Henvisningsformidling Bilag 16 Den terative Model Side 1/9 NSTRUKTON TL TLBUDSGVER: Teksten i dette afsnit er ikke en del af Kontrakten og vil
Læs mereKvartalsrapport vedr. fase 1 af SKATs systemmodernisering for 1. kvartal 2008
Skatteudvalget (2. samling) SAU alm. del - Bilag 195 Offentligt Notat Hovedcentret Strategi og Udvikling Projektkontoret 13. juni J. nr. 08-048898 Kvartalsrapport vedr. fase 1 af SKATs systemmodernisering
Læs mereBilag 10. Afprøvning
Bilag 10 Afprøvning 2 Vejledning til tilbudsgiver Dette bilag beskriver, hvordan Leverancer og videreudviklingsydelser skal afprøves af Kunden i samarbejde med Leverandøren. Bilaget gælder kun for større
Læs meredfgfdhsjfgdghjghfkfhgkfhjsrt Hvad skal en kontrakt indeholde om kvalitetssikring og test? Niels Chr. Ellegaard Plesner Advokatpartnerselskab
dfgfdhsjfgdghjghfkfhgkfhjsrt Hvad skal en kontrakt indeholde om kvalitetssikring og test? Niels Chr. Ellegaard Plesner Advokatpartnerselskab Agenda 1. Indledning 2. Perspektivet 3. Skibbrudne IT-projekter
Læs mereSoftwaretest. - 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 mereEntreprenøren skal følge et kvalitetsstyringssystem, som lever op til de i dette bilag anførte krav.
1 Bilag 1 Kvalitetsstyring. 1. Indledning. Generelt Entreprenøren skal følge et kvalitetsstyringssystem, som lever op til de i dette bilag anførte krav. Entreprenøren skal indenfor rammerne af sit kvalitetsstyringssystem
Læs mereEvaluering af familierådslagning i Børne- og Ungerådgivningen
Evaluering af familierådslagning i Børne- og Ungerådgivningen Udarbejdet af: EPO Dato: --9 Sagsid.:..-A-- Version nr.:. Indholdsfortegnelse Indledning Brugerundersøgelsens resultater Resultater af de indledende
Læs mereVejledning til Tilbudsgiver Dette bilag indeholder Kundens mindstekrav til tilgængelighed, svartider og drift.
BILAG 6 Servicemål Vejledning til Tilbudsgiver Dette bilag indeholder Kundens mindstekrav til tilgængelighed, svartider og drift. Side 2 af 10 Indholdsfortegnelse 1. Omfanget af servicemål 4 1.1 Mindstekrav
Læs mereSyv veje til kærligheden
Syv veje til kærligheden Pouline Middleton 1. udgave, 1. oplag 2014 Fiction Works Aps Omslagsfoto: Fotograf Steen Larsen ISBN 9788799662999 Alle rettigheder forbeholdes. Enhver form for kommerciel gengivelse
Læs mereSecure 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 mereEn personlighedstest i forbindelse med en jobsøgning
Af Anne Cathrine Schjøtt Personlighedstest: Lær dig selv at kende Personlighedstests er kommet for at blive. Derfor kan man lige så godt åbne sindet og blive gode venner med de skriftlige tests, lyder
Læs mereHvad er en referencelinie? Tidsligt fastlagt Veldefineret tilstand af mellemprodukter Mellemprodukter vurderes Sandhedens øjeblik
Hvad er en referencelinie? Tidsligt fastlagt Veldefineret tilstand af mellemprodukter Mellemprodukter vurderes Sandhedens øjeblik En referencelinie er en koordineret og veldefineret tilstand i et projekt,
Læs mereTag kontrollen tilbage. - Sådan undgår du hardware servicefælden
Tag kontrollen tilbage - Sådan undgår du hardware servicefælden Dyre serviceaftaler æder dit IT budget Du kender det sikkert allerede. Som IT Chef har du selv et stigende krav til dine leverandører omkring
Læs mereUdbud af RIPA-Syd. Underbilag 14.A - Definitioner og testtype katalog
Udbud af RIPA-Syd til Underbilag 14.A - Definitioner og testtype katalog Underbilag 14.A Definitioner og testtypekatalog Side 1 af 10 Indholdsfortegnelse: 1. DEFINITIONER...4 2. TESTTYPE KATALOG...5 2.1
Læs mereStyring 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 mereSoftware test i Socialstyrelsen. af: Jan Kristensen. Nov 2013
Software test i Socialstyrelsen af: Jan Kristensen Nov 2013 Agenda Lidt om Socialstyrelsen IT i Socialstyrelsen Software test QA Udviklingsmetode Agurkemetoden Test cases Test automatisering Afslutning
Læs mereScope 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 mereSmartFraming Et vindue til nationale sundhedssystemer. Version 3.0
SmartFraming Et vindue til nationale sundhedssystemer Version 3.0 Infrastruktur i dagens sundheds IT Det sundhedsfaglige personale benytter sig i dag af en række forskellige systemer i forbindelse med
Læs mereEA3 eller EA Cube rammeværktøjet fremstilles visuelt som en 3-dimensionel terning:
Introduktion til EA3 Mit navn er Marc de Oliveira. Jeg er systemanalytiker og datalog fra Københavns Universitet og denne artikel hører til min artikelserie, Forsimpling (som også er et podcast), hvor
Læs mereArtikel trykt i ERP. Gengivelse af denne artikel eller dele heraf er ikke tilladt ifølge dansk lov om ophavsret.
ERP Artikel trykt i ERP. Gengivelse af denne artikel eller dele heraf er ikke tilladt ifølge dansk lov om ophavsret. Børsen Ledelseshåndbøger er Danmarks største og stærkeste videns- og udviklingsklub.
Læs mereKontrakt om Videreudvikling, Vedligeholdelse og Support af IMK2- systemet. Bilag 12 - Ændringshåndtering
Kontrakt om Videreudvikling, Vedligeholdelse og Support af IMK2- systemet Bilag 12 - Ændringshåndtering 12.05.2016 Version 1.0 [Vejledning til tilbudsgiver: Bilaget er i sin helhed at betragte som et mindstekrav
Læs mereTil ledelsen af kvalitetstyringssystemet for natur og miljøområdet. 2. maj Analyserapport for kvalitetsstyringssystemet på natur og miljøområdet
Til ledelsen af kvalitetstyringssystemet for natur og miljøområdet. Svendborg Kommune Centrumpladsen 7, 2. 5700 Svendborg Tlf. 62 21 19 04 Fax. xxxxxxxx www.svendborg.dk 2. maj 2012 Analyserapport for
Læs mereJammerbugt Kommune. Periodisk audit, P2. Ledelsessystemcertificering. Kvalitetsstyring - iht. Lov 506 af 07.06.2006 og Bek. 1258 af 15.12.
Ledelsessystemcertificering Kvalitetsstyring - iht. Lov 506 af 07.06.2006 og Bek. 1258 af 15.12.2011 Audit 22. oktober 2014 Certificeringens dækningsområde DNV teamleader: Auditteam: Sagsbehandling på
Læs mereArtikel trykt i Controlleren. Gengivelse af denne artikel eller dele heraf er ikke tilladt ifølge dansk lov om ophavsret.
Controlleren Artikel trykt i Controlleren. Gengivelse af denne artikel eller dele heraf er ikke tilladt ifølge dansk lov om ophavsret. Børsen Ledelseshåndbøger er Danmarks største og stærkeste videns-
Læs mereBILAG 1: TIDSPLAN DUBU 3.0. Version 0.5
BILAG 1: TIDSPLAN Version 0.5 18-11-2016 INSTRUKTION TIL TILBUDSGIVER Nærværende Bilag indeholder tidsplanen for gennemførelse af Projektet. Nærværende Bilag skal udfyldes af Tilbudsgiveren, jf. nedenstående
Læs mereProjektarbejde med scrum- metoden
Projektarbejde med scrum- metoden Indhold Indhold... 1 1 Indledning... 2 2 Roller og terminologi i scrum... 3 Opgavestilleren... 3 Scrum Masteren... 3 Projektgruppen... 3 Sprint... 3 3 Møder... 3 Planlægningsmødet...
Læs mereProjektlederens 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 mereProduktbeskrivelse for
Produktbeskrivelse for Service til opfølgning på behandlingsrelationer NSP Opsamling Tjenesteudbyder Opfølgning Notifikation Side 1 af 7 Version Dato Ansvarlig Kommentarer 1.0 22-12-2011 JRI Final review
Læs mereStyregruppens anvendelse af tests
Styregruppens anvendelse af tests Styregruppens anvendelse af testresultater til styring af leverancen Danish Software Testing Board (DSTB) Softwaretest fra teori til praksis 2016 Bo Lind Fagråd for Strategi
Læs mereOPSTILLING AF EFFEKTIVE MILEPÆLE FOR FLÅDECHEFER
OPSTILLING AF EFFEKTIVE MILEPÆLE FOR FLÅDECHEFER KORTLÆGNING AF EN VELLYKKET STRATEGI FOR 2019 INTRODUKTION Når du skal ud på en længere rejse, er det ikke nok kun at kende destinationen. Du skal også
Læs mereFRA 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 mereStyregruppeformænd i SKAT Kort & godt (plastkort)
Håndbogen for Styregruppeformænd i SKAT Kort & godt (plastkort) 80% af alle projekter, hvor der er uigennemskuelighed fejler Lange projekter er mere risikofyldte end korte Transparente projekter har oftere
Læs mereMetoder og produktion af data
Metoder og produktion af data Kvalitative metoder Kvantitative metoder Ikke-empiriske metoder Data er fortolkninger og erfaringer indblik i behov og holdninger Feltundersøgelser Fokusgrupper Det kontrollerede
Læs mereChecklister. Appendiks til bogen Softwaretest. Indhold
Checklister Appendiks til bogen Softwaretest Indhold Checklister... 1 Appendiks til bogen Softwaretest... 1 1. Indledning... 2 2. Checkliste til review af foranalysen... 2 3. Checkliste til review af analysefasen...
Læs mereHos 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 mereBILAG 1 TIDS- OG AKTIVITETSPLAN
BIAG 1 TIDS- OG AKTIVITETSPAN INDHODSFORTEGNESE 1. Hovedtidsplan... 5 1.1 Ændring af tidsplanen... 6 2. Underbilag 1.a Milepæle for levering af licenser og evt. hardware... 6 3. Underbilag 1.b Detailplan
Læs mereProjektets karakteristika
Projektets karakteristika Gruppeopgave Projektledelse DTU 1999 Projektets karakteristika Formål At give en karakteristik af projektets stærke og svage sider, som kan lægge til grund for den senere mere
Læs mereBILAG 6 ÆNDRINGSHÅNDTERING
BILAG 6 ÆNDRINGSHÅNDTERING INDHOLDSFORTEGNELSE 1. Indledning... 4 2. Ændringer... 4 2.1 Kundens ændringsanmodning... 4 2.2 Leverandørens ændringsanmodning... 4 2.3 Mindsteindhold for et løsningsforslag...
Læs mereAu 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(Bilaget ligger på i pdfformat og word-format.)
BILAG 7 DEN AGILE METODE OG SAMARBEJDSORGANISATION (Bilaget ligger på http://silkeborgkommune.dk/erhverv/udbud/varer-og-tjenesteydelser i pdfformat og word-format.) Skemaer udfyldes af Tilbudsgiver. Besvarelsen
Læs mereErfaringer med CPR-replikering
Erfaringer med CPR-replikering Dette dokument beskriver en række overvejelser vi har gjort os i forbindelse med at vi har udviklet en Proof of Concept (PoC) af en CPR-replikeringstjeneste for KOMBIT. CPRs
Læs mereUnderbilag 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 mereBilag 1 Tidsplan Version 0.9 05-05-2014 0
Bilag 1 Tidsplan Version 0.9 05-05-2014 0 Indhold 1 VEJLEDNING TIL TILBUDSGIVER... 2 2 INDLEDNING... 3 2.1 ETAPER I UDVIKLINGSPROJEKTET... 3 2.1.1 ETAPE I - AFKLARING... 3 2.1.2 ETAPE II ANALYSE, DESIGN,
Læs mereUdbud 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 mereETC sæt strøm til projektstyringen
ETC sæt strøm til projektstyringen Sådan får du succes med projektestimering Få styr på projekter og deadlines Denne publikation indeholder en gennemgang af den nye ETC-funktion i TimeLog Project. Med
Læs mereEfter et årti med BIM i Danmark: Hvor langt er vi?
Efter et årti med BIM i Danmark: Hvor langt er vi? Selv efter et årti er BIM stadiget af byggebranchens helt store buzzwords - og et begreb som enhver materialeproducent skal forholde sig til. Hvor peger
Læs mereVedrørende Lægemiddelstyrelsens it-projekt DAHLIA
Finansudvalget 2009-10 FIU alm. del 16 Bilag 3 Offentligt Folketingets Finansudvalg Vedrørende Lægemiddelstyrelsens it-projekt DAHLIA Ministeriet for Sundhed og Forebyggelse gav ved brev af 5. november
Læs mereForandringsprocesser i demokratiske organisationer
Forandringsprocesser i demokratiske organisationer 4 nøgleudfordringer Af Tor Nonnegaard-Pedersen, Implement Consulting Group 16. juni 2014 1 Bagtæppet: Demokratiet som forandringsmaskine I udgangspunktet
Læs mereUDFORMNING AF POLITIKKER, REGLER, PROCEDURER ELLER GODE RÅD SÅDAN GØR DU
UDFORMNING AF POLITIKKER, REGLER, PROCEDURER ELLER GODE RÅD SÅDAN GØR DU HVORFOR? På Aalborg Universitet ønsker vi, at vores interne politikker, regler og procedurer skal være enkle og meningsfulde. De
Læs mereDer påvises en acceptabel kalibrering af kameraet, da det værdier kun er lidt lavere end luminansmeterets.
Test af LMK mobile advanced Kai Sørensen, 2. juni 2015 Indledning og sammenfatning Denne test er et led i et NMF projekt om udvikling af blændingsmåling ved brug af et LMK mobile advanced. Formålet er
Læs mereProjekt Byg og Miljø har netop færdiggjort første indledende runde af leverandørdialogen.
OPSUMMERING AF TEKNISK DIALOG Byg og Miljø Projekt Byg og Miljø har netop færdiggjort første indledende runde af leverandørdialogen. 1. Indledning I uge 26 har KOMBIT holdt tekniske dialogmøder omkring
Læs mereGPS stiller meget præcise krav til valg af målemetode
GPS stiller meget præcise krav til valg af målemetode 1 Måleteknisk er vi på flere måder i en ny og ændret situation. Det er forhold, som påvirker betydningen af valget af målemetoder. - Der er en stadig
Læs mere1. Baggrund og problemstilling
1. Baggrund og problemstilling 1.1 Baggrund Opgavestiller og fremtidig bruger af systemet er klinikken Tandlæge Annelise Bom 1. Opgaven udspringer af et ønske om at forbedre aftalestyringen. Nøgleordene
Læs mereNye 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 mereRetningslinjer for arkitekturreviews Version 1.0. Maj 2017
Retningslinjer for arkitekturreviews Version 1.0 Maj 2017 Indhold Indhold... 2 Introduktion til retningslinjerne... 3 Hvilke projekter skal have foretaget arkitektur-reviews?... 3 Tre trin for arkitekturreviews...
Læs mereVejledning - Udarbejdelse af gevinstdiagram
Vejledning - Udarbejdelse af gevinstdiagram Maj 2015 INDHOLD 1. INDLEDNING... 1 1.1 FORMÅL... 1 1.2 VEJLEDNINGENS SAMMENHÆNG MED DEN FÆLLESSTATSLIGE IT-PROJEKTMODEL... 1 1.3 GEVINSTDIAGRAMMET... 2 1.4
Læs mereBilag 19: Test af DTT-nettet
Bilag 19: Test af DTT-nettet Indholdsfortegnelse 1. Sammendrag...3 2. Testlaboratorium...4 3. Acceptanstests...5 4. Systemtests...5 5. Stabilitetstests...6 6. Smartkorttests...6 7. Test af overensstemmelse
Læs mereEr der stadig behov for brugeruddannelse?
Er der stadig behov for brugeruddannelse? Bjarne Herskin, teach to teach, 2013 ER DET NØDVENDIGT MED BRUGERUDDANNELSE ANNO 2013? Er det virkelig stadig relevant at afholde it-brugerkurser. Er vi ikke nået
Læs mereUNDERBILAG 3A.1 TIL KONTRAKT OM EOJ-SYSTEM. Use case Opfølgning
UNDERBILAG 3A.1 TIL KONTRAKT OM EOJ-SYSTEM Use case Opfølgning INSTRUKTION TIL TILBUDSGIVER: Teksten i dette afsnit er ikke en del af Rammeaftalen og vil blive fjernet ved indgåelse heraf. Formål med bilag:
Læs mereKvalitet på arbejdspladsen
Kvalitet på arbejdspladsen Kvalitet på arbejdspladsen Indhold Hvad er kvalitet? At bygge fundamentet en spændende proces Slut med snakken i krogene Kvalitet tager tid men hvilken tid? Gryden skal holdes
Læs mereDansk-historieopgaven (DHO) skrivevejledning
Dansk-historieopgaven (DHO) skrivevejledning Indhold Formalia, opsætning og indhold... Faser i opgaveskrivningen... Første fase: Idéfasen... Anden fase: Indsamlingsfasen... Tredje fase: Læse- og bearbejdningsfasen...
Læs mereBilag 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 mereSOLRØD KOMMUNE ESDH. Afprøvning. Bilag 6
SOLRØD KOMMUNE ESDH Afprøvning Bilag 6 April 2007 Vejledning Leverandør skal kvalificere bilaget ved at tilføje: Testplaner Beskrivelse af leverandørens metoder eller processer til intern test inden overgivelse
Læs mereDynamics AX hos Columbus
Dynamics AX hos Columbus Dynamics AX er ikke længere bare Dynamics AX Stop lige op, før du vælger at opgradere Vejen til produktivitet er Rollecentre Henrik fortæller dig, hvordan det er at være kunde
Læs mere