Test
This presentation is the property of its rightful owner.
Sponsored Links
1 / 32

Test i a gile projekter projekterfaringer fra Thomas Kauders, PowerPoint PPT Presentation


  • 78 Views
  • Uploaded on
  • Presentation posted in: General

Test i a gile projekter projekterfaringer fra Thomas Kauders, Sr. T est Manager og Quality Delivery Manager. Om mig. Hvad koster en Program Test Manager?. 9 mndr x 140 timer x 1000,- kr = 1.260.000 kr,-. Hvorfor vil man betale disse penge?

Download Presentation

Test i a gile projekter projekterfaringer fra Thomas Kauders,

An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -

Presentation Transcript


Test i a gile projekter projekterfaringer fra thomas kauders

Test i agile projekter

  • projekterfaringer fra Thomas Kauders,

    Sr. Test Manager og Quality Delivery Manager


Om mig

Om mig


Hvad koster en program test manager

Hvad koster en Program Test Manager?

9 mndr x 140 timer x 1000,- kr =

1.260.000 kr,-

  • Hvorfor vil man betale disse penge?

  • Hvad får man for disse penge – hvad er værdien?

  • Hvad er ”kernen” i testledelse og test?


Hvorfor vil man betale disse penge

Hvorfor vil man betale disse penge?

Der er behov for test, fordi

  • Det er dyrt at være usikker på produktets kvalitet, da

    • negative overraskelser i produktion og quick fixes er tit omkostningsfulde

  • Der er dyrt at have fejl i produktet, da

    • fejl forsinker aflevering

    • medfører fejl i produktion og relaterede forretningsprocesser (fejlregistrering, fejlfakrurering, kundesiv)

      Fejl opstår i alle produkter, også med de beste udviklerressourcer, da det er menneskeligt at fejle


Hvad f r man for disse penge hvad er v rdien

Hvad får man for disse penge – hvad er værdien?

Værdien af test kommer af

  • Forudsigelse af produktets kvalitet

    • på basis af målbare og operationaliserede acceptkriterier samt enighed i fortokninger af krav

  • Færre fejl i produktet

    • hurtigere afleveringer ved færre fejlrettelser undervejs

    • ingen kritiske fejl i produktion


Hvad er testens m l

Hvad er testens mål?

Proaktive

  • 1 Definere produktets acceptkriterier gennem konsesubaseret dialog mellem interessanter

    Reaktive

  • 2 Finde de væsentligste for kunden fejl

  • 3 Understøtte process for hurtig rettelse af defekter

  • 4 Informere interesenter om produktets kvalitet (=i hvilket grad acceptkriterier er opfyldt), så der kan træffes en beslutning om release på de mest faktuelle grundlag

    TM rolle er at sikre opnåelse af disse mål


Hvordan opn r vi disse m l 1

Hvordan opnår vi disse mål? 1

Definere produktets acceptkriterier gennem konsesubaseret dialog mellem interessanter


Produktet det handler om viden 1

Produktet – det handler om viden 1

  • Softwareudvikling handler om viden

  • En destillationsprocess hvor erfaring og viden

    udkrystalliseres til et produkt

  • Viden kommer fra mange steder/afdelinger/

  • interessenter


Viden fra forskellige brugere grupper interessanter 1

Viden fra forskellige brugere/grupper/interessanter 1

  • Viden ”bor” og er uadskillelig fra de grupper som benytter sig af denne viden.

  • Udenfor disse grupper er viden blot informationer som er værdiløse

  • Grupperne kaldes ”Communities of Practice”

  • Under softwareudvikling formidler forskellige grupper af

    mennesker deres viden til hinanden for at produktificere det

  • Indbyrdes har gruppen fællse sprog, forståelse, mål

  • Kommunikation (vidensudveksling) er et problem mellem grupper

  • God vidensudveksling kræver

    • Brokere; mennesker med et ben i hver lejr

    • Objekter – fysiske artifakter at samles om at fortolke

  • Fejl opstår som følge af (mangende) interaktioner mellem CoPs


