Testausta vai määrittelyä? Hyväksymistestaus ja jatkuva integraatio ketterässä ohjelmistokehityksessä Public 27.10.2008 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ä Disclaimer: Tämäesitys ei välttämättäedusta työnantajani mielipiteitä, vaan ainoastaan omia mielipiteitäni ja kokemuksiani ohjelmistoalan ammattilaisena. Public 27.10.2008 Ixonos Oyj 2
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 Public 27.10.2008 Ixonos Oyj 3
Agile ketterä ohjelmistokehitys 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/ Public 27.10.2008 Ixonos Oyj 4
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 Public 27.10.2008 Ixonos Oyj 5
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 Public 27.10.2008 Ixonos Oyj 6
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 Public 27.10.2008 Ixonos Oyj 7
Periaatteet Agile manifesto (http://agilemanifesto.org/) Individuals and interactions over processes and tools Working softwareover 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. Public 27.10.2008 Ixonos Oyj 8
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) Public 27.10.2008 Ixonos Oyj 9
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 Public 27.10.2008 Ixonos Oyj 10
Hyväksymistestaus LOPUSTA ALKUUN Public 27.10.2008 Ixonos Oyj 11
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 Enter Information Classification here 29.3.2007 Ixonos Oyj 12
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önmuuttamista toimintojen suhteen iteraation aikana (asiakas) Virheiden ja erityistapausten osalta kannattaa laajentaa testejä myös iteraation ollessa käynnissä Public 27.10.2008 Ixonos Oyj 13
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. Acceptance Test Case Acceptance Test Case Fixture Fixture System Under Test Public 27.10.2008 Ixonos Oyj 14
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) Public 27.10.2008 Ixonos Oyj 15
Jatkuva integraatio JATKUVA PALAUTE Public 27.10.2008 Ixonos Oyj 16
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] Public 27.10.2008 Ixonos Oyj 17
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 Public 27.10.2008 Ixonos Oyj 18
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 Public 27.10.2008 Ixonos Oyj 19
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 Public 27.10.2008 Ixonos Oyj 20
Demonstraatio hyväksymistestauksesta ja jatkuvasta integraatiosta PHISHBOOK Enter Information Classification here 29.3.2007 Ixonos Oyj 21
Ympäristö Sun Application Server Public 27.10.2008 Ixonos Oyj 22
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. KOKEMUKSIA KETTERÄSTÄ OHJELMISTOKEHITYKSESTÄ Public 27.10.2008 Ixonos Oyj 23
Vesiputous ei auttanut Scrum:ko pelastaa? Thereis no silverbullet 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 Public 27.10.2008 Ixonos Oyj 24
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 Public 27.10.2008 Ixonos Oyj 25
Lähteitä ja hyvää luettavaa [1] Poppendieck M. & T. Implementing Lean Software Development: From Concept to Cash, Addison-Wesley 2007. Ehkäpäparas lean-teostähän mennessä katsoo asioita laajemmin kuin Scrum-manuaalit [2] JeffriesR., A MetricLeadingto Agility, http://www.xprogramming.com/xpmag/jatrtsmetric.htm Schwaber, K. AgileProject Management withscrum, Microsoft Professional 2004. Scrum-manuaali menetelmän alkulähteeltä Schwaber, K. The Enterprise and Scrum, Microsoft Professional 2007. Ohjeita Scrumin käyttöönottoon yrityksissä Public 27.10.2008 Ixonos Oyj 26
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 Public 27.10.2008 Ixonos Oyj 27
Kiitos Thankyou www.ixonos.com Public 27.10.2008 Ixonos Oyj