testausta vai määrittelyä? - tunitie21201/s2008/luennot/acceptancetestingtty.pdf ·...

© Ixonos OyjPublic 27.10.2008

Testausta vai määrittelyä?Hyväksymistestaus ja jatkuva integraatio ketterässä

ohjelmistokehityksessä

© Ixonos Oyj

Juha Inkinen

• Työnantaja: Ixonos marraskuusta 2007, sitä ennen Nokia Networks /

Nokia Siemens Networks

• Opiskellut TTY:llä ohjelmistotuotantoa, valmistunut DI:ksi 2006

• Diplomityö Nokia Networksille aiheesta

Acceptance Testing in an Agile Product Development Project

• Tutustunut agileen ja Scrumiin vuonna 2005 Nokia Networksillä

27.10.2008Public 2

Disclaimer:

Tämä esitys ei välttämättä edusta työnantajani mielipiteitä, vaan ainoastaan omia mielipiteitäni ja

kokemuksiani ohjelmistoalan ammattilaisena.

Disclaimer:

Tämä esitys ei välttämättä edusta työnantajani mielipiteitä, vaan ainoastaan omia mielipiteitäni ja

kokemuksiani ohjelmistoalan ammattilaisena.

© Ixonos Oyj27.10.2008Public 3

Sisältö ja tavoitteet

• Ketterät ohjelmistokehitysmenetelmät – kevyt johdatus aiheeseen

• Hyväksymistestaus

• Jatkuva integraatio

• Kokemuksia ketterästä ohjelmistokehityksestä

• Luennon jälkeen opiskelijoista…

• 25% vaihtaa alaa

• 25% pitää luennoitsijaa puolimielisenä

• 45% herää hyvin levänneinä

• 5% ymmärtää, mistä on kyse ja parantaa isona maailmaa

© Ixonos Oyj

Agile – ketterä ohjelmistokehitys

27.10.2008Public 4

Kuva: http://en.wikipedia.org/wiki/Image:Brittany_agility_jump.jpg, Ron Armstrong Lisenssi: cc-by-2.0 http://creativecommons.org/licenses/by/2.0/

© Ixonos Oyj

Itämaista mystiikkaa: Toyotan kangaspuut

• Lean Manufacturing

• Toyodan/Toyotan automaattiset kangaspuut 1800-luvun lopulla

• Just-in-time flow / Non-stock production / Pull system

• Autonomation / Zero inspection / Stop-the-line

• Eli suomeksi

• Pyritään pitämään varasto minimissään

• Tehdään työtä pienissä erissä

• Vikatilanteissa järjestelmä pysähtyy välittömästi

• Virheiden estäminen ennakolta

• Mutta tämä toimii teollisessa tuotannossa: ohjelmistokehitys on

enemmän tai vähemmän tuotekehitystä, ja tuotekehitys ei ole tuotantoa

– vaikka sana ohjelmistotuotanto yrittääkin niin vihjailla

27.10.2008Public 5

© Ixonos Oyj

Toyota Product Development System

• Systems Design by an Entrepreneurial Leader (Chief Engineer)

• Expert Engineering Workforce

• Responsibility-based Planning and Control

• Set-based Concurrent Engineering

• Jälleen suomennettuna

• (Tiimin) johtajana kokenut työntekijä (arkkitehti)

• Työntekijöistä koulutetaan oikeasti taitavia asiantuntijoita

• Vastuulliset työntekijät

• Optimaalisen ratkaisun etsiminen vaihtoehtoja rajaamalla

27.10.2008Public 6

© Ixonos Oyj

Lean Software Development

• Toyota Product Development System –periaatteita sovellettuna

ohjelmistokehitykseen [1]

1. Eliminate Waste

2. Build Quality In

3. Create Knowledge

4. Defer Commitment

5. Deliver Fast

6. Respect People

7. Optimize the Whole

27.10.2008Public 7

© Ixonos Oyj

Periaatteet

