Arkisto: syyskuu 2010



Näytä minulle hyvä testitapaus

22. syyskuuta, 2010 | Kirjoittaja: Antti Niittyviita
Kommentit: 4

Testitapaukset ovat yleensä paskoja. Ne on suunniteltu huonosti ja ne on kirjoitettu auki vielä huonommin!

Jos et usko väitettäni, niin kokeile itse:

Laadi 100 testitapausta ja tee kolmelle eri testaajalle samanlainen toimeksianto niiden ajamisesta.

Kaikki kolme testauskierrosta tuottavat erittäin suurella todennäköisyydellä erilaiset tulokset. Niiden ajaminen vie jokaiselta testaajalta eri ajan ja testien läpäisyprosenttikin eroaa kaikissa. Veikkaisin vielä että raportoitujen virheiden määrä jokaisella testaajalla on eri.

Kun asiaa pysähtyy hetkeksi ajattelemaan syykin on selvä. Testien laatija on liian usein eri henkilö kuin testien ajaja. Vaara piilee siinä että testien kirjoittajista oikeasti vain pieni osa on hyviä ohjelmoimaan ihmisten käyttäytymistä. Testitapausten kuvaukset harvoin onnistuvat luomaan jokaiselle lukijalle saman kuvan testin tavoitteista, taustoista ja suoritustavoista.

Tarkkojen testitapausten suunnittelu onkin tästä nimenomaisesta syystä erittäin riskialtista puuha. Testitapausten tarkkaa speksaamista perustellaan usein hyvän ja vertailukelpoisen historiatiedon keräämisellä erityisesti regressiotyyppisestä testauksesta. Kuitenkin testejä ajavat henkilöt vaihtuvat usein ja siten muuttuvat myös testitulokset. Perinteisessä speksipohjaisessa testausprosessissa palaakin hurjat määrät työaikaa testitulosten tarkistamiseen ja normalisointiin.

Se voi olla järkevää ajan käyttöä ainoastaan silloin kun projektin laskutusperiaate on tuntipohjainen ja työn maksajalla on pohjaton kassa.

Siksi suosittelenkin pohtimaan erikseen jokaisen projektin kohdalla edellä mainittua ongelmaa. Ratkaisu voi löytyä esimerkiksi näin:

  1. Jokainen testaaja ajaa vain itse suunnittelemiaan testitapauksia. Itse laaditut proseduurit yleensä onnistutaan ymmärtämään oikein. Näin säästetaan aikaa testitulosten tarkastamisesta ja normalisoinnista.
  2. Luovutaan testitapausten liian tarkasta laatimisesta. Siirrytään testitapausten kuvauksissa käyttämään vaikkapa tarkistuslistoja tai tutustutaan säikeistettyyn prosessimalliin. Näin säästyy aikaa paitsi testitulosten tarkastuksesta ja normalisoinnista, myös testispeksausesta, katselmoinneista.

Hassua. Yhtäkkiä en osaakaan kertoa mikä on hyvä testitapaus. Osaatko sinä?

Testaus aikataulupuristuksessa

9. syyskuuta, 2010 | Kirjoittaja: Antti Niittyviita
Kommentit: 3

Testausguru Amit on aloittanut työt yrityksessä, joka kehittää logistiikkajärjestelmiä teollisuusyrityksille. Järjestelmäkehitys on projektiluontoista, sillä tarpeet ovat vahvasti erilaiset jokaisen uuden asiakkaan kohdalla.

Työn tekoa leimaa jatkuva kiire ja repivyys tuotekehityksessä. Sovitun järjestelmätoimituksen lähestyessä työt kasaantuvat rankalla tavalla. Yleensä viimeinen kuukausi ennen toimitusta menee ylitöiksi koko tiimillä. Toimituksen jälkeen korjaillaan lisäksi jäännösvirheitä, joista asiakas on toimituksen jälkeen reklamoinut.