Hvad er fejlkilderne 1

Hvad er fejlkilderne? 1

  • Kan mitigeres – derfor er det vigtigt at Definere produktets acceptkriterier gennem konsesubaseret dialog mellem interessanter


Test i a gile projekter projekterfaringer fra thomas kauders

  • Definere målbare accept/exit kriterier 1

Hvorfor?

  • Testens rolle er at måle om produktet lever op til aftalte acceptkriterier – i det daglige kaldet krav.

  • Men krav er amorfe er op til fortolkning.

  • En testcase er en fortolkning af kravet OG den er altid binær – Ja/Nej - PASS/FAIL

  • Et testsæt kan således entydigt afgrænse produktet / leverancen. Når alle testcases i testsættet er PASSed = produktet klar.

  • KUN testen kan definere entydige exit kriterier.

  • Hvis udviklere kender ExpectedResult på forhånd kan de kode efter dem og

    fejl kan forebygges!

    Testcase/testset = accept kriterier

Krav

Testsæt


Test i a gile projekter projekterfaringer fra thomas kauders

  • Definere målbare accept/exit kriterier 1

  • Opdelig af et system i ikke overlappende dele

P1

P2

P3

P4

P5

P6

P7

  • For at gøre systemet testbart skal det opdeles i partitioner. En partition er et levertbart systemkomponent, modul eller opgave,


Test i a gile projekter projekterfaringer fra thomas kauders

  • Definere målbare accept/exit kriterier 1

Eksempler på hvordan jeg har løst opgaven:

Ved at partitionere systemet i leverbare moduler kan jeg måle 0-100% levering af dele af systemet.

Ved at udarbejde et testsæt ALTID med sporing til krav.

Jeg gør testen målbar ved at hver testcase er udformet som et JA/NEJ spørgsmål og har ALTID et Expectedresult (Forventet resultat)

På den måde kan du måle om kravet/kravene er opfyldt når testcasen er PASSed.

TCs behøver ikke at være mange / detaljerede – men de skal ALTID have ExpectedResult


Test i a gile projekter projekterfaringer fra thomas kauders

  • Definere målbare accept/exit kriterier 1

Ved at udarbejde et testsæt ALTID med sporing til krav gør jeg mine krav målbare.


Test i a gile projekter projekterfaringer fra thomas kauders

  • Definere målbare accept/exit kriterier 1

Jeg gør testen målbar ved at hver testcase er udformet som et JA/NEJ spørgsmål og har ALTID et Expectedresult (Forventet resultat)

TCsbehøver ikke at være mange / detaljerede – men de skal ALTID have ExpectedResult


Test i a gile projekter projekterfaringer fra thomas kauders

  • Definere målbare accept/exit kriterier 1

The Agile twist

Krav = User Story

User Stories – nedbrydes i

et antal PBI-er.

For hver PBI udarbejdes

et antal TBIer med action og

expected result. Et PBI

fortolker User Story

Under Sprint planning udvælges færdige, elevante PBIer og TBI´er

Sprint planning = PBI planning + TBI planning


Test i a gile projekter projekterfaringer fra thomas kauders

  • Definere målbare accept/exit kriterier 1

Hvorfor?

Hvordan?

  • Inden fejlen opstår

    • (i teststrategier, testplaner) og testcases

    • Partitionering i leverancer

    • Et fuld test sæt = Alle krav fortolket som Ja/Nej spørgsmål


Test i a gile projekter projekterfaringer fra thomas kauders

  • Skabe konsensus om accept kriterier 1

Buy In; Forhåndsaccept af testcases som exit kriterier; CoP fælles kravfortolkning; give-and-take; Forhandling INDEN udvikling!

Accept-kriterie drevet udvikling


Hvordan opn r vi disse m l 2

Hvordan opnår vi disse mål? 2

Finde de væsentligste for kunden fejl


