Yleensä, jos projektiluontoisessa työssä jää aikaa, niin suoritetaan perusteellinen järjestelmätesti.
Paras tapa suorittaa tämä on syöttää järjestelmällisesti virheellistä irrationaalista syötettä järjestelmään ja tämän vuoksi on otettava pomolta perusteltuja erivapauksia järjestelmän käyttötavasta.
Tahallaan väärinkäytetyn järjestelmän toiminnasta voidaan tehdä havaintoja ja miettiä sen laatukriteerejä - täyttäisikö se laatukriteerit tositilanteessa ja voidaanko välillisesti syntyvät vahingot ennalta minimoida sallitulle hallittavalle tasolle.
Testi on syytä tehdä ennen järjestelmän tuotantoonottoa, jolloin järjestelmästä vastaava toimittaja ja sen käyttäjä eivät joudu ristiriitaiseen tilanteeseen virheellisen käytön seurauksista. Vaikka järjestelmä toimisikin kaikkien speksien mukaan, niin silti saattaa vastaan tulla tilanteita, joita ei suunnitteluvaiheessa ole otettu huomioon.
Murphyn laki sanoo, että jos jokin voi mennä pieleen, niin ennenpitkää se meneekin totaalisen pieleen. Testaamisella pidennetään siis vain MTBF (Mean-Time-Between-Failure) väliä. Seurauksena on järjestelmän vakiintuneempi käytänne sen käytössä, mikä myöskin lisää turvallisuutta ja luotettavuutta sen käyttäjien keskuudessa.
Se, että vapaamuurariutta lähentelevien erivapauksien ottamisesta ilmoitetaan pomolle vasta testaamisen puolessa välissä, saa johdon tietenkin paniikkiin ; tällä voidaan samalla testata myöskin koko järjestelmätoimitusta ketään poislukematta - kun virheraportteja tulee siihen malliin, että nyt on piru irti ja kaikki menee päin helvettiä.
Pääsääntöisesti järjestelmät kuitenkin onneksi toimivat rationaalisesti hallitusti, koska virhekertymä on kerrallaan pieni ja helposti manuaalisesti korjattavissa.
Oleellinen kysymys on, että pystyykö mahdollisimman täydellinen, mutta silti käytännössä vajaa järjestelmä sopeutumaan kaikenlaiseen mahdolliseen syötteeseen kaatumatta.
Laatu = testaaminen * toimivuus * kapasiteetti
Puhunko nyt ohjelmiston laatukriteereistä?
Savolainen vastaus: se on kuulijan korvien välissä mistä nyt puhun.
Paras tapa suorittaa tämä on syöttää järjestelmällisesti virheellistä irrationaalista syötettä järjestelmään ja tämän vuoksi on otettava pomolta perusteltuja erivapauksia järjestelmän käyttötavasta.
Tahallaan väärinkäytetyn järjestelmän toiminnasta voidaan tehdä havaintoja ja miettiä sen laatukriteerejä - täyttäisikö se laatukriteerit tositilanteessa ja voidaanko välillisesti syntyvät vahingot ennalta minimoida sallitulle hallittavalle tasolle.
Testi on syytä tehdä ennen järjestelmän tuotantoonottoa, jolloin järjestelmästä vastaava toimittaja ja sen käyttäjä eivät joudu ristiriitaiseen tilanteeseen virheellisen käytön seurauksista. Vaikka järjestelmä toimisikin kaikkien speksien mukaan, niin silti saattaa vastaan tulla tilanteita, joita ei suunnitteluvaiheessa ole otettu huomioon.
Murphyn laki sanoo, että jos jokin voi mennä pieleen, niin ennenpitkää se meneekin totaalisen pieleen. Testaamisella pidennetään siis vain MTBF (Mean-Time-Between-Failure) väliä. Seurauksena on järjestelmän vakiintuneempi käytänne sen käytössä, mikä myöskin lisää turvallisuutta ja luotettavuutta sen käyttäjien keskuudessa.
Se, että vapaamuurariutta lähentelevien erivapauksien ottamisesta ilmoitetaan pomolle vasta testaamisen puolessa välissä, saa johdon tietenkin paniikkiin ; tällä voidaan samalla testata myöskin koko järjestelmätoimitusta ketään poislukematta - kun virheraportteja tulee siihen malliin, että nyt on piru irti ja kaikki menee päin helvettiä.
Pääsääntöisesti järjestelmät kuitenkin onneksi toimivat rationaalisesti hallitusti, koska virhekertymä on kerrallaan pieni ja helposti manuaalisesti korjattavissa.
Oleellinen kysymys on, että pystyykö mahdollisimman täydellinen, mutta silti käytännössä vajaa järjestelmä sopeutumaan kaikenlaiseen mahdolliseen syötteeseen kaatumatta.
Laatu = testaaminen * toimivuus * kapasiteetti
Puhunko nyt ohjelmiston laatukriteereistä?
Savolainen vastaus: se on kuulijan korvien välissä mistä nyt puhun.
Vastaukset 7
Vanhimmat
kuule meet sillee maate ja rupeet vetaa zetaa
Ei testausta oteta projektiin mukaan lainkaan. Äkkiä vaan markkinoille. Asiakas testaa sitten...
Vapaamuurarit... erivapaudet... järjestelmällinen irrationaalisuus...
Mä en nyt oikein ymmärrä tota viestiä. Onks tää joku testi?
Et nimittäin tajua testaamisesta yhtään mitään!
Onhan noita järjestelmiä.... En tee testausta, koska mol:in järjestelmä on järjestänyt kokeet kahden viikon päähän, eikä ole aikaa testailla kaikkea.
Tajusin juuri, ettet tajunnut mitä halusin sinun tajuavan tajuamisestani.
tuo sinun testaamisesi.
Testaaminen perustuu speksissä olevien kohteiden tarkistamiseen sekä heikoiksi arveltujen kohtien kokeiluun. Yllättävän usein se softa ei teekään sitä mitä dokumentti lupaa, tai koodari luulee sen tekevän.
Mutta esimerkiksi selaimia testataankin myös kuvaamallasi tavalla, generoiduilla virheellisillä webbisivuilla. Ja katsotaan, kaatuuko.
Monesti ongelma on pikemminkin siinä, että yksikkötestaus tarkoittaa lähinnä sitä kääntyykö softa vai ei. Jo yksikkötestauksessa voisi kuitenkin käyttää esimerkiksi dataa jossa villejä enkoodauksia ja muutenkin kokeilla myös pari poikkeusta per toiminto. Näin järjestelmätestaukseen jäisivät vain ne asiat jotka oikeasti vaativat koko järjestelmän.