Merge branch 'master' of github.com:tkbremnes/Kompendie-TDT4242

Forelesning 1.md

@@ -19,7 +19,7 @@ From test to requirement
 : Why do we need this test?
 
 From requirement to test
-: Where is this requirement ested?
+: Where is this requirement tested?
 
 Når en skal endre/justere et krav an en også finne relevante tester.
 
@@ -43,11 +43,11 @@ Preskriptive statements
 : Enforced **solely** by the software-to-be. Formulert av fenomen som deles mellom programvare og miljø.
 : Programvare forstår dette via sensorer, handler med aktuatorer.
 
-Hvor mye skal være opp til brukeren, vhor mye skal styres av programvare?
+Hvor mye skal være opp til brukeren, hvor mye skal styres av programvare?
 
 ## Målorientering
 
-Prpgramvare, milø. Interaksjon melleom aktive komponenter kalles *aktører*.
+Programvare, milø. Interaksjon melleom aktive komponenter kalles *aktører*.
 
 Requirement
 : A goal under the *responsibility@ ofa single agent tin the sw-to-be
@@ -69,7 +69,7 @@ Multi-agent goal	Single-agent goal
 	* Increase/reduce
 * Behavioural goal
 	* System behaviour
-	* Agent behaviout
+	* Agent behaviour
 	* Achieve/Cease
 	* Maintain/Avoid
 

Forelesning 11/11.2.md

@@ -248,6 +248,7 @@ Use case map path
 ![UCM Path elements](img/ucm-path.png)
 ![UCM example: Commuting](img/ucm-path-example.png)
 ![UCM example: JSON](img/number.gif)
