Hieman taustaa:
Kyseessä on siis monikansallinen SOA maailmaan toteutettu nelitasoarkkitehtuuripalvelu, jossa integroidaan puolisen tusinaa räätälöityä palvelua ja järjestelmää yhdeksi kokonaiskattavaksi palveluksi. Integraatioalustana toimii SonicESB ja SOA malli on webservice-pohjainen toteutus. Ohjelmoinnissa on käytetty pääasiassa C# ja Javaa (useita eri järjestelmiä). Palvelut ovat webbisovelluksia MySQL kannoilla. Tarkempaa tietoa en tässä lähde jakamaan, mutta perusperiaate on se, että meillä on integraatioputkia asiakkailta meille, jossa dataa puljataan ja tehdään sillä erilaisia temppuja, ja sitten putkea pitkin takaisin laitetaan jalostettua dataa. Simple, fun, "iz all good".
Vaan testaus tässä SOA-maailmassa osoittautui hieman erityyppiseksi kuin olin aiemmissa projekteissani testausta harrastanut. Projekti alkoi 2010 keväällä ja jatkuu vieläkin. Tuolloin keväällä luotiin kattavat testaussuunnitelmat sekä testitapaukset. Testausstrategia oli periytynyt aiemmasta php-MySQL-sovelluksesta, joten strategia oli kohtuu simppeli. Toiminnallista testausta, suorituskykytestausta integraatio ja systeemitestaustasolla. Yksikkötestit eivät juurikaan meikäläistä huolettaneet, olihan se kehittäjien peruskauraa. Testausautomaatiota ei juurikaan ollut, mutta toisessa yksikössä kehitetty CI-prosessi alkoi kiinnostamaan.
Jo alussa totesin, että ketterän kehityksen yhdistäminen SOA-maailmaan loi SUURIA kuoppia testaussuunnittelussa eikä IEEE-standardien mukainen testaussuunnittelu onnistunut sprinttimaailmassa. Siirryinkin testauksessa sulavasti "Definition of Done" -tyyppiseen testaukseen, jossa testitapaukset toimivat tukipilarina sekä "heuristiikkana" toiminnallisuuksien testaamisessa. Tämä malli oli toimiva jo toteutetuissa GUI:ssa ja perus bisneslogiikka toteutuksissa. Testejä tehtiin ja toiminnallisuuksia saatiin vietyä usein jopa asiakkaalle asti.
Ongelmat alkoivat kasaantua, kun SOA nosti rumaa päätään. Integroitiin pari järjestelmää ja liitettiin käyttöliittymä webserviceiden kautta taustalogiikkaan. Lisäksi integraatioputki asiakkaalta vaati testausta. Lähes kaikki integraatiotason testaus pamahti työpöydälle samaan aikaan ja testidataa ei ollut kenelläkään. Päivien työ kului konffatessa testidataa ja automatisoimalla integraatiotestejä - samalla koko toteutus muuttui pikkuhiljaa ja testit vanhentuivat. Päivitysrumbaan tuli kokoajan uutta testattavaa ja ylityöt alkoivat paukkua.
Syksyyn mennessä olimme saaneet ketterään tiimiimme toisen testaajan, joka samoin tein kiinnitettiin teknisempään testaukseen hänen ohjelmointitaustastaan johtuen. Työn määrä ei vaan mitenkään ottanut vähentyäkseen, kun mentiin kokoajan syvemmälle integraatio- ja järjestelmäintegraatiotasoille.
Joulun koittaessa 2010 olimme tilanteessa, jossa meillä oli kuusi järjestelmää, jotka kaikki käyttivät integraatioalustaa ja kommunikoivat toistensa kanssa ja releasepäivä lähestyi. Hain apua CI-porukalta ja aikaan saatiinkin Jenkinsillä kivasti ajettavat testisetit. Lisäksi yksikkötason ESB-prosessitestaaja saatiin refaktoroimaan prosesseja ja automatisoimaan testit. Lisäksi JMeterin suorituskykytestit sekä Soap-kuomitustestit saatiin (osittain) automatisoitua ja päästiin hieman lähemmäs hyvää testikattavuutta.
Joulu tuli ja Joulun alla piti olla suuri release, mutta vaikka testit menivät läpi, järjestelmä ei toiminut. Testiinluovutustilaisuudessa integraatiokerros lakkasi vastaamasta ja homma päättyi siihen. Testausta suovittiin ja ohjelmoijien kykyä tehdä toimivaa koodia. Jokainen taisi mennä itseensä ja silloinen tekninen projektipäällikkökin vaihtoi puljua. Kaaos oli taattu.
Saimme kuitenkin projektin urille hiomalla ja aikatauluja rukkaamalla, ja ennen kaikkea asiakkaan luottamuksen takaisin. Testaus tehtiin ketterämmin ja paremmassa yhteistyössä kehittäjien kanssa. Yksikkötestausta painotettiin ja suorituskykytestien perusteella tehtiin refaktorointia kiireen ohella. Ensimmäinen versio saatiin siis pilottiin vaikka meillä oli tiedossa X-määrä melko pahojakin vikoja. Pilotti oli kankeaa ja integraatiokerros takkuili. Ympäristöjen kanssa oli ongelmaa.
Toukokuu läheni ja siirryimme testauksessa jäykästä IEEE dokumentointimallista Boltonin kouluttamaan RST-malliin, jossa meillä oli sekä sessiopohjainen testauksen hallinta että tutkivan testauksen menetelmät käytössä. Saimme kymmenkertaistettua vian löytötahdin ja saimme pienennettyä testaussykliä kehittäjien kanssa. Tulosta saatiin! Lisäksi ympäristöongelmien kanssa päästiin eteenpäin ja stabiiliutta saatiin. Ensimmäinen KUNNON pilottiinsiirto saatiin toukokuussa ja pilotti ulkomailla eteni hyvin. Kiitosta tuli uuden testausprosessin myötä ja kehittäjiä kiiteltiin ja jopa koko projektiryhmä sai pienen kannustuspalkinnon.
Tässä vaiheessa alkoi kuitenkin pilvet kasaantua, kun päätettiin tehdä datamallin muutos integraatiokerrokseen. Asian piti olla kohtalaisen läpihuutojuttu: muutetaan kirjastot, rajapinnat, muutetaan arkkitehtuuria nopeuttamiseksi, refaktoroidaan komponentteja, yhdistellään... WHAT?! Tämä läpihuutojuttu osoittautuikin käytännössä KAIKKEEN vaikuttavaksi ("God bless that SOA!") ja testaus oli avainasemassa näiden muutosten läpiviennissä.
Kaikki testit jouduttiin päivittämään ja vielä yhtä aikaa. Kaikki ketjut piti uudelleensuunnitella, jokainen kanta-assertio tarkistaa. Kehittäjät olivat tehneet siis muutokset lokaalisti ja jokainen omat muutoksensa. Nyt niiden ollessa samassa korissa me testaajat olimme pulassa... Tai olemme. Tuo on tämänhetkinen tilanne.
--
Aiemmin sanoin "vähän taustaa", mutta tästä muodostuikin melko kattava kertomus. Mitä tästä jäi käteen? Paljon ylityötä? Kritiikkiä? Koloja asiakassuhteessa? Mitä me opimme (tai opimme edelleen)?
Illan pimeinä tunteina, kun muu testausporukka on jo lähetetty lataamaan akkuja, saatan istua koneella ja etsiä vastauksia kysymyksiin. Miten testaus on järkevä organisoida SOA maailmassa? Mihin sijoittaa se vähä määrä testauspanosta, joka meillä on antaa tälle projektille?
Mietin testauksen alihankintaa, jossa toteutamme testitapaukset ja alihankkijaryhmä saa testata softan etu- ja takaperin. Vaan sen verran olen oppinut, että SOA maailmassa täytyy olla ketterä ja liian skriptatut testitapaukset ja -ideat muodostuvat päivitystaakaksi, josta ei ole pakoa. Ketteryys on siis avain. Vaan miten ketteröitetään testausta?
Lähdimme hyväksi havaittua tutkivan testauksen lähestymistapaa hyväksikäyttäen kartoittamaan tilanteita ja riippuvuuksia. Saimme paremmin tietoa käyttämällä taitoamme ja tietoamme koostamaan järjestelmästä kokonaiskuvan kaikkine integraatioineen ja rajapintoineen. Päätimme pitää tiettyjä osa-alueita mustina laatikkoina ja kriittisiin solmukohtiin syvennyimme tarkemmin. Automaatiota parannettiin parametrisoimalla testitapauksia tehokkaammin ja jopa poistamalla päivityshelvetiksi muodostuneita tapauksia. Testasimme myös aikaisemmin kuin aiemmin, jolloin saimme tietää riippuvuuksia ennen niiden toteuttamista.
Testauspolitiikka alkoi muuttumaan "pass/fail" -tyyppisestä "kaikki testit menevät läpi, mutta ne löytävät/eivät löydä vikoja, poikkeamia, riskejä, huomioita, häiriöitä, jne." -tyyppiseen. Pyrimme tuomaan asoita esille enemmänkin tarinana kuin punainen/vihreä -periaatteella. Me halusimme antaa tietoa järjestelmästä kehittäjille ja projektin päättäjille.
Myös strategia päivittyi jäykästä ketterään. Tekniikat olivat testaajien kontekstiin sopiviksi valittavia ja työkaluja käytettiin parhaiden taitojen mukaisesti (ei parhaiden käytäntöjen). Saimme työkaluista irti sellaisia ominaisuuksia, joita emme olleen aiemmin käyttäneet johtuen käytänteistä. Pystyimme tekemään pidempiä ketjutuksia ja tarkempia assertioita ja kantatarkistuksia. Heuristinen lähestymistapa systeemitestaukseen vei meidän kauemmas ja lähemmäs testattavaa softaa (välillä rautaa) ja nosti aivan uudenlaisia vikoja ja puutteita järjestelmästä. Vaikka vikojen määrä on tähtitieteellinen verrattuna projektin aiempiin vaiheisiin, niin laatu on noussut - ihmiset ottavat opikseen huomioista, riskeistä, kysymyksistä. Testaus nostaa esiin asioita, joita kukaan ei ole ennen ajatellut. Testaus nostaa esiin asioita, mitä harva on aiemmin edes tajunnut! Testaajat eivät etsi vain bugeja vaan testaajat kertovat kaikesta, mitä havainnoivat.
Testaus tarjoaa enemmän tietoa kuin koskaan aiemmin ja se vie meitä eteenpäin. Ja nyt mennään taas eteenpäin, että saadaan tämä projektivaihe kunnialla maaliin!
No comments:
Post a Comment