Test i a gile projekter projekterfaringer fra thomas kauders

  • Organisere test at finde afvigelser fra disse (fejl) 2

  • Inden fejlen opstår

    • i teststrategier, testplaner og testcases

  • Efter fejlen er opstået

    • i defekthåndtering


Hvordan opn r vi disse m l 3

Hvordan opnår vi disse mål? 3

3 Understøtte process for hurtig rettelse af defekter


Test i a gile projekter projekterfaringer fra thomas kauders

Fejl har som regel flere kilder (som sidder geografisk spredt)

Defecttracking

Defecttriageborard

Personlig ansvar – assign defekter til navngiven person

  • Skabe- og holde kommunikationskanaler åbne for at forebygge- og løse fundne fejl 3


Hvordan opn r vi disse m l

Hvordan opnår vi disse mål?

Informere interesenter om produktets kvalitet (=i hvilket grad acceptkriterier er opfyldt), så der kan træffes en beslutning om release på de mest faktuelle grundlag


Test i a gile projekter projekterfaringer fra thomas kauders

  • Inden fejlen opstår

    • i teststrategier, testplaner og testcases

  • Efter fejlen er opstået

    • i defekthåndtering

  • Informere alle løbende om pass/fail status for opfyldelse af de enkelte acceptkriterier 4


Test i a gile projekter projekterfaringer fra thomas kauders

----


Tiltag du b r kigge efter

Tiltag du bør kigge efter

Som kunde bør du kigge efter at din PTM har fokus på følgende opgaver:

  • Partitionering

  • Kravsporing

  • Testplan - tidsplan

  • TestDesign/TestCases

  • Rapportering, KPI / synliggørelse / kommunikation

  • Defekthåndtering / Fokusering


Eksempler fra mine projekter partitionering

Eksempler fra mine projekter Partitionering

  • Opdelig af et system i ikke overlappende dele

P7

P1

P2

P3

P4

P5

P6

P7

  • For at gøre systemet testbart skal det opdeles i partitioner. En partition er et levertbart systemkomponent, modul eller opgave,


Eksempler fra mine projekter kravsporing

Eksempler fra mine projekter Kravsporing

  • Testens formål at påvise afvigelser ift krav.

    • Krav kan være nedskrevne, strukturerede; eller ikke

  • Uanset skal testcases spores til krav

  • Når TCs er PASSED = kravet opfyldt


Eksempler fra mine projekter testplanl gning

Eksempler fra mine projekter Testplanlægning

  • Behøver ikke at være en testplan i word...

  • Skal ”tjene” projektet - levere informationer

    på rette tidspunkt

    [Vis fil]


Eksempler fra mine projekter testdesign testcases

Eksempler fra mine projekter Testdesign / Testcases

  • Testcases = acceptkriterier

  • Deres formål er at operationalisere de oprindelige krav

  • Ved at nedbryde dem til binære spørgsmål: PASS / FAIL::

  • NB: Uden konsensus om TC ingen konsensus om acceptkriterier


Eksempler fra mine projekter kpi rapportering

Eksempler fra mine projekter KPI / Rapportering

  • Hvad man måler det man optimerer

  • Færdiggørelsesgrad

  • Gns. Fejlretningstid

  • Antal åbne defekter per person(!)

  • Det handler om at synliggøre for relevante

  • beslutningstagere i hele organisationen hvad

  • status er og hvad det betyder for dem

  • Test er projektets øjne og ører: Rapporteringen fortæller

  • hvor er vi i forhold til vores mål (acceptkriterier).

  • NB: Uden konsensus om TC ingen konsensus om acceptkriterier


Eksempler fra mine projekter defekth ndtering

Eksempler fra mine projekter Defekthåndtering

  • Defekthåndtering handler om at rapportere kontrollere fremdrift på væsentlige fejl

  • KPI:

    • Gns. Fejlretningstid; Gns. liggetid per person; Antal defekter hos person

  • Det handler om at få mennesker at tale sammen og samarbejde.


  • Login