Sammanfattningar Essentials of Software Engineering
|
|
- Charlotta Bengtsson
- för 6 år sedan
- Visningar:
Transkript
1 Sammanfattningar Essentials of Software Engineering F10, Testning Quality Assurance (QA) inkluderar testning. Testning är en aktivitet som handlar om att utvärdera produktens kvalitet, och att förbättra den, genom att identifiera defekter och problem. Bästa sättet att uppnå kvalitet är genom att ha en väl-definierad process som passar organisationen och projektet, + att alla teammedlemmar ska vara engagerade och vilja göra sitt bästa samt använda rätt tekniker. Högkvalitativ process! större chanser till högkvalitativ produkt. Det är dock inte ofta som den ideala processen uppnås, därför är testning av artefakterna viktigt genom hela projektet. Olika tekniker för att hitta fel i ett program: - Testning: att designa testfall, köra programmet i en kontrollerad miljö och verifiera att output är korrekt. - Inspektioner och granskningar: en eller flera personer utöver skaparen av produkten tittar på den och granskar den för att hitta fel. Bra att applicera på kravspecifikationer. - Formella metoder: matematiska tekniker för att bevisa att ett program är korrekt - Statiska analyser: att analysera strukturen i ett program. Ofta automatiserade, hittar misstag och felbenägna villkor i programmet. Vi skiljer på fault, failure och error. Människor gör errors (misstag) som kan leda till att mjukvara innehåller faults (buggar, defekter). När man kör mjukvara med faults kan det leda till failure. Testning handlar om att ställa frågor till systemet och jämföra svaret med någon typ av korrekt svar. - Hur ställer vi frågorna? - Hur vet vi svaret (från systemet)? - Hur vet vi vad som är det korrekta svaret, att jämföra med?! Är det en del av kraven?! Räknas det ut manuellt?! Kan man jämföra med tidigare versioner eller andra system?! Kan man använda en fördefinierade test suites (en samling testfall som är
2 menade för att testa mjukvara)?! Ska man använda ett oracle? (eller Heuristics, dvs riktlinjer?) Testning görs utifrån olika testfall som blir grunden för hur man ska utföra testningen. För att bestämma vad ett förväntat resultat av ett testfall ska bli kan vi använda ett test oracle. Ett test oracle är en källa med information om huruvida output från ett testfall är korrekt eller inte. Det kan specificera korrekt output för alla möjliga inputs eller endast för specifika inputs. Det behöver inte specificera specifika output-värden utan kan också bara visa inom vilka begränsningar outputvärdet behöver vara. Testfall De 3 delar som behöver ingå i ett testfall är: - Ett set med input-kriterier - Execution conditions, alltså steg i testet, som inkluderar inputvärdena - Förväntade resultatet Varje testfall ska ha ett unikt ID. Hur kan vi generera och välja testfall? Antingen genom intuition, vilket innebär att man låter den som utför testet fritt välja vad de vill testa. Eller genom specifikationerna. Man baserar alla testfall på vad som står i specifikationerna utan att kolla på koden. Tekniker som baseras på specifikationer kallas för black-box testing. Ett annat sätt att välja testfall är genom att titta på koden. Man baserar testfallen på kunskaper om själva koden, och definierar ett visst mått av vad koden ska täcka
3 för funktioner för att sedan designa testfall för att uppnå det måttet. Tekniker baserade på koden kallas ofta för white-box testing. Black-box testing: Tekniker baserade på specifikationerna White-box testing: Tekniker baserade på koden Vem är det som utför testningen? Vi har tre alternativ: programmerare, testare eller användare. Programmerare utför ofta unit testing. De skapar testfall och kör dem medan de skriver koden. Testares jobb är att skriva testfall och se till att de körs. Här krävs andra kunskaper än endast programmeringskunskaper. Vissa professionella testare analyserar resultaten från testfallen och kan utifrån det bedöma kvalitetsnivån av produkten. Användare är bra att ha med i testningen, för de hittar ofta användbarhetsproblem + att de använder väldigt många olika inputs som är bra för att testa systemet mot riktiga scenarion. Vad är det som testas? - Unit testing: att testa de individuella enheterna av funktionalitet, t. ex. en enda funktion. - Functional testing: att testa så att de individuella enheterna fungerar som en funktionell enhet när man slår samman dem. - Integration and system testing: att testa den integrerade funktionaliteten av det kompletta systemet. Enligt föreläsningen är nivåerna istället dessa: - Unit: testar de individuella enheterna (som ovan) - Integration: testa två eller fler enheter tillsammans (som ovan men annat namn) - System: testa funktionella och icke-funktionella egenskaper i hela systemet. Skillnaden mellan boken och föreläsarens är sista nivån (System eller Integration and system testing). Föreläsarens nivå handlar inte bara om att testa funktionaliteten utan även om att testa icke-funktionella egenskaper hos systemet.
4 Två olika sätt att mäta kvalitet på ett program: Verifiering: Gör vi produkten på rätt sätt? Handlar om att kontrollera att produkten uppfyller kraven och specifikationerna. Man spårar en mjukvaruprodukts krav genom utvecklingsfasen, och när mjukvaran ska gå från en fas till en annan så verifierar man att kraven hittills är mötta. Validering: Gör vi rätt produkt? Att kontrollera att den färdiga mjukvaruprodukten möter användarnas krav och specifikationerna. Kan oftast bara göras i slutet på projektet med ett fullständigt mjukvarusystem. Olika tekniker för att utföra verifiering: inspektion och granskning, testning, statisk analys och formella metoder. Olika tekniker för att utföra validering: testning och inspektioner.
5 F11, Unit-testing Det finns tre olika nivåer av testning: - Unit - Integration - System En unit kan i ett testsammanhang vara lite olika saker: - Individuella funktioner / metoder inom en viss klass - Objektklasser med flera attribut och metoder - Sammansatta komponenter, som består av flera klasser, med definierade gränssnitt som används för att få tillgång till deras funktionalitet Definitionen av unit testing är att man ska testa individuella kodenheter i isolering. Detta innebär att alla beroenden med andra kodenheter måste brytas. Detta kan
6 man göra genom att använda sig av så kallade stubs (stubbar) eller drivers. Stubbar är de moduler som blir kallade på, medan drivers är de funktioner som kallar på andra funktioner. En stubbe innehåller samma gränssnitt som den beroende kodenheten, men ingen funktionalitet. Istället kan den förse med förbestämda svar på förfrågningar. Olika tekniker för att ta fram testfall: Equivalence Class Partitioning En black-box teknik (alltså baserad på specifikationerna). Görs denna alltså som white-box teknik för unit testing då, och som black-box när det gäller integration och system testing? Grundtanken med denna teknik är att input och output från en komponent kan delas in i klasser, som enligt komponentens specifikation, kommer att behandlas likadant av komponenten. Då räcker det med att testa ett enda värde från varje klass, som kan representerar hela klassen. Det är viktigt att ta med både giltiga och ogiltiga värden i testfallen. Ex. om en tenta har följande gränser: under 10p = U, = G, 16 och uppåt = VG. Maxpoäng man kan få är 20.! Ekvivalensklasserna blir då 0-9, 10-15, Då väljer man ett värde från varje klass, t. ex. 6, 11 och 17 att testa. Sedan måste man även testa ogiltiga värden. I detta fall allt som är mindre än 0 och större än 20, samt icke-heltal. Dessa kan vara 1.55, -2, 23 och tjoho. Om testfallet misslyckas för ett värde så förväntar vi oss alltså att det misslyckas för alla andra medlemmar i den klassen också, och tvärtom om den lyckas så lyckas den för alla.
7 Border Value Analysis BVA är baserad på Equivalence Partitioning och är därmed också en black-box teknik. Grundtanken är att programmerare är benägna att göra fel när de ska programmera för gränserna i klasserna. Därför bör man testa gränsvärdena i varje klass, alltså; precis under min-värdet, min-värdet själv samt precis över min-värdet; precis under max-värdet, max-värdet och precis över max-värdet. Anledningen till att det är användbart att testa på gränserna är: - För att det är en sannolik källa till programmerings-fel, t. ex. att man råkar skriva < istället för <=. - För att kraven ofta är lite luddiga när det gäller beteendet vid gränsvärden - För att man kan upptäcka interna dolda begränsningar i koden All pairs En metod för att testa kombinationer av input. Den grundläggande principen för denna metod är att de flesta fel orsakas av interaktioner mellan som mest två faktorer. Om man ska testa varje kombination av varje typ av input så får vi ett väldigt stor antal kombinationer att testa. Kan bli tusentals, tiotusentals Därför finns det denna teknik, All Pairs, för att generera endast så många kombinationer som behövs för att täcka alla par av värden. Varje värde från varje variabel, ska paras ihop minst en gång men varje värde från varje annan variabel. Det finns All-pairs verktyg som genererar ett passande set med testfall. White-box testning = metoder baserade på den interna strukturen av koden. Används oftast i unit testing. Path Analysis Två uppgifter i path analysis: 1. Analysera antalen paths som existerar i ett system eller ett program 2. Bestäm hur många vägar som ska inkluderas i testet. Hur många vägar som ska inkluderas i de olika testfallen bestäms genom att man ska se till att varje statement är täckt av något test och varje branch är täckt av något test. Detta kallas för coverage-based testing. Det finns tre grundläggande typer av code-coverage:
8 - Statement coverage: se till att varje statement utförs åtminstone en gång i något av testfallen - Branch coverage: se till att för varje beslutspunkt i grafen så ska varje branch väljas åtminstone en gång - Path coverage: se till att varje unik path genom hela control-flow grafen utförs åtminstone en gång i något av testfallen Man kan använda sig av cyklomatisk komplexitet för att få en indikation för hur många testfall som behövs för att täcka en bit kod. CC är då den övre gränsen för Branch coverage (BC), och den lägre gränsen för Path coverage (PC). Fördelar med coverage-based testing: - Det är ett systematiskt sätt att utveckla testfall - Det finns mätbara resultat alltså hur täckande det blir - Det finns många stödverktyg att använda, t. ex. testdata-generatorer Nackdel: - Koden måste vara tillgänglig Olika verktyg för code coverage mäter olika saker, så det är viktigt att ta reda på vad verktyget man använder mäter. Test-driven development = att skriva unit tests innan man skriver koden, och sedan använda dessa tester för att se till att koden fungerar. Detta gör att du först får ange kraven som en testfall, och sedan implementera dem. Process för detta:
9 1. Skriv ett testfall 2. Verifiera att det testfallet misslyckas 3. Ändra korden så att det testfallet lyckas (målet är att skriva så enkel kod som möjligt, utan att bry sig om framtida tester eller krav) 4. Kör testfallet för att verifiera att det nu fungerar och kör de tidigare testfallen för att verifiera att koden inte har fått någon annan ny defekt. 5. Refactor the code, för att göra den bättre. Fördelar med TDD: - Man skriver endast skriver små kodsnuttar, testar, sedan fortsätter skriva. - Man får först ange kraven som ett testfall, och sedan implementera dem. Detta gör att du måste förstå kraven först innan du implementerar dem. - Leder ofta till att man skriver fler tester och enklare kod. Uppnår ofta åtminstone statement coverage. - Det är en effektiv teknik som hjälper programmerare att snabbt bygga pålitlig kod.
10 F12, Integration testing, system testing, reviews and test reporting Integration testing = man testar två eller fler enheter tillsammans, för att se till att de individuella enheterna fungerar som en funktionell enhet Här skapar man testfall som testar gränssnittet mellan moduler.
11 Problem som kan finnas i gränssnittet mellan två komponenter: - Interface misuse: en komponent kallar på en annan komponent men använder dess gränssnitt felaktigt. T. ex. att parametrarna används i fel ordning. - Komponenten som kallar på den andra har inbäddade antaganden om beteendet hos den andra komponenten som är felaktiga. - Komponenten som kallar och komponenten som blir kallad på opererar i olika hastighet och utgången information blir hämtad. Man vill alltså försöka hitta fel i gränssnittet. För att kunna göra det behöver man en s.k. call graph, eller dependency graph. Anledningen till att man behöver en call graph är för att man ska få en förståelse av systemet, och kunna spåra flödet av värden mellan olika funktioner. Olika strategier för integration testing: - Big Bang = Alla moduler/komponenter integreras samtidigt. Sedan testar man allt, man har alltså inga mellanliggande test. Inga moduler integreras förrän alla moduler är färdiga.
12 - Top Down = Här börjar man med huvudmodulen och lägger sedan till moduler genom att följa call graph:en. Man integrerar de viktigaste modulerna först. - Bottom Up = Här börjar man med löven i call graph:en, och lägger sedan till moduler genom att följa call graph:en uppåt i hierarkin. - Use Case / Scenario = Man integrerar alla delar av koden som tillhör ett visst scenario och testar dessa. Moduler som inte är färdiga än och alltså inte går att testa med använder man stubbar eller drivers för att ersätta. Stubbar / stubs används för att simulera funktionalitet hos en modul som man behöver kalla på för att kunna testa en modul. = called Drivers används för att simulera funktionalitet hos en modul som ska kalla på modulen man testar. = callers System Testing = systemtestning under utvecklingen handlar om att skapa en version av de i princip färdiga systemet och testa detta Använder nästan alltid black-box tekniker. Det är viktigt att ha en bra versionshantering för att kunna veta vilken version som testats vart buggar har blivit fixade. Man kan använda use cases som identifierar systemets interaktioner som en bas för att testa funktionalitet under systemtestningen. Man testar också icke-funktionella krav under systemtestning. Vilka metoder används? Man kan använda metoder så som EP och BVA för att utveckla testfall även här, men sedan finns det fler metoder. Exempelvis dessa: - Heuristics, t. ex. felgissning. Vad brukar gå fel i den här typen av mjukvara? - Bug taxonomy vilka är de vanligaste buggarna man har hittat hittills i projektet eller från de här utvecklarna? The V-model:
13 Systemtester kan vara scripted eller exploratory. Scripted innebär att man följer ett set med instruktioner (skrivna i förväg) när man gör testet. Exploratory innebär att man skapar testfallen och de förväntade outputen under testsessionen. - dessa kan vara time boxed - dessa kan vara baserade på en tour, t. ex. att man går igenom alla funktioner. Systemtester kan baseras på individuella funktionella krav, icke-funktionella krav, användarscenarion (use cases) eller scenarion. Ett koncept för testning kallas för Soap Opera tests det innebär att man testar en överdriven eller sammanträngd verklighet. Man använder sig av användarscenarion men gör dem mer komplicerade, precis som man gör med handlingen i soap operas.! Detta gör att funktioner och egenskaper testas snabbare och på en högre nivå än i riktiga situationer. Icke-funktionella krav blir allt viktigare i systemtestningen Man bör testa alla egenskaper i ISO9126. Idag ligger ofta fokus på performance testing. För att testa denna utför man ofta Load Tests och Stress Tests.
14 - Load test = testa om systemet kan hantera den belastning som det är gjort för - Stress test = kan systemet hantera korta perioder av overload, och återhämta sig snyggt från detta? Även andra tester kan prioriteras, så som säkerhetstester (penetrationstester, integritetstester) och användbarhetstester (kan användaren utföra alla operationer i systemet? Kan användare installera och börja använda systemet utan hjälp?) Olika typer av tester: Release testing: man testar en viss release av ett system, som ska användas utanför utvecklingsteamet Acceptance testing: utförs ofta av kunden. Ibland är det dock kunden som definierar testfallen men sedan utförs de av utvecklingsteamet (under övervakning av kund). User tests (INTE användbarhetstester): Uppdelade i två grupper: - Alpha tests: en begränsad grupp testar tidigare versioner av systemet, för att få feedback tidigt - Beta tests: en stor grupp testar den nästan färdiga produkten, för att hitta buggar relaterade till configuration eller för att testa specifika användarscenarion som är svåra att härma under labbtester. Crowd testing: Liknar Alpha- och Beta testning, men här har de som utför testerna en formell roll i testningsorganisationen och kan få specifika instruktioner över vad som ska testas. Testarna kan betalas per aktivitet eller per bugg de hittar. Static vs Dynamic Testing
15 Static testing Automatisk statisk analys (ASA) Ett verktyg analyserar koden och producerar varningsmeddelanden och felmeddelanden. Här kan det finns både false positives, varningar när det egentligen inte är något problem (false alarm), och false negatives, problem som verktyget inte hittar. Låg kostnad men har hög påverkan. Reviews Människor läser och kommenterar koden och dokumentationen. Kräver inte att programmet körs. Fördelar med reviews: - Man hittar buggar - Man minskar risker - Man ser till att alla kan förstå dokumentationen Alla typer av dokument kan granskas. Kravspecar, designdokument, kod, testfall, användarmanualer osv. Det finns olika typer av reviews: - Tekniska reviews (Peer review är en förenklad sådan.) - Inspections
16 - Walk-through Den minst formella typen av review är när två personer, författaren och en kollega, diskuterar koden. Peer review = författaren av dokumentet ger det till en kollega som får granska det, sedan gör kollegan granskningen självständigt och skriver formella kommentarer till författaren av dokumentet. Walkthrough = möte. Författaren går igenom dokumentet och så får några granskare ge kommentarer. Efter detta får författaren fundera över kommentarerna och sedan uppdatera dokumentet. Inspection = möte. Mer formell än de andra två. Man har formella roller, t. ex. chairman och recorder. Författaren kan vara närvarande men det är inte hen som presenterar dokumentet. Materialet som ska granskas skickas ut i förväg så att alla individuellt kan granska det först. En reader (inte författaren) leder gruppen genom materialet. Inspektörerna ger kommentarer som diskuteras. Här kan man använda sig av checklistor när man går igenom dokumentet. En jämförelse av olika tekniker Dokument från testning - Testplan - Testfall - Buggrapporter - Testverktyg och automatiserad testning - Metrics, statistik och sammanfattning Vad kan ingå i en testledares rapport till projektledningen? Kvalitetsrisker hur många av de identifierade riskerna har testats hittills? Defekter hur många har hittats, hur många har fixats, m.m.
17 Testfall hur många har skapats, hur många har utförts, inte utförts, osv. Coverage hur mycket kod har blivit täckt av testning hittills? Kostnad hur mycket tid har vi spenderat hittills? Dessa olika aspekter visar man ofta i en graf. Att avsluta testning Att hålla koll på testresultaten och observera statistiken. Olika sätt: Problem find rate antalet problem man hittat per timma varje dag i en graf, se hur de minskar med tiden. Man kan ha ett mål i planen som säger att när problem find rate har minskat till en viss nivå så slutar man testa. S-curve ett annat sätt att mäta när man kan sluta testa. Visar en kurva över hur antalet defekter ökar, och när den kurvan har nått en viss stabilitet så slutar man testa. Pepper code with defects sedan sortera kodens defekted i seeded defects och i riktiga defekter. Utifrån detta kan man sedan anta ungefär hur många fel som finns kvar i koden. De kostnader som vägs mot varandra i en beräkning av ROI är kostnaderna för att förebygga testning och kostnaderna för att ha dålig kvalitet på slutprodukten. ROI för testning är oftast flera hundra procent.
Configuration testing Why? Vad det är tänkt att koden ska göra. Performance testing Kommentarer Skriva om koden som kommentar
Skapa testfall Testing Köra testen Hitta fel Inspections and reviews Verifiera resultatet Formal methods Static analysis Completeness Verifiering Kvalitet Maintainability Validering Traceability Fault
Några grundläggande begrepp
Några grundläggande begrepp Validering bygger vi rätt system? Uppfyller kravspecifikationen de verkliga behoven? Verifiering bygger vi systemet rätt? Uppfyller det färdiga systemet kravspecifikationen?
Testning på 3 föreläsningar. PV7180 Verifiering och Validering. Litteratur. Vad är testning? Varför testa och olika syn? Målet med testning
ning på 3 föreläsningar Första föreläsningen Översikt PV7180 Verifiering och Validering Föreläsning 3 ning del 1 Andra föreläsningen Coverage ing, OO-ing, Utvärdering av tekniker Tredje föreläsningen Automatiserad
TDDI02. Programmeringsprojekt. Föreläsning 3 Jonas Lindgren, Institutionen för Datavetenskap, LiU
TDDI02 Programmeringsprojekt. Föreläsning 3 Jonas Lindgren, Institutionen för Datavetenskap, LiU På denna föreläsning: Verifikation, Validering och Testning XP Extreme Programming Vad är ett fel? I engelskan
Testplanering, test-first, testverktyg
Testplanering, test-first, testverktyg Mats Skoglund Department of Computer and Systems Sciences Stockholm University/Royal Institute of Technology Stockholm, Sweden 12 mars 2007 Mats Skoglund Page 1(33)
Mjukvarudesign. Designprocessen. Teknisk design. Konceptuell design
RE SD PD I UT IT ST AT Mjukvarudesign System Requirement Specification Inkrementell och iterativ! Konceptuell design (VAD) Systemdesign (OOA) Arkitekturell (grovkornig, UML) Teknisk design (HUR) Programdesign
Testdriven utveckling. Magnus Jonsson Siemens Medical Solutions
Testdriven utveckling Magnus Jonsson Siemens Medical Solutions 2 Soarian Stort projekt, ca 400 personer i projektet Distribuerad utveckling i USA, Indien och Sverige Web baserat lösning med admin client
Testning. 1DV404, HT14 Jesper Andersson Kap 21 + Testing Primer
Testning 1DV404, HT14 Jesper Andersson Kap 21 + Testing Primer UP Faser Elaboration ü Syfte: Fastställa och validera en basarkitektur för systemet vilket ger en stabil grund för den största delen av utvecklingsarbetet
TDDI02. På denna föreläsning: Programmeringsprojekt, Föreläsning 3. Verifikation, validering och testning
TDDI02 Programmeringsprojekt, Föreläsning 3 Anton Sundblad Filip Strömbäck Med utgångspunkt i tidigare slides av Jonas Lindgren På denna föreläsning: Verifikation, validering och testning Begreppsdistinktioner
TDDI02. På denna föreläsning: Programmeringsprojekt, Föreläsning 3. Filip Strömbäck. Verifikation, validering och testning
TDDI02 Programmeringsprojekt, Föreläsning 3 Filip Strömbäck Med utgångspunkt i tidigare slides av Jonas Lindgren På denna föreläsning: Verifikation, validering och testning Begreppsdistinktioner Lite populistiskt
men borde vi inte också testa kraven?
men borde vi inte också testa kraven? Robert Bornelind Presentation på SAST, 24 februari 2011 SQS Software Quality Systems Sweden AB Innehåll Introduktion Kvalitet, tid och kostnad Process Testning av
Testning av applikationer
Tentamen, (20 YH-poäng) Plats: Övningstenta Tid: Övningstenta Tillåtna hjälpmedel: Papper, penna, suddgummi, linjal. Ej tillåtna hjälpmedel: Datorer, mobiltelefoner, surfplattor, miniräknare, böcker, anteckningar,
Testautomatisering. Intro
Testautomatisering FM: Presentation Genomgång av Kursplan / Kursupplägg Varför testautomatisering? Video + diskussion Idag David Gullmarsvik david.g@jetas.se Software Developer Tidigare Lärare KYH, TI
Programvaruutveckling - Metodik 2016 Jonas Wisbrant
Föreläsning 3: Test och efterläsning om kodning Programvaruutveckling - Metodik 2016 Jonas Wisbrant 1 Kursinformation Detta har hänt: Pratat och skapat krav (och plan) Övning 2 Riskhantering, intressenter
F6 Objektorienterad design. ID1004 Objektorienterad programmering Fredrik Kilander
F6 Objektorienterad design ID1004 Objektorienterad programmering Fredrik Kilander fki@kth.se långa ord AKTIVITETER I PROGRAMVARUUTVECKLING Iterativ utveckling Kravspecifikation Design Implementation Testning
Metoder och verktyg för funktionssäkerhet
Metoder och verktyg för funktionssäkerhet Projektstart 1. Hantera kraven En bra process är grunden för att hantera kraven i ett säkerhetsprojekt. Det krävs att du har en tydlig spårbarhet mellan krav och
Platina och kvalité. Rasmus Staberg, Teknisk direktör, 2014-04-08
Formpipe Platina och kvalité Rasmus Staberg, Teknisk direktör, 2014-04-08 04 08 1 Formpipe Presentation Bakgrund Platina släpptes som första release år 2000. Fick pris för Best in show från Bill Gates
men borde vi inte också testa kraven? Robert Bornelind
men borde vi inte också testa kraven? Robert Bornelind Presentation på SAST 15 års jubileum 14 oktober 2010 SQS Software Quality Systems Nordic Innehåll Introduktion Kvalitet, tid och kostnad Process Testning
Programdesign. Dokumentera. Dokumentera
Programdesign Dokumentera Välj datastruktur så programmet blir så enkelt som möjligt. Välj algoritm så programmet blir lättläst, robust och effektivt. Analysera programmet för att få en bra metod. Överväganden
Testplan Cykelgarage
Testplan Cykelgarage Stefan Johansson D08 (dt08sj7@student.lth.se) Johan Anderholm D08 (dt08ja5@student.lth.se) Angelica Gabasio D08 (dt08ag8@student.lth.se) Marcus Carlberg D08 (dt08mc4@student.lth.se)
Programdesign. minnesutrymme storlek på indata. DA2001 (Föreläsning 15) Datalogi 1 Hösten / 20
Programdesign Välj datastruktur så programmet blir så enkelt som möjligt. Välj algoritm så programmet blir lättläst, robust och effektivt. Analysera programmet för att få en bra metod. Överväganden vid
Unit testing methodology
Department of Computer Science Per Hurtig Stefan Lindberg & Fredrik Strandberg Unit testing methodology Opposition Report, C/D-level 2005:xx 1 Övergripande utvärdering Helhetsintrycket av uppsatsen är
Filhanterare med AngularJS
Filhanterare med AngularJS Författare: Filip Johansson Peter Emilsson Oskar Georgsson Christian Nilsson Datum: 2014-03-26 1 Sammanfattning Filhanterare med AngularJS är en filhanterare skapad för Sigma
Presentation. Fredrik Runnsjö 1996 Utvecklare 2004 Testare ~2006 Scrum/Canban
Presentation Fredrik Runnsjö 1996 Utvecklare 2004 Testare ~2006 Scrum/Canban Om AddQ Mission Vi skapar affärsnytta för kunden genom specialisttjänster inom test, kvalitetssäkring och effektivisering Tjänsteområden
Laboration: Whitebox- och blackboxtesting
Tilda11 höstterminen 2011 Laboration: Whitebox- och blackboxtesting Mål med laborationen Du ska lära dig begreppen white-box testing och black-box testing Du ska öva dig på att konstruera testfall Du ska
Regressionstestning teori och praktik
Regressionstestning teori och praktik Lic. Emelie Engström emelie.engstrom@cs.lth.se Software Engineering Research Group LUND UNIVERSITY Sweden SWELL the Swedish Research School in Software Verification
Anledning: Generellt så undviker QUPER att göra fullständiga förutsägelser för relationerna mellan ett systems fördelar, kostnad och kvalitet.
Fråga 1. QUPER Påstående: QUPER är en modell för att elicitera krav Anledning: Generellt så undviker QUPER att göra fullständiga förutsägelser för relationerna mellan ett systems fördelar, kostnad och
Exempel på verklig projektplan
Exempel på verklig projektplan Detta är ett exempel på en proffessionell projektplan hämtad ur verkliga livet. Den visas inte i sin fullständighet, det mesta är bortklippt, men strukturen och mycket av
V!cto. Att tjäna pengar genom bättre testning med
Att tjäna pengar genom testning med Att tjäna pengar genom testning med 1 (50) Det finns tre vägar till test: 1: Testautomati- Att bygga sering Att bygga Att bygga Att bygga Att bygga Att bygga Att bygga
SF Bio App. Repport. Test summary. 1- Syfte. 2. Produktöversikt. Författare: Zina Alhilfi Datum: Version: v1,0
Test summary SF Bio App. Repport Författare: Zina Alhilfi Datum: 2017-03-13 Version: v1,0 Granskad: Klar Ref: Test plan V1,0 Status: klar 1- Syfte Syftet med denna slutrapport är att redovisa vilka testaktiviteter
Visuell GUI Testning
Visuell GUI Testning Vad är ett Graphical User Interface (GUI)? Icke-animerat GUI Animerat GUI Nuläget System- och acceptanstestning är dyrt! Manuellt Långsamt Enformigt Svårt att replikera exakt Nödvändigt
CREATING VALUE BY SHARING KNOWLEDGE
CREATING VALUE BY SHARING KNOWLEDGE PROJEKTLEDNING 101 Nidzara Dellien, Lund September 2017 PROJEKT En formell definition på projekt är följande (enligt Wikipedia): En temporär satsning för att framställa
Introduktion Schenker-BTL AB, Stab IT Beskrivning över informationsintegreringmed Schenker, metodbeskrivning version 1.
Schenker har interna system som handhar information som är av intresse för våra kunder/partners. Idag finns ett flertal av dem tillgängliga via Internet, sk Online-tjänster. Dessa erbjuder inte bara hämtning
Vad är RTCA DO-178C? och: Hur arbetar Saab med dessa krav? Lars Ljungberg, Saab AB, Avionics Systems
Vad är RTCA DO-178C? och: Hur arbetar Saab med dessa krav? Lars Ljungberg, Saab AB, Avionics Systems 2018-05-07 FUNCTONAL SAFETY DO-178C är processorienterad dentifiera risker (hazards) och de säkerhetsfunktioner
Test och utvärdering - introduktion. Systemering med användarfokus Malin Pongolini
Test och utvärdering - introduktion Systemering med användarfokus Malin Pongolini ACD metoden: faserna Analys Användaranalys Uppgiftsanalys Kravställande Användbarhetskrav Funktionalitetskrav Design Prototyping
Testning som beslutsstöd
Testning som beslutsstöd Vilken typ av information kan testning ge? Vilken typ av testning kan ge rätt information i rätt tid? Hur kan testning hjälpa din organisation med beslutsstöd? Hur kan produktiviteten
Vad händer med L3: ΔL3-L4 för Krav följs upp av annan projektgrupp. Föreläsning 5: V&V II + Design II Efterläsning Kodning
Föreläsning 5: V&V II + Design II Efterläsning Kodning Programvaruutveckling - Metodik 2016 Jonas Wisbrant 1 Vad händer med L3: ΔL3-L4 för Krav följs upp av annan projektgrupp PHL kopierar L3 + PHL-protokoll
Testning av program. Verklig modell för programutveckling
Fel i program När man skriver program uppkommer alltid fel. Felen kan indelas i följande kategorier: Under kompileringen upptäcker kompilatorn fel som handlar om att man använt konstruktionerna i programspråket
Kursinformation. Metodik för programvaruutveckling. Utvecklingsprocessen för programvara. Innehåll. Processmodell. Exempel
Kursinformation Metodik för programvaruutveckling Föreläsning 3 Latex ok för litteraturstudierapport (prata med mig bara) Nästa föreläsning är av Björn Regnell (jag är med också) Presentationer imorgon
ALM Live: Testfokus bättre mjukvarukvalitét med Visual Studio 2008 Team System
ALM Live: Testfokus bättre mjukvarukvalitét med Visual Studio 2008 Team System Magnus Juvas Qwise Om oss: Qwise Vi hjälper systemutvecklingsteam att bli bättre. Vi är experter på ALM och Team System. Vi
För varje par av påstående/anledning svara med ett av följande alternativ (½ p per rätt svar):
Fråga 1 (3p) Kap 5 Special interfaces, Kap 10 Techniques at work För varje par av påstående/anledning svara med ett av följande alternativ (½ p per rätt svar): A: Både påståendet och anledningen är korrekta
TPFD - TestPlan Före Design BESKRIVNING AV AKTIVITETER
TPFD Beskrivning Rev 4 1(10) TPFD - TestPlan Före Design BESKRIVNING AV AKTIVITETER Anv.krav Terminologi Detaljkrav Konfigdok Hantera Utgåvor Projektplan Testplan Test-o-felrättning Ändringslogg Återst.
Testning. 1DV404, HT14 Jesper Andersson Kap 21 + Testing Primer
Testning 1DV404, HT14 Jesper Andersson Kap 21 + Testing Primer Testning ü Testningens huvudsakliga syfte är att reducera risker. ü Osäkerhetsfaktorer inom utvecklingen av ny programvara kan få ett projekt
Static vs Dynamic binding Polymorfism. Objekt-orienterad programmering och design Alex Gerdes, 2016
Static vs Dynamic binding Polymorfism Objekt-orienterad programmering och design Alex Gerdes, 2016 Diagnostiskt prov Shape + overlaps(shape): int return 1; Shape shape = new Shape(); Polygon tripoly =
Föreläsning 3 Verifiering och Validering
ETSA01 Ingenjörsprocessen för programvaruutveckling Metodik Föreläsning 3 Verifiering och Validering Jonas Wisbrant 2 Detta har hänt... Pratat och skapat krav och plan Några har kommit i kontakt med IP3-projekt
PMM (Process Maturity Metrics) Allmänt. Mätetal för framgångsfaktorer. 1. CM konfigurationsstyrning
PMM (Process Maturity Metrics) PMM är en metod för att mäta processmognad i utvecklingsprojekt. I korthet går metoden ut på att man utvärderar sin utvecklingsprocess med avseende på ett antal framgångsfaktorer
Övningstenta (Kursplan 2011) Ver 2015, 2015-12-19
Swedish Software Testing Board (SSTB) International Software Testing Qualifications Board (ISTQB) Foundation Certificate in Software Testing Övningstenta (Kursplan 2011) Ver 2015, 2015-12-19 Tillåten tid:
Verifiering & Validering. Integrationstest. Enhetstest. Verifiering och & validering rep. -
Från F3 Verifiering och & validering rep. - INGENJÖRSPROCESSEN forts. METODIK ETSA01 VT13 INGENJÖRSPROCESSEN METODIK ETSA01 VT13 JONAS WISBRANT Verifiering & Validering Verifiering Bygger vi produkten
12 principer of agile practice (rörlig)
X-treme programming 12 principer of agile practice (rörlig) Ge nöjd kund genom tidig och kontinuerliga leveranser Den viktigaste punkten som betyder att min vill ha kontinuerlig feedback Välkomna sena
TDDC74 Programmering: Abstraktion och modellering Tenta, kl 14 18, 11 juni 2014
TDDC74 Programmering: Abstraktion och modellering Tenta, kl 14 18, 11 juni 2014 Läs alla frågorna först, och bestäm dig för i vilken ordning du vill lösa uppgifterna. Skriv tydligt och läsligt. Använd
Static vs Dynamic binding Polymorfism. Objekt-orienterad programmering och design (DIT953) Niklas Broberg, 2018
Static vs Dynamic binding Polymorfism Objekt-orienterad programmering och design (DIT95) Niklas Broberg, 2018 Diagnostiskt prov Shape + overlaps(shape): int return 1; Shape shape = new Shape(); Polygon
Version 1.0. 2013-02-13 Testteam 4 Testledare: Patrik Bäck
Version 1.0-2013-02-13 Testteam 4 Testledare: Patrik Bäck 0 Sammanfattning Testplanen är utarbetad som ett svar på Konsumentverkets förfrågningsunderlag avseende upphandling av ett nytt budget- och skuldsaneringssystem,
TDDE10 TDDE11, 725G91/2. Objektorienterad programmering i Java, Föreläsning 4 Erik Nilsson, Institutionen för Datavetenskap, LiU
TDDE10 TDDE11, 725G91/2 Objektorienterad programmering i Java, Föreläsning 4 Erik Nilsson, Institutionen för Datavetenskap, LiU På denna föreläsning: Ett större exempel på OOP Objektorienterad Analys (OOA)
+Överskådlighet Normalt sätt blir ett program skrivet i det procedurella paradigmet överskådligt. Modifikationer på delproblem kan ske med lätthet.
Uppgift 1 Ett programmeringsparadigm är i grund och botten ett sätt att arbeta, ett sätt att möta problem. Det finns flera olika paradigm där varje paradigm har sina egna styrkor och svagheter. Det som
Föreläsning 12 Inspektionsmetoder. Rogers et al. Kapitel 15
Föreläsning 12 Inspektionsmetoder Rogers et al. Kapitel 15 Inspektionsmetoder Metoder som genomförs utan användare En eller helst flera experter utför en inspektion eller granskning Man utgår ifrån vedertagna
REGELVERK & HANDBÖCKER
1 (5) REGELVERK & HANDBÖCKER Innehåll sid. Uppdateringar/kompletteringar 2 Nyskrivning av rutiner 4 Gränsytan mellan systemsäkerhet och programvarusäkerhet 5 2 (5) Uppdateringar/kompletteringar Software
Utvärdering. Övergripande (1) Med/utan användare. Övergripande (2) Fredag 1 oktober F1. Ann Lantz - Anna Swartling -
Utvärdering Fredag 1 oktober 13-15 F1 Ann Lantz - alz@nada.kth.se Anna Swartling - ast@kth.se Övergripande (1) Av den verkliga världen: Hur agerar man, vad händer? Hur används teknik? Beteendevetenskapliga
XP-projekt: En fördjupning
XP-projekt: En fördjupning Extreme Programming Martin Karlsson marka@itn.liu.se K7522 011 36 34 63 Fem värden Kommunikation Var öppna Var ärliga Ta konflikter Diskutera Tag beslut Tag ansvar Kräver feedback,
Granskning av gränssnitt. Mattias Arvola
Granskning av gränssnitt Mattias Arvola 2 Att skapa interaktiva system Identifiera krav Utforma alternativ Ta fram prototyper (eller annan illustration av system) Utvärdera 3 Mål med utvärderingen Revidera,
Agil testning i SCRUM
Agil testning i SCRUM Petter Salomonsson Petter.salomonsson@addq.se Tel: 0708-398435 Kort presentation AddQ Consulting AB tydlig fokus på test och kvalitetssäkringstjänster erbjuder mycket erfarna konsulter
SAST Q1. Som att börja arbeta på ett nytt jobb. Testautomatisera med Modell-baserad testning
SAST Q1 Som att börja arbeta på ett nytt jobb Testautomatisera med Modell-baserad testning Christina Nordström Kristian Karl Christina Nordström Test sedan 1996 Aldrig testautomatiserat Enhetschef Testenheten
Praktikum i programvaruproduktion
Praktikum i programvaruproduktion Introduktion Föreläsare/Ansvarig: Pontus Boström Email:pontus.bostrom@abo.fi Rum A5055 Assistent: Petter Sandvik Email: petter.sandvik@abo.fi Rum: A5048 Föreläsningar:
Olika syften. TDDD60 användbarhetstest. När passar vilken typ? Med eller utan användare
TDDD60 användbarhetstest Olika syften Olika typer av metoder Mått på användbarhet/kravuppfyllelse Olika syften Hitta användbarhetsproblem för att förbättra (mål: åtgärda problem, förbättra produkten) Formativ
DI Studio 4.3 - nyheter
DI Studio 4.3 - nyheter Sofie Eidensten och Patric Hamilton Copyright 2010 SAS Institute Inc. All rights reserved. 2 Varför DI Studio Snabbare utveckling Enklare underhåll Gör det överskådligt 3 Nyheter
Projektplan, Cykelgarage
Projektplan, Cykelgarage Johan Anderholm, (dt08ja5@student.lth.se) Jon Andersen (dt08ja8@student.lth.se) Marcus Carlberg (dt08mc4@student.lth.se) Simon Ekvy (dt08se2@student.lth.se) Stefan Johansson (dt08sj7@student.lth.se)
Utforskande testning
Utforskande testning SAST Stockholm, 2012-02-23 Rikard Edgren Qamcom Karlstad rikard.edgren@qamcom.se Utforskande testning är en stil för programvarutestning som betonar varje testares frihet och ansvar
Tentamen ID1004 Objektorienterad programmering October 29, 2013
Tentamen för ID1004 Objektorienterad programmering (vilande kurs), 29 oktober 2013, 9-13 Denna tentamen examinerar 3.5 högskolepoäng av kursen. Inga hjälpmedel är tillåtna. Tentamen består av tre sektioner.
Classes och Interfaces, Objects och References Objekt-orienterad programmering och design (DIT952) Niklas Broberg, 2016
Classes och Interfaces, Objects och References Objekt-orienterad programmering och design (DIT952) Niklas Broberg, 2016 Abstract class En abstract class är en class som inte kan skapa några objekt. Syfte:
Tentamen: INTE 2011-10-26
Tentamen: INTE 2011-10-26 Det enda godkända hjälpmedlet är ett exemplar av den personliga fusklappen som lämnats in som inlämningsuppgift tre på kursen. På nästa sida finns ett utdrag ur instruktionerna
TDDC74 - Projektspecifikation
TDDC74 - Projektspecifikation Projektmedlemmar: Namn Efternamn abcde123@student.liu.se Namn Efternamn abcde123@student.liu.se Handledare: Handledare handledare@ida.liu.se eller handledare@student.liu.se
Testplan Autonom truck
Testplan Autonom truck Version 1.1 Redaktör: Joar Manhed Datum: 20 november 2018 Status Granskad Kim Byström 2018-11-20 Godkänd Andreas Bergström 2018-10-12 Projektidentitet Grupp E-post: Hemsida: Beställare:
Classes och Interfaces, Objects och References, Initialization
Classes och Interfaces, Objects och References, Initialization Objekt-orienterad programmering och design (DIT953) Niklas Broberg/Johannes Åman Pohjola, 2018 Abstract class En abstract class är en class
Enhetstester på.netplattformen
Enhetstester på.netplattformen Praktikfall ur verkligheten Copyright Prolore 2007. All Rights Reserved. Viktor Laszlo Vem är jag 11 år inom test Prolore: specialiserat på Testautomatisering, Prestandatest
Date Version Description Author. 1 Introduktion s Översikt av Vårdguiden 1.2 Syfte och Omfattning Inkluderat
Slutrapport Vårdguiden SR.Vg_v.1.0 Date Version Description Author 2017-03-17 1.0 Slutrapport gällande för TP.Vg_v.1.0, TS.Vg_v.1.0, TR.Vg_V.1.0 och AvR.Vg_v.1.0 Lisa Millhus Innehåll 1 Introduktion s.2
Kurser och seminarier från AddQ Consulting
Kurser och seminarier från AddQ Consulting Med fokus på kvalitet och effektivitet bidrar vi till att underlätta människors vardag. Kompetensutveckling är nyckeln till framgång för dig som jobbar med test,
Formell Verifiering. Hur vet man att ett system fungerar korrekt? Lisa Kaati
Formell Verifiering Hur vet man att ett system fungerar korrekt? Lisa Kaati Innehåll Motivering Formell verifiering Modellkontroll (model checking) Verifiering av kod Forskning Dator system finns överallt
Teknisk testning för otekniska testare
Teknisk testning för otekniska testare SAST, 16-feb-2017 Rikard Edgren Nordic Medtest rikard.edgren@nordicmedtest.se Nordic Medtest utför testning och kvalitetssäkring och bidrar till mer användbar och
Arbeta i projekt. Anders Hessel ITP-projekt Uppsala Universitet
Arbeta i projekt Anders Hessel 2003-02-05 ITP-projekt Uppsala Universitet Varför Projekt? Vad är projekt? Varför projekt? Svårighet? Undervisning Bilda projektgrupp Formell grupp - har ledare Roller Konflikter
Projekt i programmering 1 (ver 2)... 2 Projektidé... 2 Planering... 2 Genomförande... 2 Testning och buggar... 3 Utvärdering... 3 Planering...
Projekt i programmering 1 (ver 2)... 2 Projektidé... 2 Planering... 2 Genomförande... 2 Testning och buggar... 3 Utvärdering... 3 Planering... 4 Bussen (projektförslag)... 5 Bakgrund... 5 Klassen Buss
Från vaga testuppdrag till förankrad teststrategi
Från vaga testuppdrag till förankrad teststrategi Dataföreningen Stockholm, 18-okt-2012 Rikard Edgren Qamcom Karlstad rikard.edgren@qamcom.se Agenda 1. Testuppdrag 2. Projektomgivning 3. Produktelement
Användning av testautomation inom Extendas utvecklingsorganisation
Testautomation Användning av testautomation inom Extendas utvecklingsorganisation Agenda Presentation av Extenda Vad är en POS? Test av POS Automatiska tester Sammanfattning 2 Kort historik 1982 Extenda
Mål med lektionen! Repetera och befästa kunskaperna.
Entity Framework Mål med lektionen! Repetera och befästa kunskaperna. Vad lektionen omfattar Repetera och gå igenom kursen lite snabbt. Vilka problem vill vi lösa? Vi arbetar med Webbapplikationer Vi kommer
Programmering = modellering
Programmering = modellering Ett datorprogram är en modell av en verklig eller tänkt värld. Ofta är det komplexa system som skall modelleras I objektorienterad programmering består denna värld av ett antal
Test specifikation. SF Bio App. Författare: Zina Alhilfi Datum: Version: v1,0. Granskad: Klar Ref: Testplan_v1.
Test specifikation SF Bio App. Författare: Zina Alhilfi Datum: 2017-03-07 Version: v1,0 Granskad: Klar Ref: Testplan_v1.0 Status: Klar 1. Introduktion 1.1 Syfte och omfattning 1.2 Terminologi 1.3 Referenser
F4 Testning och Parprogrammering i XP EDAF45 Programvaruutveckling i grupp Projekt Boris Magnusson,Datavetenskap, LTH
F4 Testning och Parprogrammering i XP EDAF45 Programvaruutveckling i grupp Projekt Boris Magnusson,Datavetenskap, LTH 1 XP:s Deltekniker (Practices) 1. Planering Planeringsspelet Regelbundna releaser Hållbart
Belastningstester med Visual Studio 2008 - Gränssnittet
Belastningstester med Visual Studio 2008 - Gränssnittet Belastningstester med Visual Studio 2008 - Gränssnittet ANVÄNDARGRÄNSSNITTET Belastningstester med Visual Studio 2008 - Gränssnittet Test typer Alla
Verktyget FindBugs. Djupstudie i kursen EDA 270 Coachning av programvaruteam. Christofer Bach dt05cb6 Daniel Nilsson dt05dn4. Lunds Tekniska Högskola
Verktyget FindBugs Djupstudie i kursen EDA 270 Coachning av programvaruteam Christofer Bach dt05cb6 Daniel Nilsson dt05dn4 Lunds Tekniska Högskola 15 feb 08 1. Sammanfattning Denna djupstudie kommer att
Föreläsning 4, Användbarhet, prototyper
Föreläsning 4 Användbarhet och prototyper Kapitel 5-7 i Stone et al. Mer om användbarhet Psykologiska principer avseende: Förväntningar En uppgift i taget Struktur för förståelse Känna igen eller komma
Länkade listor och automatisk testning
1 (6) Länkade listor och automatisk testning Algoritmer och datastrukturer Obligatorisk nr 3 Syfte Att ge träning i programmering av länkade listor på låg abstraktionsnivå med primitiv pekarmanipulering.
Utvärdering. Övergripande (1) Övergripande (2) Med/utan användare. Heuristisk utvärdering. Expertutvärdering. Måndagen den 29 september 8-10 F1
Utvärdering Måndagen den 29 september 8-10 F1 Ann Lantz Alz@nada.kth.se Anna Stockhaus Ast@nada.kth.se Övergripande (1) Av den verkliga världen: Hur används teknik på arbetsplatsen? Kan man förbättra design
Lunds Tekniska Högskola Datorarkitektur med operativsystem EITF60. Superscalar vs VLIW. Cornelia Kloth IDA2. Inlämningsdatum:
Lunds Tekniska Högskola Datorarkitektur med operativsystem EITF60 Superscalar vs VLIW Cornelia Kloth IDA2 Inlämningsdatum: 2018-12-05 Abstract Rapporten handlar om två tekniker inom multiple issue processorer
UML: Exempel. Ett modelleringsspråk. UML: Ansvar. UML: tre huvudanvändningar. Exempel: En klass position storlek. UML Unified Modelling Language
Ett modelleringsspråk : Exempel Fönster Klassnamn Unified Modelling Language Av Booch, Jacobson, Rumbaugh Exempel: En klass position storlek Attribut (instansvariaböe) Resultatet av en sammanslagning av
Överlagring, static, testning, formella metoder och undantag! Förelasning 13!! TDA540 Objektorienterad Programmering!
Överlagring, static, testning, formella metoder och undantag! Förelasning 13!! TDA540 Objektorienterad Programmering! Gränssnitt igen För att kunna ändra på olika delar av programmet utan att andra delar
Föreläsning 2. Objektorienterad analys och design. Analys: att modellera världen. Design: att strukturera program.
Föreläsning 2 Objektorienterad analys och design. Analys: att modellera världen. Design: att strukturera program. Vår process Kravbeskrivning (3 dagar). Enkel form av användningsfall (use cases). Analys
Att fatta rätt beslut vid komplexa tekniska upphandlingar
Att fatta rätt beslut vid komplexa tekniska upphandlingar Upphandlingsdagarna 2015 Stockholm 29 januari 2015 1 Inledning Den här presentation kommer att undersöka de vanligaste fallgroparna vid komplex
Deluppgift 2 Kravhantering a) (2p) När man diskuterar krav brukar man ange två olika typer av krav. Beskriv dessa och ge exempel.
Page 1 (5) Hemuppgift 1DV404 150115-150118 Deluppgift 1 Processmodeller a) (4p) Alla mjukvaruutvecklare följer någon form av utvecklingsprocess i sitt arbete. Diskutera vad organisationer brukar ange som
International Olympiad in Informatics 2011 22 29 July 2011, Pattaya City, Thailand Tävlingsuppgifter Dag 2 Svenska 1.3. Papegojor
Papegojor Yanee är fågelentusiast. Sedan hon läst om IP over Avian Carriers (IPoAC), har hon spenderat mycket tid med att träna en flock papegojor att leverera meddelanden över långa avstånd. Yanees dröm
Uppgift v1: Teststrategi i sammanhang Terese Berger. Teststrategi. Projekt CiviCRM. Version 0.9. Sida 1(7)
Teststrategi Projekt CiviCRM Version 0.9 Sida 1(7) Innehållsförteckning Referenser...2 Revisioner...2 1. Inledning...3 1.1 Uppgift...3 1.2 Bakgrund...3 1.3 Organisation...4 1.4 Granskning och godkännande...4
Verifiering & validering -
Verifiering & validering - INGENJÖRSPROCESSEN forts. METODIK ETSA01 VT13 Verifiering och validering rep. INGENJÖRSPROCESSEN METODIK ETSA01 VT13 JONAS WISBRANT 1 1 Från F3 Verifiering & Validering Verifiering
Inklusiv Design Design för Alla
Inklusiv Design Design för Alla Alla kan vara med! Design för Alla Vilka designar vi för? 2 Design för Alla Vilka designar vi för? 3 Design för Alla Vilka designar vi för? Perfekt syn Felfri Superstark