• Agile manifesto (http://agilemanifesto.org/)

27.10.2008Public 8

“Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan

That is, while there is value in the items on the right,

we value the items on the left more.”

© Ixonos Oyj

Menetelmiä

• eXtreme Programming

• Kent Beck

• Scrum

• Jeff Sutherland

• Ken Schwaber

• Agile Unified Process

• Scott Ambler

• Dynamic Systems Development Method

• DSDM Consortium

• + muita (lisää tulee jatkuvasti)

27.10.2008Public 9

© Ixonos Oyj

Mikä siis on agilen ydin?

• Kenelle ohjelmistoja tehdään?

• Ketkä tekevät ohjelmistoja?

• Muuttavatko ihmiset koskaan mieltään?

• Osaavatko ihmiset ennustaa?

• Onko ohjelmistokehitys ojankaivuuta?

• Onko ojankaivuu ojankaivuuta?

�Jatkuva muutostila ja odottamattomat yllätykset on pakko hyväksyä

• Tarjolla olevat muutoksenhallintamenetelmät:

• Silmät ja korvat kiinni ja koodataan ohi maalin

• Vaihdetaan alaa – esimerkiksi matematiikan lait eivät juuri muutu

• Reagoidaan muutokseen – hallitaan kaaosta pienissä paloissa

27.10.2008Public 10

© Ixonos Oyj

LOPUSTA ALKUUNHyväksymistestaus

27.10.2008Public 11

© Ixonos Oyj

Perusteet

• Miksi testata vasta iteraation tai tuotteen kehityksen lopussa

vaatimusten toteutumista?

• Testaaminen vasta lopussa johtaa testauksen ylityöllistämiseen

• Virheiden löytyminen ja korjaaminen lopussa johtaa aikataulujen

pettämiseen

• Seurauksena stressiä, ajan- ja rahanhukkaa ja paljon pahaa mieltä

• Voisiko tuotteen hyväksymistestata jo ennen sen olemassaoloa?

• Jos testeillä koetellaan kuinka hyvin ohjelmisto vastaa määrittelyä, niin

kannattaako tehdä mitään erillistä määrittelyä "tyhmänä" dokumenttina?

• Automaattiset hyväksymistestit ovat älykästä, ajettavaa

määrittelydokumentaatiota

29.3.2007Enter Information Classification here 12

© Ixonos Oyj

Kuka tai ketkä tekevät?

• Ketterässä ohjelmistokehityksessä määritellään tuotetta jatkuvasti

• Määrittelyä tehdään erittäin tiiviissä yhteistyössä asiakkaan kanssa

• Asiakkaan tulisi siis ensisijaisesti tehdä hyväksymistestit

• Ohjelmoijat rakentavat "telineet" (fixtures), joiden avulla testejä ajetaan

• Fixture toimii tulkkina testattavan järjestelmän ja testien välillä

• Jokainen saa laajentaa hyväksymistestikantaa

• Testaajat, kehittäjät, johtajat, harjoittelijat – jopa asiakas

• Versiointi: syytä välttää sisällön muuttamista toimintojen suhteen

iteraation aikana (asiakas)

• Virheiden ja erityistapausten osalta kannattaa laajentaa testejä

myös iteraation ollessa käynnissä

27.10.2008Public 13

© Ixonos Oyj

FixtureFixtureFixtureFixture

Hyväksymistestaus – tapoja

• Hyväksymistestaus on toiminnallisuuden testausta

• Testit voidaan ajaa käyttöliittymän kautta tai "yhtä kerrosta alempaa"

• Testeissä voidaan tarkistaa tietokannasta asioita yms.

27.10.2008Public 14

System Under Test

FixtureFixture

Acceptance Test CaseAcceptance Test Case

© Ixonos Oyj

Työkaluja

• Fitnesse: www.fitnesse.org

• Ward Cunninghamin Fit Frameworkin (http://fit.c2.com) päälle

rakennettu wiki

• Sekä Fit että Fitnesse on portattu Javasta muillekin

ohjelmointikielille

• Robot Framework: http://code.google.com/p/robotframework/

• Alun perin Nokia Networksilla (nyk. Nokia Siemens Networks)

kehitetty Python-kieleen pohjautuva hyväksymistestausframework

• Exactor, Canoo WebTest …

• Roll-your-own: tee oma domain-spesifinen kieli esim. Rubyllä tai käytä

esim. RSpeciä (http://rspec.info)

27.10.2008Public 15

© Ixonos Oyj

JATKUVA PALAUTEJatkuva integraatio

27.10.2008Public 16

© Ixonos Oyj

Perusteet

• Ketterä ohjelmistokehitys perustuu jatkuvaan muutokseen

• Julkaisuja tulee tehdä usein

• Kovassa vauhdissa tarvitaan vahvat turvalaitteet

• Integraatio – koko järjestelmän rakentaminen

• Automaattinen yksikkötestaus

• Muun tasoiset automaattiset testit (esim. hyväksymistestaus)

• Kehittäjät tarvitsevat nopeaa palautetta tekemistään muutoksista

• Ohjelmisto tulee pyrkiä pitämään jatkuvasti toiminta-/toimituskuntoisena

• Automaattisten hyväksymistestien raportteja lukemalla voidaan seurata

projektin etenemistä – Running Tested Features [2]

27.10.2008Public 17

© Ixonos Oyj

Tavoitteet

• Varmistetaan ohjelmiston osien yhteensopivuus

• Pienemmät muutokset kerralla versionhallintaan, ei märehtimistä

• Kehittäjä voi ajaa yksikkötestit ja tallentaa muutoksensa

versionhallintaan testien onnistuessa

• CI huolehtii yksikkö-, integraatio- ja hyväksymistesteistä

• Epäonnistumisen ainut rangaistus on tarve korjata (pieni) virhe

• Palautetta kehittäjille, muulle organisaatiolle ja jopa asiakkaalle

27.10.2008Public 18

© Ixonos Oyj

Mitä CI-ohjelmisto voi tehdä?

• Yleisimmin ajetaan seuraavat toiminnot (Java-web-sovellus):

1. Haetaan muuttunut koodin versionhallinnasta

2. Suoritetaan staattinen analyysi

3. Käännetään koodi ajettavaan muotoon

4. Instrumentoidaan koodi kattavuusanalyysiä varten

5. Ajaa yksikkötestit

6. Paketoidaan ohjelmisto asennettavaan muotoon

7. Asennetaan ohjelmisto sovelluspalvelimelle

8. Ajetaan hyväksymistestit asennetulle ohjelmistolle

9. Mikäli kaikki testit menivät läpi, niin leimataan koodiversio

10. Raportoidaan edellä mainittujen toimintojen tulokset

• Kaikkea muutakin automaattista voidaan tehdä, jopa asentaa lopuksi

tuotantoympäristöön…

27.10.2008Public 19

© Ixonos Oyj

Työkaluja

• CruiseControl: http://cruisecontrol.sourceforge.net/

• Java-kielinen klassikko

• XML-pohjainen konfiguraatio, paljon työkaluintegraatioita

• Hudson: https://hudson.dev.java.net/

• Kehuja kerännyt: Duke's Choice Awards 2008 -palkinto Sun:lta

• Näppärä konfigurointikäyttöliittymä, paljon työkaluintegraatioita

• Muita (lähde: http://en.wikipedia.org/wiki/Continuous_Integration)• AnthillPro

• Apache Continuum

• Apache Gump

• Atlassian Bamboo

• Automated Build Studio

• BuildBot

• CABIE

• Cascade

• Team City

• …

27.10.2008Public 20

© Ixonos Oyj

PHISHBOOKDemonstraatio hyväksymistestauksesta ja jatkuvasta integraatiosta

29.3.2007Enter Information Classification here 21

© Ixonos Oyj

KOKEMUKSIA KETTERÄSTÄOHJELMISTOKEHITYKSESTÄ

”Käytimme Scrumia, TDD:tä, acceptance-testausta, jatkuvaa integraatiota,

pariohjelmointia, joten projekti onnistui heti aikataulussa. Asiakas kantoi

eteemme kultaa, jalokiviä ja suitsukkeita, ja meitä juhlittiin koko

kansantalouden pelastajina.”

27.10.2008Public 23

© Ixonos Oyj

Vesiputous ei auttanut – Scrum:ko pelastaa…?

• ”There is no silver bullet” – ihan oikeasti ei ole!

• Mikään menetelmä ei tule pelastamaan järjenkäytöltä…

• Aivoton ohjeiden noudattaminen ei kauan toimi

• … ja järjenkäyttö saattaa pelastaa miltä tahansa menetelmältä

• Mikä tahansa menetelmä toimii, jos sitä käyttävät älykkäät ihmiset,

jotka eivät noudata kaikkia menetelmän koukeroita

• Kestävä toiminta ei kuitenkaan voi perustua "sankareihin"

• Halo Effect ja menestysreseptien kopiointi

• ”Sädekehä” haittaa objektiivista tieteellistä tutkimusta

• ”Epäonnistuimme, koska projektihenkilöstö riiteli” vs.

”menestyimme, koska projektihenkilöstö uskalsi sanoa

mielipiteensä”

• Agile-saralla riittää varmasti tutkittavaa vuosiksi eteenpäin

27.10.2008Public 24

© Ixonos Oyj

Testaajan (vaikea) rooli

• Varsinkin XP on hyvin kehittäjä-/ohjelmoijakeskeinen ja muutkin

menetelmät korostavat (kehittäjän) moniosaajuutta

• Ketterässä ohjelmistokehityksessä jokaiselle on kuitenkin tarvetta

• Testaaja ei ole automaatti vaan automatisoija

• Ketterä testaaja

• kaivelee asiakkaan mielen syövereitä

• tulkitsee loppukäyttäjän toiveita

• automatisoi kaiken

• ottaa vastuun ohjelmistosta – virheet eivät ole "niiden koodarien"

vika vaan yhdessä korjattavia ongelmia

• tutkii, kokeilee ja rääkkää ohjelmistoa

27.10.2008Public 25

© Ixonos Oyj

Lähteitä ja hyvää luettavaa

• [1] Poppendieck M. & T. Implementing Lean Software Development: From

Concept to Cash, Addison-Wesley 2007.

• Ehkäpä paras lean-teos tähän mennessä – katsoo asioita laajemmin

kuin ”Scrum-manuaalit”

• [2] Jeffries R., A Metric Leading to Agility,

http://www.xprogramming.com/xpmag/jatRtsMetric.htm

• Schwaber, K. Agile Project Management with Scrum, Microsoft

Professional 2004.

• Scrum-manuaali menetelmän alkulähteeltä

• Schwaber, K. The Enterprise and Scrum, Microsoft Professional 2007.

• Ohjeita Scrumin käyttöönottoon yrityksissä

27.10.2008Public 26

© Ixonos Oyj

Lähteitä ja hyvää luettavaa

• Crispin, L. & House, T. Testing Extreme Programming, Addison-Wesley

2002.

• Ensimmäisiä agile-testausoppaita – ei pelkästään XP:lle

• Crispin, L. & Gregory, J. Agile Testing: A Practical Guide for Testers and

Agile Teams.

• Tulossa vasta ensi vuoden alussa, mutta Crispinin aiemman teoksen

tuntien todennäköisesti erittäin hyvä

• Cunningham, W. & Mugridge, R. Fit for Developing Software: Framework

for Integrated Tests, Prentice Hall PTR 2005.

• Acceptance-testausta Fit- ja FitNesse -työkaluilla. Sisältää paljon

ajatuksia acceptance-testauksesta, vaikka ko. työkaluja ei

käyttäisikään

27.10.2008Public 27

testausta vai määrittelyä? - tunitie21201/s2008/luennot/acceptancetestingtty.pdf ·...

Documents