Tee testispeksit uudella tavalla!

Jarkon uusin projekti oli alkanut painaa hommia jatkuvan integroinnin periaatteella. Projekti oli ensimmäinen tyyppiään organisaatiossa, jossa Jarkko teki testimanagerin hommia. Projektin alussa testauksen haluttiin toimivan varsin perinteisellä mallilla. Testauksessa nimittäin suunniteltiin releaselle savustustestit ja iso kasa toiminnallisuustestejä. Ne paketoitiin ennalta suunniteltuihin testisetteihin.

Jarkon testaustiimi käytti noin 4000 testitapauksen speksattua joukkoa. Testitapaukset oli jaoteltu erillisiin testisetteihin ohjelmiston osa-alueen mukaan. Yhden testisetin ajaminen vei aikaa tiimiltä kolme päivää. Ongelma tässä oli se että buildiautomatiikka teki aina uuden releasen joka yö. Kun yksi testikierros valmistui, sen tulokset tulivat kaksi päivää myöhässä. Kaksi uutta rellua oli jo ehtinyt tuutista ulos. Testitulosten parasta ennen päiväys siis meni jo!

“Tämähän ei varsinaisesti kuulosta ongelmalta!” totesi projektipäällikkö. Jarkko kuitenkin laski että  testikierroksen loppusuoralla löytynyt vakava integraatiobugi voi pahimmassa tapauksessa aiheuttaa kolmen päivän töiden reverttauksen versionhallinnasta. Pahimmassa tapauksessa töitä saattoi mennä hukkaan jopa 8 developperin ja 3 testaajan, eli 33 miestyöpäivän verran! “Kalliiksi tulee” -perusteli Jarkko.

Jarkko ja testaustiimi olivat onneksi tiedostaneet riskin hyvissä ajoin ja etsivät aktiivisesti ratkaisua ongelmaan jo ennen kuin projektijohto asian ymmärsi. Tiimille oli projektin alussa valittu kätevä testauksenhallintajärjestelmä, jossa testisettejä ei ollut pakko rakentaa ennalta. Niitä pystyi muodostamaan dynaamisesti tarpeiden mukaan. Kun pullonkaulat projektissa lopulta ymmärrettiin ja ratkaisun löytämiseen allokoitiin vielä lisäresursseja, tiimi ryhtyi ripeästi toimeen:

Testauksenhallintajärjestelmä integroitiin buildiautomatiikkaan siten että aina uuden buildin valmistuessa, testausjärjestelmään luotiin automaattisesti uusi testauksen kohde (release). Jokainen testitapaus piti sisällään jo ennalta tiedon siitä millä releasella kyseinen testi oli viimeksi tehty. Yksittäiselle testitapaukselle voitiin siis näin muodostaa myös “parasta ennen” -päiväys. Tämän jälkeen joka aamu tiimi rakensi päiväkohtaisen testaussuunnitelman ja testisetit dynaamisesti. Testisettien rakennuksen kriteereinä olivat:

1. top-10 testitapaukset, eli järjestelmän ylläpitämän kirjapidon mukaan kymmenen eniten virheitä löytänyttä testitapausta
2. aikaisemmin epäonnistuneet testitapaukset, jotta nähdään onko tullut parannuksia aikaisempiin releaseihin
3. releasen muutoskohteet, eli testauksen riskipohjainen suunnittelu
4. “parasta ennen” -päiväyksen eniten ohittaneet testitapaukset ja lopuksi
5. tutkiva testaus

Näin toimiessa testaustiimillä oli jatkuvasti ajantasaisempi kuva lopputuotteen kypsyydestä ja siitä millä osa-alueilla kaivattiin eniten korjauksia. Kriittisimmät virheetkin saatiin kiinni keskimäärin työpäivää aikaisemmin, kun ei väkisin väännetty ennalta suunniteltuja testisettejä samassa järjestyksessä kuin aina ennenkin. Muutosten toteutus oli lopulta niin onnistunut että firma päätti muuttaa testauksen toimintatapoja muissakin projekteissa samaan suuntaan.

Kuinka usein teillä on paukutettu aina saman regressiotestisetin alkupäätä päivän verran ja löydetty sitten testauksen keskeyttävä virhe viimeisestä kolmanneksesta testitapauksia? Aika ärsyttävää sanon minä. Usein vanhassa mallissa pysytään siksi että joku haluaa menneisyyden testimetriikat vertailukelpoisiksi tulevien testikierrosten kanssa. Tästä syystä testsetin muuttaminen on joskus niin pirullisen työläs prosessi. Unohda perinteinen:

Saat väistämättä testauksestasi enemmän irti kun avaat toimintaympäristön ja testispeksit muutoksille. Huolehdi siis aivan aluksi että testaus saa tehokkaammin ja aikaisemmin bugit kiinni ja vaivaa päätäsi vasta lopuksi metriikoilla. Näin myös lopputuotteesi kiittää!