Ehdokas vuoden 2012 kalleimmaksi bugiksi
Kesälomat alkaa olla lusittuna, illat pimenee ja työtahti tiivistyy!
Blogi avaa kevyellä bugi-aiheisella uutisella. Tämäkin blogi on ajoittain ruotinut kalleimpia virheitä. Vuoden 2012 kisaan on ilmoittautunut varteenotettava vaihtoehto.
Jersey Cityssä pääpaikkaansa pitävän Knight Capitalin kaupankäyntiohjelmiston algoritmiin on livahtanut virhe, joka on aiheuttanut 440 miljoonan dollarin vahingon. Seuraavana päivänä yhtiön arvo romahti yli 50%. Päivän päätteeksi pörssikurssi oli n. kolmanneksen pienempi kuin ennen virheen sattumista.
Eikä siinä vielä kaikki. Kun selailee Knight Capitalin verkkosivuja, voi tappio olla merkittävästi suurempi. Yritys nimittäin markkinoi sivuillaan hyvin voimaakkaasti teknologiaansa tehokkaan ja tuottoisan kaupankäynnin ytimenä. Teknologiaa esittelevällä sivustolla kerrotaan mm. näin:
Our robust technology infrastructure and flexible architecture provides instant access across multiple asset classes to liquidity both within and outside of Knight.
Ja näin:
With our regular, prudent investments in our technology platform, Knight strives to remain ahead of the latest technology developments, providing advanced market access and trade execution services across multiple asset classes.
Mitäpäs luulette nykyisten ja tulevien asiakkaiden ajattelevan yrityksen luotettavuudesta, kun keihäänkärjeksi nostettu teknologia pettää dramaattisella tavalla? Ei se ainakaan lisää asiakkaiden luottamusta.En ihmettelisi yhtään, vaikka sijoittajat alkaisivat vetää rahojaan pois. Ainakin uutisen kommentit ennustavat kovin synkkää tulevaisuutta yritykselle.
Mikäli markkinoit yrityksesi teknologista ylivertaisuutta, joudut myös väistämättä panostamaan sen toimivuuteen. Muuten bugit käyvät reaalista arvoaan paljon kalliimmiksi.
Suosittelemme myös:
Testaus 2011 seminaari ja vuoden testaajan valinta
Hei lukija! Tieturilla on tapana järjestää testausaiheinen seminaari joka kevät. Aiheet iskevät jälleen napakasti testauksen kuumimpien...
Oivalluksellakin on hintansa
Jos kysymys ei ole uskomattomasta munkista, mäihästä tai tuurista, niin onnistumisilla on aina hintansa. Hinta on mahdollista maksaa etukäteen ja...
Toisinaan kuulen juttuja, että kun ohjelmiston tai muun tuotteen kehittämiseen varattu budjetti alkaa umpeutua, niin leikataan tuotteen testausta. Tämä on virheliike. Kun rahat alkavat olla vähissä, niin silloin tilanne on se, että ei todellakaan ole varaa leikata testauksesta. Osa tuotteita kehittävistä tahoista ei tätä vielä tiedä, mutta yksi toisensa jälkeen jokainen sen oppii, joko kantapään kautta tai sitten muuten kuten otetaan opiksi toisten tekemistä virhearvioista.
Kerran minulle on sanottu, että olen tätä mieltä koska olen testaaja ja katson asioita testauslasit päässä. Vastaukseni tähän on, että kyllä. Kuinka edes voisin olla mitään muuta mieltä kaiken kokemani, kuulemani ja uutisista lukemani jälkeen? Testauksen ammattilaisena on minun velvollisuus tuoda tämmöiset asiat esille. Jos en olisi ammattitestaaja, niin olisin todennäköisesti jotain muuta mieltä.
Ammattitestaaja täräyttää kaksi tikkaa häränsilmään. Ensimmäinen kappale on todennäköisesti kaikille IT-projekteihin osallistuneille tuttu. Näppituntuma minulla on, että tilanne on kuitenkin paranemassa koko ajan. Onko lukijoilla vastaavia tai päinvastaisia kokemuksia?
Toinenkin kappale on tuttu kaikille. Myyjät katsovat kaikkea myynnin näkökulmasta (ja se on tärkein), markkinoijien mielestä markkinointi on tärkeintä, teknologiatyyppien mielestä teknologia ratkaisee ongelmat ja testaajien mielestä testaus on avain onneen.
Testaajille voisi olla hyvin avartavaa miettiä, että mielissään, että mitäs tässä itse asiassa ollaan testaamassa ja mitä tapahtuu jos testaus jää tekemättä ja ns. pahin mahdollinen tapahtuu. Kuoleeko joku? Jos ei, niin voiko virheen seurauksena liiketoimintamme mennä nurin? Jos ei, niin häviämmekö merkittävän asiakkuuden? Jne. On paljon helpompaa perustella testauksen merkitys, kun testaamatta jättämisen riskit osataan kertoa.
Sitten enää pitäisi jonkun viisaan osata sanoa, että milloin on testattu riittävästi 🙂
Milloin on testattu riittävästi? Kysymys on hyvä ja oma näkemykseni on seuraava: Kun testauksessa saavutetaan tilanne, että uusia bugeja ei enää löydy, niin se tarkoittaa sitä, että testauksessa on jotain pielessä eikä suinkaan sitä, että nyt tuote on virheetön. Lähes poikkeuksetta voi sanoa, että 100% passed tulos tarkoittaa sitä, että hälytyskellojen on hyvä soida ja managerin syytä käydä läpi se, että mitä testauksessa itseasiassa testataan. Kertaakaan ei ole käynyt niin, että 100% passed -tuloksen saanut tuote olisi toiminut 100 prosenttisesti asiakkaan käytössä.
No sitten reality check – elämme toki maailmassa joka pyörii, ainakin toistaiseksi vielä, rahan eli ajan mukaan. Kukaan muukaan ei tuo markkinoille 100 peosenttisesti toimivaa tuotetta, niin siispä kaikki voivat tuoda virheellisen tuotteen markkinoille. Kilpailutilanne syntyy siitä, että kuka on osannut korjata ne oikeat virheet ja kuka puolestaan on käyttänyt aikansa ”väärien” virheiden korjaamiseen.
Tilanne on käsittämättömän mielenkiintoinen ja moniulottoinen ja kovin moni ei peliä osaa pelata oikein. Ne jotka pelin ovat opetelleet ja sen osaavat, voivat menetellä esimerkiksi näin: Hyväksytään heti kärkeen, että tuote on reikäinen kuin emmentaali – pistetään korjauspaketti asiakkaille myöhemmin. Keskitytään tekemään tuotteesta muuten todella hyvä esimerkiksi fyysiset ominaisuudet jne. Kun tuote on tarpeeksi viileä, niin tapahtuu jotain todella todella erikoista – asiakkaat alkavat puolustamaan bugista tuotetta, että mitä väliä vaikka sillä ei voi soittaa kun se muuten on niin siisti ja että korjaus on tulossa ja että he malttavat odottaa siihen asti. Kaikille pelin pelaaminen näin ei sovi.
Itse olen sitä mieltä, että tuotetta ei ole testattu riittävästi milloinkaan. Voidaan kuitenkin tehdä businespäätös, että tuote laitetaan markkinoille näillä ja näillä bugeilla. Pointti tässä on se, että näiden bugien täytyy olla tiedossa eli testattuna. Bugien korjaus sitten priorisoidaan erilaisia menetelmiä käyttäen ja korjaukset toimitetaan asiakkaille nopealla aikataululla.
Huhujen mukaan ongelma olisi aiheutunut siitä että algoritmin testausta varten rakennettu ohjelma meni vahingossa uuden version asennuksen mukana tuotantoon tekemään kauppoja.
Ohjelmistoista löytyy aina bugeja, se on selkeä ja vääjäämätön asia. Voidaan osoittaa tiettyjä poikkeustapauksia, joiden käyttökohde vaatii huomattavan suurta testausta, niistäkin löytyy bugeja (satelliitit, sydäntahdistin, jne.).
Bugien määrällä ei ole sinänsä merkitystä. On aivan sama, onko bugeja 10, 100, 1000, jne. Bugien laatu ja näkyvys käyttäjälle, vaikutus dataan, jne., se ratkaisee.
Yksi kriittinen bugi voi aiheuttaa koko järjestelmän käyttökelvottomuuden. Esim. digiboxi ei ikinä saa purettua bittivirtaa, koska yksi bitti on väärässä asennossa. Kuva ei näy ollenkaan, joten tuote ja lähetysjärjestelmä on hyödytön. Toisaalta, suurikin muutos datassa voi näkyä pienenä haittana, muttei ole vakava. Esim. digiboxin suuresta datavirrasta osa on korruptoitunut ja aiheuttaa jonkin verran pikselöitymistä kuvassa. Uutiset kuitenkin voi katsoa, pientä harmistusta aiheuttaen.
Ns. bugiton softa on mielettömän kallista, koska määrittelyyn, testaamiseen, ympäristön stabiloimiseen ym. pitää käyttää paljon aikaa=rahaa. Jos järjestelmässä yksi komponentti päivitetään, pitää suuri osa testata uudestaan. Mitä osia testataan, se pitää analysoida ennen päivitystä. Ja sekin vie aikaa=rahaa.
Laadunvarmistuksessa on kyse myös mm. mittauksesta, arvioinneista, laadun analysoinnista ja ymmärtämisestä. Kyse ei ole vain testikeissin ajamisesta ja bugin rapsaamisesta. Toki nuokin ovat tärkeitä asioita, testikeissin ajamisella verifioidaan etukäteen laaditun suunnitelman mukaan tietyllä tavalla, tietty osa ohjelmistosta. Ja bugirapsalla ohjataan palaute eteenpäin.
Antti: mielenkiintoinen huhu ja hyvinkin voi olla mahdollinen. Löytyskö tuohon jottain lähdettä?
Jaha: mainiosti tiivistetty testauksen merkityksen moniulotteisuus. Testauksen pitää lähteä täysin eri olettamuksista, kun vastakkain laitetaan vaikkapa mobiilipeli tai lentokoneen autopilottisofta. Toisaalta, testaukselle aiheutuu myös täysin eri vaatimukset, jos mobiilipelin haluaa julkaista äärimmäisen menestynyt yritys verrattuna yritykseen, joka pukkaa ensimmäisen pelinsä maailmalle. Testaus ei voi olla erillinen saareke, vaan sillä pitäisi aina olla liiketaloudelliset lähtökohdat.
Syksy 2011
Ehdokkaani kalleimmaksi bugiksi on ehdottomasti Hollantilainen DigiNotar certificate authority, jonka järjestelmän suojauksiin jäänyt alokasmainen moka salli iranilaisen (?) hakkerin varastaa yli 500 yritysten SSL-suojauksissaan käyttämää pääsertifikaattia.
Jos kämmi ei suorastaan euro/dollarimääräisesti ehkä ollutkaan kallis, niin suhteellisesti vahinko oli tasan 100%. Koska moisen yhtiön ainoa myytävä tuote on luottamus loppui tämän yksittäisen insidentin takia firmalta koko liiketoiminta ja yritys hakeutui vararikkoon saman tien.
Siis vakavarainen yhtiö –> hakkeri –> yhtiön arvo 0 ja aikajanana tässä yhteydessä pikemminkin tuntiskaala.