+[Cucumber – Cucumber testing](http://cukes.info/)
 
 ... cue eksempler i massemassevis
 

Forelesning 15/15.1.md

@@ -1,7 +1,7 @@
 # Regresjonstesting
 Regresjonstesting er testing gjort for å kontrollere at en systemoppdatering ikke reintroduserer feil som har blitt fikset tidligere. Dette gjøres via black-box-testing (for å teste funksjonalitet) og grey-box-testing (for å teste arktitekturen).
 
-Ettersom regresjonstester er ment å teste all funksjonalitet og alle forandringer vil slike tester være store. Av den grunn må regresjonstesting eksekveres og kontrolleres automatisk.
+Ettersom regresjonstester er ment å teste all funksjonalitet og alle forandringer, vil slike tester være store. Av den grunn må regresjonstesting eksekveres og kontrolleres automatisk.
 
 ## Automatisk regresjonstesting
 

Forelesning 15/15.2.md

@@ -3,24 +3,31 @@ Her brukes konseptet om en firewall for å redusere settet klasser eller kompone
 
 En firewall i denne sammenhengen er en separator mellom de klasser som beror på en klasse som endres fra resten.
 
-Dependency, encoding
+Det finnes to sentrale konsepter,Dependency og encoding.
+
+## Enkle regler for fire wall i et objektorientert system
 
 1. Gitt to suksessive versjoner av et objektorientert system, identifisér klasser som har blitt endret.
 2. Dersom en klasse er en del av et arvshierarki må en også anse etterkommere av den endrede klassen som endret.
 3. For hver endrede klasse, identifisér alle klasser som sender eller mottar meldinger til/fra den endrede klassen og inkludér de inne i firewallen.
+
+regel 4 og 5 identifiserer en utvidet fire wall
+
 4. Identifisér alle datastier til og fra den endrede klassen
 5. Finn alle eksterne klasser i den modifiserte klassens omfang og inkludér de i den utvidede firewallen
 
 
-Punkt 4 og 5 er en utvidet firewall.
-
 
 ![Testing firewall (TFW)](img/firewall.png)
 
 
 ## Dependency
-> Is the component dealing with the plain values of the input?
+To viktige spørsmål kommer opp her
+
+1. Benytter komponenten seg vanlige verdier av inputen?
+2. Må komponenten gjøre rede for hvordan denne inputen ble generert?
+
+Noen grunnregler for disse testee er at det bare skal bli brukt for å teste oppdateringer og endringer. Det antas også at det innledende testsettet og softwaren som er testet er av høy kvalitet.
 
-> Must the component account for how those inputs were generated?
 
 IKKE FERDIG

Forelesning 5/5 2.md

@@ -118,4 +118,76 @@ Vi ser også på testdata fra tre forskjellige utviklingsaktivteter:
 Disse utgjør høyresiden av V-modellen.
 
 ### Funn
-Det viser seg at Paretos regel (om at 80% av effekten kommer fra 20% av årsakene) gjelder i det fleste tilfeller for både defektkategoriene og triggerne. Det vil si at omtrent 20% av defekttriggerne utløser 80% av defektene. 
+Det viser seg at Paretos regel (om at 80% av effekten kommer fra 20% av årsakene) gjelder i det fleste tilfeller for både defektkategoriene og triggerne. Det vil si at omtrent 20% av defekttriggerne utløser 80% av defektene.
+
+De vanligste defektene er relatert til enten dokumentasjon eller funksjon. Grensesnittdefekter er den eneste defektkategorien som kom på topp tre av de vanligste defektene både etter testing og etter inspeksjon. Samtidig er "bivirkninger" den eneste defekttriggeren som finnes blandt både testing- og inspeksjonsresultatene.
+
+## Inspeksjon som en sosial prosess
+Man må ta høyde for at inspeksjoner også inneholder en menneskelig faktor, og ikke bare tekniske detaljer. Det er viktig å tenke på hvordan personer:
+
+	* Samhandler
+	* Samarbeider
+
+### Datakilder
+Det har blitt gjennomført to eksperimenter relatert til de sosiale prosessene i inspeksjoner:
+
+	* UNSW - tre eksperimenter med 200 studenter, hvor fokuset var gevinst vs tap ved prosessen
+	* NTNU - to eksperimenter:
+		* NTNU 1, 20 studenter fordelt på grupper hvor de bruker sjekklister
+		* NTNU 2, 40 studenter 
+
+#### Data fra UNSW-eksperimentet
+Programmene som ble inspisert bestod av:
+	* 150 linjer lang kode med 19 defekter
+	* 350 linjer lang kode med 38 defekter
+
+	1 Hver student inspiserte koden individuelt og leverte inn hver sin rapport
+	2 Studentene ble tilfeldig plassert på grupper med tre personer, til sammen 40 grupper
+	3 Hver gruppe inspiserte koden sammen og leverte en rapport
+
+For å forstå UNSW-eksperimentet, må man forstå to termer:
+	* Nominell gruppe - en gruppe personer som senere vil delta i en ekte gruppe, men som foreløpig jobber alene
+
+	* Ekte gruppe - en gruppe personer som kommuniserer direkte med hverandre, og samarbeider
+
+Fra dette eksperimentet fant man at gruppen som enhet ikke fant 7 av defektene som enkeltpersonene fant. Samtidig fant de 5 defekter som enkeltpersonene ikke fant. Det vil si at prosessgevinst er 5 defekter, mens prosesstap er 7 defekter. Dette viser bare at det er store sjanser for at man ikke finner visse defekter ved å samarbeide i grupper, men samtidig er det store muligheter for å finne flere andre defekter.
+
+Etter å ha analysert alle dataene fra dette eksperimentet, fant man at sannsynligheten for prosesstap (dvs. de defektene man taper/mister ved å bruke grupper) er 53%. Sannsynligheten for prosessgevinst (dvs. de ekstra defektene man finner ved å bruke grupper) var 30%. Man kan derfor konkludere med at det å bruke grupper ikke har så stor nytteverdi, og at man like gjerne kan droppe denne delen.
+
+Det var en 10% sannsynlighet for at studentene rapporterte om defekter i rapporten, til tross for at ingen fant disse defektene. De defektene de fant var det 80-95% sannsynlighet for at de nevnte i rapportene.
+
+Grunnen til at defekter som blir funnet på egenhånd blir forkastet i grupperapporten, kan være at majoriteten i gruppa bestemmer. Hvis et gruppemedlem finner en feil som ingen andre finner, kan det hende det gruppemedlemmet gir etter for gruppepress.
+
+	* Ved prosesstap finner man mange nye defekter, men fjerner også mange. 
+	* Ved prosessgevinst finner man mange nye defekter, men fjerner bare none få.
+	* Ved prosess-stabilitet finner mange defekter og fjerner omtrent like mange
+
+Man kan dele gruppene opp i to deler:
+	* Prosessgevinst
+	Alles bidrag teller, og man finner mange nye defekter
+	* Prosesstap
+	Gruppepress, finner få nye defekter
+
+#### Data fra NTNU1-eksperimentet
+Det var som sagt 20 studenter med i eksperimentet, som inspiserte et program på 130 kodelinjer. Programmet inneholdt 13 defekter.
+
+	1 Gruppene bestod av to, tre eller fem studenter
+	2 Halve gruppe brukte en skreddersydd sjekkliste
+	3 Hver gruppe inspiserte koden og leverte en rapport
+
+Gruppestørrelsen og bruken av sjekklister var hovedfokuset under eksperimentet. Dessuten ble effekten av kombinasjonen av de to også undersøkt.
+
+Resultatene viser at de største gruppene fant fire flere defekter enn de minste gruppene. Bruk av sjekkliste ga ikke utslag på hvor mange defekter gruppa fant. De minste gruppene som brukte sjekklister fant to flere defekter enn de største gruppene som brukte defekter. Standardavviket gjør at man kan utelukke alt annet enn gruppestørrelsen.
+
+#### Data fra NTNU2-eksperimentet
+40 studenter som inspiserte et program på 130 kodelinjer. Programmet inneholdt 12 defekter.
+
+	1 20 PhD-studenter og 20 ingeniørstudenter på tredjeåret
+	2 Hver student inspiserte koden individuelt og leverte inn rapport
+
+Defektene gikk under følgende kategorier:
+	* Feil kode - f.eks. feil parameter
+	* Ekstra kode - f.eks. ubrukte variabler
+	* Manglende kode - f.eks. ingen exception handling
+
+De med minst erfaring og som nylig har kodet er bedre til å finne manglende kode, mens de med litt mer ingeniørutdanning var flinkere til å finne overflødig kode. Erfaring hadde ingen innvirkning på hvor flinke studentene var på å finne feil kode. 

README.md

@@ -9,6 +9,7 @@ Diskusjoner skjer på IRC - #etkultnavn på freenode.
 
 ## Kontributører
 [kartoffelmos](http://kartoffelmos.net)
+
 [ekun](http://glittum.org)
 
 ## For å bygge
@@ -19,7 +20,7 @@ Installere Ruby
 Kjøre `ruby build.rb`
 
 ## Ferdige kapitler
-Ingen
+15, 12, 11, 3(under review), 5 (5.2 må korrekturleses)
 
 ## Gjenstår å gjøre
 * Alle kapitler