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

Transkriptio

1 Testausta vai määrittelyä? Hyväksymistestaus ja jatkuva integraatio ketterässä ohjelmistokehityksessä Public Ixonos Oyj

2 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 Ixonos Oyj 2

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 Public Ixonos Oyj 3

4 Agile ketterä ohjelmistokehitys Kuva: Ron Armstrong Lisenssi: cc-by Public Ixonos Oyj 4

5 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 Ixonos Oyj 5

6 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 Ixonos Oyj 6

7 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 Ixonos Oyj 7

8 Periaatteet Agile manifesto ( 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 Ixonos Oyj 8

9 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 Ixonos Oyj 9

10 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 Ixonos Oyj 10

11 Hyväksymistestaus LOPUSTA ALKUUN Public Ixonos Oyj 11

12 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 Ixonos Oyj 12

13 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 Ixonos Oyj 13

14 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 Ixonos Oyj 14

15 Työkaluja Fitnesse: Ward Cunninghamin Fit Frameworkin ( päälle rakennettu wiki SekäFit ettäfitnesse on portattu Javasta muillekin ohjelmointikielille Robot Framework: 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ä( Public Ixonos Oyj 15

16 Jatkuva integraatio JATKUVA PALAUTE Public Ixonos Oyj 16

17 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 Ixonos Oyj 17

18 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 Ixonos Oyj 18

19 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 Ixonos Oyj 19

20 Työkaluja CruiseControl: Java-kielinen klassikko XML-pohjainen konfiguraatio, paljon työkaluintegraatioita Hudson: Kehuja kerännyt: Duke's Choice Awards palkinto Sun:lta Näppärä konfigurointikäyttöliittymä, paljon työkaluintegraatioita Muita (lähde: AnthillPro Apache Continuum Apache Gump Atlassian Bamboo Automated Build Studio BuildBot CABIE Cascade Team City Public Ixonos Oyj 20

21 Demonstraatio hyväksymistestauksesta ja jatkuvasta integraatiosta PHISHBOOK Enter Information Classification here Ixonos Oyj 21

22 Ympäristö Sun Application Server Public Ixonos Oyj 22

23 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 Ixonos Oyj 23

24 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 Ixonos Oyj 24

25 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 Ixonos Oyj 25

26 Lähteitä ja hyvää luettavaa [1] Poppendieck M. & T. Implementing Lean Software Development: From Concept to Cash, Addison-Wesley Ehkäpäparas lean-teostähän mennessä katsoo asioita laajemmin kuin Scrum-manuaalit [2] JeffriesR., A MetricLeadingto Agility, Schwaber, K. AgileProject Management withscrum, Microsoft Professional Scrum-manuaali menetelmän alkulähteeltä Schwaber, K. The Enterprise and Scrum, Microsoft Professional Ohjeita Scrumin käyttöönottoon yrityksissä Public Ixonos Oyj 26

27 Lähteitä ja hyvää luettavaa Crispin, L. & House, T. Testing Extreme Programming, Addison-Wesley 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 Acceptance-testausta Fit-ja FitNesse -työkaluilla. Sisältääpaljon ajatuksia acceptance-testauksesta, vaikka ko. työkaluja ei käyttäisikään Public Ixonos Oyj 27

28 Kiitos Thankyou Public Ixonos Oyj