“Industrial approach for testing (2)” Teknikker og verktøy for testing i et Scrum-team Utdrag fra Skatteetatens teststrategi Sten Aksel Heien Skatteetatens.

Slides:



Advertisements
Liknende presentasjoner
v/Tormod Engebu, IKAVA KDRS 13. november 2013
Advertisements

TDD over BDD why and how XP meetup Johannes Brodwall, Programming artist Steria Norway.
PUG Norway – 12. nov 09Thomas Skjørten / Jan Kolstad.
Fra idè til ferdig produkt
Extreme Integration Oslo XP meetup, 22. mars, 2011 Johannes Brodwall.
Kontrollstrukturer (Kapittel 3)
”Verifiser Forventet Funksjonalitet”
Test-Drevet Utvikling Bowling med
Målinger generelt •I et moderne samfunn brukes målinger i mange ulike sammenhenger •Eksempler: –Sammenligne priser, lønninger –Høyde: størrelse på klær.
1 Forelesning nr 7 Statisk dokumentasjon TDT4285 Planlegging og drift av IT-systemer Vår 2005 Anders Christensen, IDI.
Leselos Ordforråd/metakognisjon
Unit testing Gruppe 2: Kjartan Haugen Jon Gunnar Bjørkmo
Test-Drevet Utvikling Bowling med extremeprogramming.no.
Behaviour Driven Development, Steg 1: - Ikke tenk som en utvikler Jan Fredrik Stoveland , Smidig 2009.
Tjenestebasert design med dynamiske proxyer og Spring Bjørn Vidar Bøe, JavaZone 2005.
Ideutvikling - Problemdefinisjonen. Hva gjør de erfarne problemløserne? •Samler og analyserer informasjon og data •Snakker med mennesker som kjenner problemet.
Softwarearkitektur og kvalitet
Programmering av dynamiske websider i C# - hva er det, og hvordan undervise? Tom Heine Nätt.
Databasehåndtering med MySQL
© Lars-Erik Kindblad.  Et platformuavhengig verktøy for å automatisere build prosesser.  Støttes og drives av Apache Software Foundation.  Kommer ferdig.
Generelt I/O if/else Funksjoner Lists Løkker Dictionaries Annet Listebehandling Klasser Python med noen algdat-anvendelser Åsmund Eldhuset asmunde *at*
1 Oppgave gjennomgang Kap Oppgaver -Kap 12: 1, 2, 3, 5, 7, 8, 11, 18, 19.
Hvordan skrive en effektiv kravspesifikasjon gsfc. nasa
Verifikasjon og validering
Hvordan skrive en god utredning?
Mange IT-prosjekter kunne med fordel vært drevet mer som en Lean Startup.
  © Steria FitNesse som nyttig verktøy Smidig FitNesse som nyttig verktøy Anders Vindvad.
Lederen som coach Jeg kan ikke lære noen noe,
Hvordan uttrykke krav Kapittel 4.4. Innledning Målet er å samles rundt ett entydig språk som ikke kan misforståes eller feiltolkes. Gjør sporbarheten.
Testing av system Gruppe 6 Henrik Bækhus Morten A. Iversen Mathias Bondeson Gunnar K. Kulleseid Svein Ivar Kristiansen Ronny Hulthin.
Teknikker for å bedre design- prosessen -Design by contract -Prototyping design -Fault-tree analyses.
Improving Products Gruppe Presenteres av : Hege-Kristin Johansen Herman Kolås Marianne Ates Marit Finden Jonas Lillevold André Johansen Tom.
Automated Testing Tool & When to Stop Testing
Java sertifisering - testern tester test
Farvel til applikasjonsserveren Fra kompleksitet til kontroll.
  © Steria Å Lytte til koden Johannes Brodwall, Chief scientist, Steria Iterate 21. mai, 2010.
