Löydä virheet, kun niiden korjaaminen on halvinta
Proven Jukka on rakentamassa taloa. Nykysuuntauksen mukaan kylppäriin tulee kaksi suihkua, neliönmallisen huoneen vastakkaisiin nurkkiin. Suihkuja varten piti nurkkaa “oikaista”, jotta suihkun tarvittavine hanoineen saa kätevästi seinään kiinni.
Koska oma ammattitaitoni soveltuu lähinnä vakuttavan kuuloiseen puheeseen ohjelmistojen testaamisesta, päätin tilata paikalle ammattimiehen.
Ammattimiehen tehtävänä oli rakentaa metallikehikko suihkun taustaa varten ja kiinnittää se. Koska kyseessä oli ammattimies, kehikko valmistui nopeasti ja kiinnityskin onnistui kätevästi proppujen ja ruuvien avulla lattiaan.
Seuraavaksi paikalle kutsuttiin LVI-asentaja, asentamaan suihkuja ja muita laitteita. Nähdessään metallikehikot, asentaja kysyi ensimmäisenä Jukaltamme, että eikös lattian alle asennettukin lattialämmitys. Tietenkin oli, sehän on modernin talon perusmukavuus.
Esitietojen perusteella ja ennen työn aloittamista LVI-asentaja päätti kuitenkin vielä suhauttaa paineilmaa lattialämmityksen putkien läpi.
Kuinka ollankaan, propun rei’istä suhahti ilmoille kunnon pölypatsas, putket olivat menneet rikki. Jos LVI-asentaja olisi tehnyt oman työnsä laput silmillä ilman edellisen työn testaamista, olisi tuloksena ollut mittava vesivahinko. Koko kylppäri olisi pitänyt uusia muutaman kuukauden sisällä muuttamisesta. Nyt selvittiin putkien vaihdolla ja varsin kohtuullisilla kustannuksilla.
Alkuharmitus takapakista vaihtui äkkiä helpotukseen. Iloinen rakentajamme ymmärsi, että pahempaakin olisi voinut sattua.
Vahinkoja sattuu ja virheitä tulee. Siksi tärkeiden ominaisuuksien testaaminen säännöllisesti on tärkeää. Liiketoimintaa vaarantavat virheet kannattaa löytää silloin, kun niiden korjaaminen on kaikkein edullisinta.
Suosittelemme myös:
Mikä on kun ei taidot riitä?
Ilma oli sakea, tunnelma tiivis ja noin 100 kilttiä koululaista nojautui kuuntelemaan väkeviä tarinoita myynnin ihmeellisestä maailmasta. Istuin...
Kävi muutama kuukausi sitten minulle niin, että testasin asiakkaan serverin sitkeyttä altistamalla sen suurelle määrälle palvelun käyttäjiä. No niinhän siinä kävi, että serveri ei painetta kestänyt, vaan antoi periksi liitoksistaan. Muisti siitä loppui johtuen alustan virheellisestä säädöstä ja muistin hallinnan perusvirheistä.
Serveri meni rikki itseasiassa niin pahasti, että se piti asentaa uudestaan. Asiakas oli harmissaan ja voivotteli aikansa. Vikojen korjauksen jälkeen sama testi ajettiin uudestaan ja nyt serveri käyttäytyi oikein eikä kaatunut.
Jälkeenpäin asiakas ilmaisi minulle, että kuinka tyytyväinen hän kuitenkin on, vaikka hajoitin hänen serverin. Nimittäin jos tuotantokäyttöön olisi siirrytty ilman korjauksia, niin palvelu olisi kyykähtänyt ensimmäisen vuorokauden aikana ja asiakkaiden ensivaikutelma olisi jäänyt sangen ohueksi. Ironiseksi tilanteen teki se, että serveri vaikutti kaikin puolin toimivalta ja valmiilta tuotantoon, mutta ns. perstuntuma asiakkaalla ilmoitti, että voi olla hyvä idea kuitenkin testata ensin tuotantokäyttöä vastaavalla kuormalla.
Ammattitestaaja, hieno käytännön esimerkki testauksen maailmasta. Tuossahan myös asiakkaasi sai käytännön kokemusta siihen, että mitä toimenpiteitä vaaditaan palvelimen kaatuessa syystä tai toisesta.
Kannattaisiko tuollainen kyykytystesti tehdä ihan harjoitusmielessä aina?
Itse käytän nyrkkisääntöä, että kaikki testaaminen kannattaa aina. Jos nyt kuitenkin puhumme nimenomaisesti kuormitustestauksesta, niin pitäisin kyseistä testausta välttämättömänä varsinkin silloin kun tuote/palvelu on suunnattu suurelle yleisölle.
Tässä on nimittäin sellainen seikka, että hieno ja hartaasti hiottu palvelu saa aivan suotta negatiivisen nosteen jos palvelu ei pysy pystyssä ensimmäisenä päivänä. Ensivaikutelma on vaikutelmista se kaikkein tärkein. Moni tietää, että kuinka paljon pitää tehdä töitä, jos haluaa muuttaa asiakkaan ensivaikutelman.
Homma menee suurinpiirtein näin: Palvelusta kiinnostunut potentiaalinen asiakas on odottamalla odottanut päiviä jotta palvelu avautuu – kun se viimein avautuu, niin sinne rynnätään heti. Kun palvelu alkaa tökkimään tai jopa kaatuu kuorman edessä, niin tästä mielensä pahoittanut asiakas kiiruhtaa oitis twiittaamaan: ”siis oli kyllä täysi susi tuokin”. Ja lumipallo-efekti on valmis. Kun palvelu saadaan viimein korjattua todennäköisesti viikkokausien jälkeen, on vahinko jo tapahtunut ja asiakkaat ovat taatusti siirtyneet ”eteenpäin”.
On hyvä idea tietää etukäteen, että miten palvelulle käy kun asiakkaat ryntäävät porukalla paikalle.
Itseäni kiehtova ajatus olisi kaikkien järjestelmien kehitykseen kuuluva asiakasohjelmien kevytversio joka suorittaisi asiakasohjelmalle ominaisia toimintoja kompaktissa muodossa siten, että valittavissa on käyttöprofiili sekä määrä asiakasyhteyksiä joita tuotetaan.
Esimerkiksi jo pieni tuotantoyritys jossa tuotannon sekä hallinnon kattava yksi järjestelmä jossa todellinen tuotannollinen kuorma on vain kymmeniä asiakasohjelmistoja.
Otaksutaan että ratkaisuksi on päätetty suorittaa kaikkia palveluita yhdessä palvelimessa. Mahdolliset tilanteet voivat olla vaikeita testata ilman tietoa siitä mitä tapahtuu kun kuormaa ei kestetä, tai vastaako oletettu kuorman kesto todellisuutta.
Tuo kiehtova ajatus kevytversiosta tässä esimerkissä sisältäisi profiilit tuotannon ja hallinnon kaltaisien kutsujen tuottamiseen. Haluttu määrä kyseisiä kevytversioita voitaisiin siis käynnistää eri testien tarpeiden mukaiset määrät ja jatkaa normaalia testausta todellisilla asiakasohjelmilla ympäristössä missä todellista vastaava tai liian suuri kuorma on olemassa.
Tämänkaltainen vaatimus järjestelmän asiakasohjelmiston määrittelyssä myös lähes pakottaisi selkeään arkkitehtuuriin.
Vastatakseni kysymykseesi, mielestäni kyky tuottaa kuormaa järjestelmän testaamiseen tulisi kuulua aina osana sovelluskehitykseen ja siten kyky testata äärimmäisiä kuormia (kyykyttää) olisi vain osa kokonaista kuormitustestausta.