Amitin hypätessä puikkoihin yrityksellä ei ollut varsinaista testaustiimiä vaan työvoima testaukselle alihankittiin kylmästi kolmannelta osapuolelta. Testauksen toimintatapana oli, että tuotekehityksestä tehtiin testaustoimeksianto alihankkijalle aina kun siltä tuntui. Sopimus oli hinnoiteltu kiinteästi per testikierros.

Amit huomasi nopeasti, että koko järjestelmäkehitystä vaivaa ikävä pullonkaula: Amitin mielestä repivyys ja aikatauluongelmat johtuivat nimenomaan kehitystyön loppusuoralla löytyvien kriittisten virheiden määrästä. Virheiden korjaamiseen kului merkittävä siivu ajasta, joka piti käyttää järjestelmätoimituksen viimeistelyyn. Lisäksi projektijohto joutui tekemään kipeitä päätöksiä valikoitujen virheiden jättämiseksi korjaamatta. Niistä asiakas useimmiten sitten takuuaikana teki reklamaatioita ja taas kului lisää aikaa korjaustöissä.

Onneksi Amit oli joskus nähnyt Conformiqin kalvosetin testauksen alihankinnasta. Niistä löytyi erinomainen havainnollistus testauksen aikataulupuristuksesta.

Testaus aikataulupuristuksessa

Testaus aikataulupuristuksessa

Projektipäällikkö ei tehnyt testaustoimeksiantoja kuin vasta jokaisen toimituksen viimeisellä kolmanneksella. Päällikön mielestä testausta ei kannattanut aloittaa, koska budjetti sisälsi kiinteän määrän testauskierroksia ja hänkin tiesi että softassa on vikoja. Testauksen aloittaminen ajoissa tuntui siis resurssien haaskaukselta.  Toisaalta järjestelmätoimituksella oli deadline, josta lipsumisesta seurasi sopimussakkoa. Takuuajalle oli siis pakko jättää virheitä. Lisäksi viimeisen kolmanneksen testaustoimeksiannoista iso siivu kului raportoitujen virheiden verifiointityöhön ja fixien tarkistamiseen.

Onneksi Amitilla oli vanhana guruna kokemusta vastaavasta tilanteesta. Ratkaisukin oli täysin itsestään selvä. Ongelmakenttää kukaan ei vain ollut huomannut tarkastella testauksen näkökulmasta aikaisemmin.

Amit ehdotti, että järjestelmäkehitys jaksotetaan selkeästi testattaviin buildeihin koko projektin ajalle ja testausbudjetti jaetaan koko projektin elinkaarelle. Amitin esittelemät korjaukset prosessimalliin aiheuttivat yrityksessä seuraavat toimenpiteet:

  • Buildisykli tiivistettiin kahteen viikkoon. Toimivan buildin oli oltava valmiina aina parillisten viikkojen torstaina.
  • Jokaisesta buildista oli tehtävä toimeksianto testaukselle. Testaustulokset olivat valmiina viidessä työpäivässä.
  • Virheidenkorjausprosessi aloitettiin heti ensimmäisten testitulosten valmistuttua ja sitä jatkettiin projektin loppuun asti.

Lisäksi testaustoimittajan kanssa sovittiin kiinteästä kuukausihinnasta, joka sisälsi kaksi testattavaa buildia. Hinta laskutettiin oli töitä tai ei. Ennakoitava työmäärä laski testauskierroksen hintaa. Raaka laskutuspolitiikka taas pakotti tuotekehityksen pitämään huolta säännöllisesti tehtävistä tarkastuskelpoisista buildeista.

Näillä toimenpiteillä vakavat virheet saatiin kiinni aikaisemmin ja ne korjattiin hyvissä ajoin ennen toimitusta. Tuotekehityksen työmäärä pysyi tasaisena läpi koko projektin. Ylitöitäkään ei enää tarvinnut tehdä ja takuuaikana tehtävien korjausten määrä puolittui. Yrityksessä huomattiin että:

Testaukseen ja koodaukseen pätee molempiin sama sääntö: Ne eivät toimi optimaalisesti aikataulupuristuksessa!