IT for Medisinsk sekretær Kai Hagali KVELD 4.  Siste rest kapittel 3  Kapittel 4  OPPGAVER  Neste gang Fletting Kai Hagali - Fredrikstad.
1 Organisering av kode (Kapittel 5). 2 Mål ● Forstå inkludering er og hvilken gevinst det gir ● Lære å utvikle egne funksjoner ● Forstå variablenes virkemåte.
How your choice of middleware product affects your testability IASA
Velkommen til Faglig Forum! :-). Problemstilling For lang feedbackloop under utvikling når man skal bygge og starte vortex og klikke seg fram til riktig.
Black box testing av webapplikasjoner
Publisering på verdensveven Kursdag 2 VÅFF, våren 2002.
Publisering på verdensveven Kursdag 3 VÅFF, våren 2002.
Innledning om HTML IT20 oktober Bakgrunn Konseptet WWW ble født i 1983 i CERN, Geneve Opphavsmann: Tim Berners-Lee, MIT Spre informasjon uavhengig.
Dynamiske nettsider PHP Del 1 – variable. PHP  PHP (Personal Home Page)  Fritt tilgjengelig programmeringsspråk  åpen kildekode  Plattformuavhengig.
Kommentarer og stil ”Dette suger!” ”Ne-hei!” ”Jo- hoo”, osv.
Andre funksjoner. Her kommer en beskrivelse av søkefunksjoner, knapper og annen funksjonalitet. 2.
Jæger: Robuste og sikre systemer INF150 Programmering mandag 18.9 Lesing av data fra fil og skriving av data til fil. Side 411 – 4.. Kap 4.
Å omfavne forandringer med ekstrem programmering(XP) Brukt i In140 Skrevet av Ola Bø Bygger på Kent Becks artikkel "Embracing change with extreme programming."
Veiledernes oppgave og rolle
Kontinuerlig kvalitetskontroll. Hvordan komme helt i mål.
BUCS Utfordringer og valg av fokus Tor Stålhane. Rammebetingelser Første spørreundersøkelse viser at det vi gjør må kunne: Brukes sammen med UML Passe.
En heuristisk evaluering avRelaxation Gjort av: ● Espen Solberg ● Geir Normann ● Leif Morten Kofoed ● Tommy Jansson.
Forstudie Nå situasjonen: dagens situasjon med ulemper og fordeler
Object  Klassen i java  Alle klasser arver fra denne om ikke noe annet blir spesifisert  ArrayList.add(Object instans)  Alle elementer formes til Object.
WEB og tilgjengelighet En kort intro. Tilgjengelighet/universell utforming Tilgjengelighet (fysisk) En side kan være tilgjengelig uten åvære UU, men UU.
Funksjoner og didaktikk
Registrering av testresultater fra mobiltelefon
Professor Guttorm Sindre Institutt for datateknikk og informasjonsvitenskap Programmering i Python.
Lokale variable Hvis vi trenger å ta vare på en verdi, inne i en metode kan vi definere en lokal variabel: int amount = 0; vi må fortelle hvilken type.
Datakortet – Modul 3 Word 2003, Kap Modul 3.
Lær å logge inn til offentlige tjenester med BankID på mobil
Kom i gang med Python Pål Hellesnes SYSTEMUTVIKLER
Lær å logge inn til offentlige tjenester med BankID på mobil
IN1000-seminar høsten 2017 Henrik H. Løvold
Spillutvikling Introduksjon til spillutvikling i Processing
JourneySwipe.
Oppsummering, FINF4021 Dag Wiese Schartum.
Oppsummering – FINF1001 Departementer Direktorater / tilsyn Kommuner
Oppsummering FINF4021 Dag Wiese Schartum.
Utskrift av presentasjonen:

“Industrial approach for testing (2)” Teknikker og verktøy for testing i et Scrum-team Utdrag fra Skatteetatens teststrategi Sten Aksel Heien Skatteetatens IT- og servicepartner (SITS) – Kompetansesenter, Grimstad Twitter: sten_aksel / Google+:

Prinsipper og teknikker Forstå hva vi skal lage BDD - oppførsel-drevet utvikling (Behaviour Driven Development) Spesifikasjon vha. eksempler (Specification by Example) TDD - testdrevet utvikling (Test Driven Development)

Prinsipp: Utenfra og inn «Epic»

Roller

Teknikk: Forstå hva vi skal lage BDD - oppførsel-drevet utvikling Gode (nok) spesifikasjoner (brukerhistorier og scenarier) Workshop med interessenter Avklare unøyaktigheter Legge til “manglende” scenarier (og brukerhistorier) Detaljere spesifiksjonen vha. eksempler Felles for alle roller i Scrum-teamet

Prinsipper og teknikker Forstå hva vi skal lage og lage testene først Alle i teamet tar ansvar for testing Automatisering av testene Manuell utforskende testing

