Anonyymi testipäällikkömme kuvaili aiemmin blogikirjoituksessaan laadunvarmistuksen ja testauksen olevan kuin kolikon kaksi kääntöpuolta tai itämaisittain jin ja jang, koska ne täydentävät toisiaan. Myös testauksen viitekehyksessä on syytä keskittyä kokonaisvaltaisuuteen.
Ohjelmistoprojektin testaustyyppien valinta voi olla testipäällikön painajainen. Ainainen resurssipula, joko ajankäytön tai investoitujen eurojen näkökulmasta, voi tuottaa hikikarpaloita testipäällikön otsalle. Tehdäkö kevyt integraatiotestaus, funktionaalinen testaus ja suorituskykytestaus? Vai keskittyäkö ennemmin funktionaaliseen puoleen ajatellen, että suorituskyky kyllä seuraa perässä? Usein vastaus on jälkimmäinen, jolloin suorituskykytestaus jää paljon pienemmälle huomiolle. Usein se jää jopa kokonaan tekemättä, jos myöhässä ollut ohjelmistonkehitys on jo syönyt määrärahat ja projektille varatun ajan. Tämä voi johtaa ongelmiin arjessa.
Miksi suorituskykytestaus on niin tärkeää? Siksi, että todellisia suorituskykytestauksen puutteessa johtuvia katastrofeja on aiheutunut myös oikeasti. Räikeimpien esimerkkien joukossa on elokuussa 2003 koko koillisen USA:n pimentänyt sähkökatkos, jonka piirissä oli jopa 50 miljoonaa ihmistä. Joillain alueilla katkos kesti kaksi päivää. Yhden sähkölaitoksen alueella tapahtunut ylikuormitus laukaisi tapahtumaketjun, jossa verkon kuormanjakoa säädellyt tietokone ylikuormittui. Koko ongelma olisi voitu välttää testaamalla etukäteen järjestelmän suorituskyky katastrofaalistenkin tapahtumien aikana.
Toistaiseksi historian kallein puutteellisen suorituskykytestauksen aiheuttama katastrofi tapahtui maaliskuussa 2008 englannissa, uudenkarheassa Heathrow’n terminaali 5:ssa. Ennen terminaalin avautumista insinöörit olivat testanneet suurella vaivalla matkalaukkuja kuljettavan liukuhihnan toimintaa. Testaamiseen oli käytetty 12 000 matkalaukkua, ja kaikki vaikutti toimivan hienosti. Testauksessa oli kuitenkin unohdettu oikeassa elämässä tapahtuvat tilanteet, kuten sellaiset, joissa matkustaja laskee laukun hihnalle, mutta nostaa sen uudelleen pois ottaakseen jonkin tärkeän esineen laukusta. Hihna ylikuormittui lähes välittömästi käynnistymisen jälkeen, ja hihnat pysähtyivät. Tästä aiheutui kymmenen seuraavan päivän aikana yli 42 000 matkalaukun siirtämisen epäonnistuminen. Yli 500 lentoa jouduttiin perumaan. Hintaa testausvirheelle tuli 4,3 miljardia puntaa.
Kuvatut esimerkit pyrkivät osoittamaan, miten täydellisessä maailmassa pelkkä funktionaalinen testaus ehkä riittäisi. Testaus on kuitenkin kokonaisvaltainen toiminto, jossa yhden osuuden puuttuminen voi aiheuttaa dramaattisia seurauksia. Niinpä koko testausketjun läpikäyminen takaa parhaalla mahdollisella tavalla koko järjestelmän toimivuuden. Suorituskykytestauksen puuttuminen testiketjusta osoittaa aivan liian usein, että ikävä kyllä me emme elä täydellisessä maailmassa.
– Riku Henriksson
