Test
Download
1 / 32

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


  • 129 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?

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha

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 agile projekter

  • projekterfaringer fra Thomas Kauders,

    Sr. Test 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?

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

  • Hvad er ”kernen” i testledelse og test?


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?

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?

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

Definere produktets acceptkriterier gennem konsesubaseret dialog mellem interessanter


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 ”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

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


  • 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


  • 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,


  • 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


  • 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.


  • 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


  • 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


  • 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


  • 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

Finde de væsentligste for kunden fejl


  • 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

3 Understøtte process for hurtig rettelse af defekter


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?

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


  • 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


----


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

  • 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

  • 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

  • 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

  • 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

  • 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

  • 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.


ad
  • Login