Teknikk: Testdrevet utvikling (TDD) Automatiserte kravtester -Brukerhistorier og scenarier steg-for-steg Automatiserte enhetstester - lavnivå tester for koden (klasser/metoder) Felles for alle roller i Scrum-teamet

Viktige mål for testing og valg av verktøy Klart, konsist og lesbart Fokus på: - kontekst - stimuli - forventninger Produktivitet

Verktøy Cucumber - Krav-/Akseptansetesting Spock/JUnit - Enhetstesting PIT / pitest - Muteringstesting

Cucumber et verktøy for krav-/akseptansetesting... som støtter spesifikasjon vha. eksempler/BDD... der brukerhistorier og scenarier (Gitt/Når/Så) gjøres kjørbare … slik at systemet får en kjørbar spesifikasjon og vi oppnår god sporbarhet fra krav til kode

Gherkin Gherkin er fellesbetegnelsen på «språket» BDD testene skrives i. Det lar oss skrive tekstlige beskrivelser av forretningsregler slik fagpersoner vil kunne uttrykke dem med sine domenespesifikke ord og uttrykk. Gherkin tjener to formål - dokumentasjon og automatiserte tester.

Gherkin gramatikken Feature Background Scenario Scenario Outline Examples (eller Scenarios) Given When Then And But | (benyttes for å definere tabeller) """ (benyttes for å definere strenger med flere linjer #(benyttes for kommentarer) Egenskap Bakgrunn Scenario Scenariomal Eksempler Gitt Når Så Og Men tilgjengelig for ca. 40 språk -selvfølgelig også for norsk!

Brukerhistorer og scenarier legges sammen med koden – i en «feature» fil (ren tekst) (fra GS-Kontroll_av_oppgavegiver.feature)

Brukerhistorer og scenarier legges sammen med koden – i en «feature» fil (ren tekst) (fra GS-Kontroll_av_oppgavegiver.feature)

Cucumber stegdefinisjoner gjør stegene i scenariene kjørbare vha. regulære uttrykk (fra StepDefinitionLeveransebehandling.java) Hvert steg i scenariet er testbart

Cucumber stegdefinisjoner gjør stegene i scenariene kjørbare vha. regulære uttrykk (fra StepDefinitionLeveransebehandling.java)

Cucumber stegdefinisjoner gjør stegene i scenariene kjørbare vha. regulære uttrykk (fra StepDefinitionLeveransebehandling.java)

Assertere i felleskode (magnet-felles) hjelper med sjekk av resultat (fra StepDefinitionLeveransebehandling.java)

Cucumber kjører vha. JUnit Runner

Roller

Spock et testrammeverk... basert på Groovy... for Java og Groovy appliksjoner (++) … kompatibel med din IDE (kjører vha. JUnit Runner) lett å lære... hvis du allerede kan Java & JUnit

Spock vil... Redusere antall linjer testkode Gjøre testene mer lesbare Gi lesbar feedback i sin feil-diagnostikk Forenkle mocking og stubbing La testene bli “spesifikasjoner” Gjøre testing morsomt / morsommere

Spock benytter etiketter (labels) given: / setup: forutsetninger, data (oppsett) (kan ikke repeteres) setup er alias for given (alltid første etikett) when:aksjoner som fører til endring (stimuli) then:forventet endring (respons) expect:forkortet alternativ for kombinasjonen when & then where:for parametrisering av input-data (må være siste etikett) and:“sminke” for ytterligere oppdeling i mindre “blokker” cleanup:opprydding (vil alltid bli kjørt)

… som gir lesbare tester!

Spock har suveren feil-diagnostikk

Innebygget mocking/stubbing … og fortsatt lesbare tester!

“Spockify your JUnit tests” på 1, 2, 3 0. endre filnavn fra java til groovy 1. extends Specification bruk Spock etiketter (given, when, then, etc.)

PIT / pitest - Muteringstesting 1. Kjør testene (grønt) 2. Endre kildekoden (ikke testen) 3. Kjør testene igjen 4. Noen tester bør feile Hvis ending ikke medførte testfeil, så er ikke koden dekket av test. Ellers, er kildekoden dekket av test.

PIT / pitest - Muteringstesting FØR: if ( a < b ) {... } if ( altErOK() ) {... } ETTER: if ( a <= b ) {... } if ( ! altErOK() ) {... }

Referanser Cucumber: Spock: pitest: