testausta vai määrittelyä? - tunitie21201/s2008/luennot/acceptancetestingtty.pdf ·...
TRANSCRIPT
© 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
Ympäristö
27.10.2008Public 22
Sun Application ServerSun Application Server
© 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
© Ixonos OyjPublic 27.10.2008
Kiitos – Thank youwww.ixonos.com