Usein testiautomaatiossa keskitytään funktionaaliseen testaukseen. Testiautomaatio-caset rakennetaan suorittamaan ohjelman vaatimusten mukaista toiminnallisuutta. Tärkeintähän on, että ohjelma toimii niin kuin pitääkin ja jos toiminallisuus on kunnossa, niin ohjelma on valmis tuotantoon, eikö niin? Vai onko sittenkään? Minkä näkökulman jätämme testaamatta? Sen, miltä ohjelma näyttää visuaalisesti.
Visuaalisen testauksen tarkoitus on löytää bugit, jotka syntyvät UI-komponentteja päivittäessä. Visuaalinen testaus vie manuaalisesti paljon aikaa ja sen onnistuminen riippuu testaajan silmän tarkkuudesta. Gregory Goldshteyn (2016) listaa artikkelissaan neljä kohtaa, jotka muodostavat hänen visuaalisen testauksen checklistinsa. Nämä neljä kohtaa ovat:
- Varmista, että jokainen UI-komponentti on oikean kokoinen, muotoinen, värinen ja oikeassa paikassa
- Varmista, etteivät UI-komponentit ole päällekkäin tai peitä toisiaan
- Varmista, ettei ruutukoon muutos riko UI-komponentteja (esim. tabletit, kännykät, pöytäkone)
- Varmista, että kaikki kuvat näkyvät oikein
Miten voimme hyödyntää testiautomaatiota web-sivun visuaalisessa testaamisessa? Applitools Eyes (https://applitools.com/) on visuaalisen testauksen automatisointiin tarkoitettu työkalu, jota käytetään web-sovelluksena. Sovelluksen saa toimimaan esim. Chromeen ladattavana Applitools Eyes Express -lisäosana (https://chrome.google.com/webstore/detail/applitools-eyes-express/ofhaaccocoghamklkjfliehhdhmibdbh). Web-käyttöliittymä on yksinkertainen ja helppokäyttöinen, kuten myös lisäosan käyttäminenkin. Lisäosan toiminnolla voi ottaa kuvan aukiolevasta web-sivusta baselineksi, ja toisella kerralla otettua kuvaa verrataan baselineen. Kuvien erot näytetään vierekkäin, erot korostettuina. Jos kuvissa on eroja (eli uusi versio web-sivusta ei vastaa alkuperäistä), testi näyttää punaista ja epäonnistuu. Testicaseihin voi asettaa erilaisia suoja-alueita, esim. dynaamisesti vaihtuvaa sisältöä, kuten mainoksia, varten. Erojen huomaamisen tasoa voi säätää tiukasta löyhään tai sen voi asettaa tutkimaan vain sivun layoutin säilymistä.
Vaikka Applitools Eyes tuntuukin helpottavan visuaalisen testauksen työurakkaa, testicasejen suunnittelu (eli ensimmäiset ajot määritelmän asettamiseksi) vievät aikaa ja niitä pitää päivittää usein. Applitools on kuitenkin hyvä huomaamaan ne pienetkin erot tai virheet, mitkä helposti menevät ihmisiltä ohi. Sen käytön voidaan katsoa vähentävän graafisten virheiden määrää sovelluksen tulevaisuudessa. No, katsotaan. Kauneus on katsojan silmässä.
Lähteet:
Applitools Eyes, Saatavilla: https://applitools.com/
Applitools Eyes Express -lisä Google Chromeen, Saatavilla: https://chrome.google.com/webstore/detail/applitools-eyes-express/ofhaaccocoghamklkjfliehhdhmibdbh
"Review of Visual vs. Functional Testing with Applitools", Gregory Goldshteyn, 12.01.2016. Saatavilla: https://www.linkedin.com/pulse/review-visual-vs-functional-testing-applitools-gregory-goldshteyn
Robot-AppEyes, Robot Framework moduuli Applitoolsille, Saatavilla: http://navinet.github.io/Robot-AppEyes/
Applitools Eyes (Visuaalisen testauksen automatisointi)
torstai 19. tammikuuta 2017
Smoke testing, joka tunnetaan myös nimillä confidence testing, sanity testing, build verification test (BVT) ja build acceptance test, tarkoittaa ohjelmiston valmistavaa testausta ennen julkaisua, jonka tarkoituksena on varmistua siitä, että ohjelmiston tärkeimmät ominaisuudet toimivat. Smoke-testaus suunnitellaan siten, että testicaset kattavat järjestelmän tai sen moduulin kriittisimmän toiminnallisuuden. Mutta mikä on se syy, miksi smoke-testausta tehdään?
Nykyaikaisten ohjelmistojen arkkitehtuuri perustuu yksittäisiin moduuleihin, jotka toteuttavat tietyn toiminallisuuden ja siihen, että moduulit viestivät ja toimivat keskenään yhteen. Useiden eri moduulien muodostamat kokonaisuudet ovat usein hyvin monimutkaisia, jolloin vain harvalla on kokonaiskuva järjestelmän täydellisestä toiminnasta ja siitä, miten yksittäisten moduulien toiminta vaikuttaa koko järjestelmään. Usein esimerkiksi alimman tason moduulin toteutus on hämärretty, eikä ohjelmistokehittäjää edes kiinnosta, miten sen sisäinen logiikka on toteutettu, kunhan moduulin tuottama output-data on oikeanlaista muiden moduulien käyttöön.
Tässä kuitenkin piilee inhimillisen virheen mahdollisuus. Nykyaikainen ketterä, agile, ohjelmistokehitys on nimensä mukaisesti nopeatahtista ja yksittäisiä moduuleja päivitetään tai muutetaan päivittäin. Koska nämä moduulit ovat tiivisti yhteydessä muihin moduuleihin, pienikin, harmittomalta vaikuttanut muutos yhden moduulin toiminnassa voi rikkoa koko järjestelmän yhteistoiminnan, odottamattomasti.
Tämän takia päivittäistä kääntämistä (daily build) ja sen automatisoitua smoke-testausta pidetään yhtenä ohjelmistokehityksen "hyvistä käytännöistä", best practices. Päivittäisellä automatisoidulla smoke-testauksella saadaan kiinni kaikki ne odottamattomat bugit, jotka syntyivät kehittäjän eilen tekemästä muutoksesta. Bugit havaitaan siten ajoissa ja toimiva ohjelmistoversio voidaan palauttaa ennen kuin epätoimivaa ohjelmistoversiota ehditään kehittää pidemmälle. Testaajina tiedämme, että tämä tarkoittaa mahdollisesti suuria säästöjä niin ajassa, rahassa kuin miestyövuosissakin.
Smoke-testauksella voidaan siis saada nopea vastaus ohjelmiston yleisen tason toimivuudesta. Sen tehtävänä, kuten testauksella yleisestikin, on luoda luottamusta ohjelmiston laatuun. Smoke-testauksella voimme olla varma, että meidän jokapäiväinen buildimme toimii huomennakin.
Lähde:
Smoke testing (software), Wikipedia. Saatavilla: https://en.wikipedia.org/wiki/Smoke_testing_(software)
Nykyaikaisten ohjelmistojen arkkitehtuuri perustuu yksittäisiin moduuleihin, jotka toteuttavat tietyn toiminallisuuden ja siihen, että moduulit viestivät ja toimivat keskenään yhteen. Useiden eri moduulien muodostamat kokonaisuudet ovat usein hyvin monimutkaisia, jolloin vain harvalla on kokonaiskuva järjestelmän täydellisestä toiminnasta ja siitä, miten yksittäisten moduulien toiminta vaikuttaa koko järjestelmään. Usein esimerkiksi alimman tason moduulin toteutus on hämärretty, eikä ohjelmistokehittäjää edes kiinnosta, miten sen sisäinen logiikka on toteutettu, kunhan moduulin tuottama output-data on oikeanlaista muiden moduulien käyttöön.
Tässä kuitenkin piilee inhimillisen virheen mahdollisuus. Nykyaikainen ketterä, agile, ohjelmistokehitys on nimensä mukaisesti nopeatahtista ja yksittäisiä moduuleja päivitetään tai muutetaan päivittäin. Koska nämä moduulit ovat tiivisti yhteydessä muihin moduuleihin, pienikin, harmittomalta vaikuttanut muutos yhden moduulin toiminnassa voi rikkoa koko järjestelmän yhteistoiminnan, odottamattomasti.
Tämän takia päivittäistä kääntämistä (daily build) ja sen automatisoitua smoke-testausta pidetään yhtenä ohjelmistokehityksen "hyvistä käytännöistä", best practices. Päivittäisellä automatisoidulla smoke-testauksella saadaan kiinni kaikki ne odottamattomat bugit, jotka syntyivät kehittäjän eilen tekemästä muutoksesta. Bugit havaitaan siten ajoissa ja toimiva ohjelmistoversio voidaan palauttaa ennen kuin epätoimivaa ohjelmistoversiota ehditään kehittää pidemmälle. Testaajina tiedämme, että tämä tarkoittaa mahdollisesti suuria säästöjä niin ajassa, rahassa kuin miestyövuosissakin.
Smoke-testauksella voidaan siis saada nopea vastaus ohjelmiston yleisen tason toimivuudesta. Sen tehtävänä, kuten testauksella yleisestikin, on luoda luottamusta ohjelmiston laatuun. Smoke-testauksella voimme olla varma, että meidän jokapäiväinen buildimme toimii huomennakin.
Lähde:
Smoke testing (software), Wikipedia. Saatavilla: https://en.wikipedia.org/wiki/Smoke_testing_(software)
maanantai 9. tammikuuta 2017
Jos apinalle antaisi tietokoneohjelman testattavaksi, miten apina suorittaisi tehtävän? Lopputuloksena olisi todennäköisesti jono satunnaisia näppäinpainalluksia ja hajonnut tietokoneen näppäimistö. Oliko apinasta siis mitään hyötyä vai ei?
Apinatestauksella (Monkey testing) tarkoitetaan testausta, jossa järjestelmälle annetaan satunnaisia syötteitä ja tutkitaan, miten järjestelmä selviytyy niiden käsittelystä. Usein juuri virheelliset syötteet, joiden käsittelyyn kehittäjät eivät ole osanneet varautua, johtavat järjestelmän vika- tai virhetilanteisiin. Apinatestaus onkin tärkeä työkalu järjestelmän häiriökestävyyden arvioinnissa (robustness). Satunnainen syöte voi myös tuoda uusia out-of-the-box ideoita järjestelmän koettelemiseen ja sillä tavoin antaa uusia keinoja löytää järjestelmän rikkovia bugeja.
On olemassa myös termi fuzz testing (sumea testaus), joka usein esiintyy apinatestauksen yhteydessä. Osa määrittelee termien eroksi sen, että apinatestaus viittaa nimenomaan satunnaisiin toimiin (random actions), kun taas sumea testaus viittaa syötetyn datan satunnaisuuteen (random input data). Toisin sanoen, sumeaa testausta on esimerkiksi se, että syöttää ohjelmalle Excel-taulukon, jonka dataa on muokattu tai rikottu määritelmien vastaiseksi. Apinatestauksen esimerkki voisi puolestaan olla ohjelman käyttäminen painamalla satunnaisesti jokaista käytettävissä olevaa nappia.
Apinat voidaan jakaa älykkäisiin (smart) ja tyhmiin (dumb). Sama pätee myös apinatestauksessa.
Älykkäillä apinoilla on suppea idea järjestelmän toiminnasta, älykkäät apinat tietävät oman paikkansa ja kykynsä ja järjestelmän kyvyt, älykkäät apinat ovat fokusoituneet järjestelmän rikkomiseen ja osaavat raportoida niistä. Tyhmät apinat eivät tiedä mitään järjestelmän toiminnasta, tyhmät apinat eivät osaa syöttää oikeanlaista syötettä, tyhmät apinat eivät tiedä omia tai järjestelmän kykyjä, eivätkä ne toimi suunnitelmallisesti.
Testaamisen ei pitäisi olla päämäärätöntä näppäimistön hakkaamista, mutta silti siitä näyttää aina silloin tällöin olevan hyötyä. Arvelisin kuitenkin, että koulutettu testaaja tulee silti halvemmaksi kuin lennättää simpanssi Espooseen ja opettaa sille koodaamista. Banaanejakaan ei tarvitse ostaa.
Lähteet:
Monkey Testing, Wikipedia. Saatavilla: https://en.wikipedia.org/wiki/Monkey_testing
Apinatestauksella (Monkey testing) tarkoitetaan testausta, jossa järjestelmälle annetaan satunnaisia syötteitä ja tutkitaan, miten järjestelmä selviytyy niiden käsittelystä. Usein juuri virheelliset syötteet, joiden käsittelyyn kehittäjät eivät ole osanneet varautua, johtavat järjestelmän vika- tai virhetilanteisiin. Apinatestaus onkin tärkeä työkalu järjestelmän häiriökestävyyden arvioinnissa (robustness). Satunnainen syöte voi myös tuoda uusia out-of-the-box ideoita järjestelmän koettelemiseen ja sillä tavoin antaa uusia keinoja löytää järjestelmän rikkovia bugeja.
On olemassa myös termi fuzz testing (sumea testaus), joka usein esiintyy apinatestauksen yhteydessä. Osa määrittelee termien eroksi sen, että apinatestaus viittaa nimenomaan satunnaisiin toimiin (random actions), kun taas sumea testaus viittaa syötetyn datan satunnaisuuteen (random input data). Toisin sanoen, sumeaa testausta on esimerkiksi se, että syöttää ohjelmalle Excel-taulukon, jonka dataa on muokattu tai rikottu määritelmien vastaiseksi. Apinatestauksen esimerkki voisi puolestaan olla ohjelman käyttäminen painamalla satunnaisesti jokaista käytettävissä olevaa nappia.
Apinat voidaan jakaa älykkäisiin (smart) ja tyhmiin (dumb). Sama pätee myös apinatestauksessa.
Älykkäillä apinoilla on suppea idea järjestelmän toiminnasta, älykkäät apinat tietävät oman paikkansa ja kykynsä ja järjestelmän kyvyt, älykkäät apinat ovat fokusoituneet järjestelmän rikkomiseen ja osaavat raportoida niistä. Tyhmät apinat eivät tiedä mitään järjestelmän toiminnasta, tyhmät apinat eivät osaa syöttää oikeanlaista syötettä, tyhmät apinat eivät tiedä omia tai järjestelmän kykyjä, eivätkä ne toimi suunnitelmallisesti.
Testaamisen ei pitäisi olla päämäärätöntä näppäimistön hakkaamista, mutta silti siitä näyttää aina silloin tällöin olevan hyötyä. Arvelisin kuitenkin, että koulutettu testaaja tulee silti halvemmaksi kuin lennättää simpanssi Espooseen ja opettaa sille koodaamista. Banaanejakaan ei tarvitse ostaa.
Lähteet:
Monkey Testing, Wikipedia. Saatavilla: https://en.wikipedia.org/wiki/Monkey_testing
torstai 29. joulukuuta 2016
Mitä tarkoitetaan mustalla tai valkoisella laatikolla testauksessa? Aloitetaan laatikoiden määritelmillä.
Musta laatikko (Black-box) on järjestelmä, jonka sisäinen toimintalogiikka on tuntematon. Pystymme havaitsemaan järjestelmään liitetyt sisääntulot (input) ja siitä lähtevät ulostulot (output), muttemme tiedä, miten ulostuloa on tässä välissä muokattu. Usein pystymme päättelemään sisään- ja ulostulon eroista, mitä muutoksia järjestelmä tekee sisääntuloon, muttemme voi varmuudella sanoa, miten tai millä logiikalla ne on toteutettu.
Valkoinen laatikko (White-box) on järjestelmä, jonka sisäinen toimintalogiikka on tunnettu. Meillä on tietoa järjestelmän toteutuksen teknisistä yksityiskohdista ja sen logiikkaa kuvaava tekninen dokumentaatio. Logiikkakuvauksen avulla tiedämme täsmälleen, miten tai millä logiikalla järjestelmä muokkaa sisääntuloa.
Entä näiden laatikoiden testaus? Mitä black-box & white-box testing tarkoittavat käytännössä ja mitä eroja niillä on?
White-box testauksessa (tunnetaan myös nimellä Structure-based testing) järjestelmän sisäisestä rakenteesta johdetaan dynaamisesti testicaset, kun taas black-box testauksessa meillä on käytössä vain tiettyjä, järjestelmän ulkoisiin ominaisuuksiin nojaavia, spesifejä testejä. White-box testaus on siis testaajan kannalta monta kertaa mukavampaa ja tehokkaampaa, koska tiedämme, miten järjestelmä toimii, eikä sitä tarvitse arvuutella. Black-box testauksessa olemme täysin omillamme, eikä meillä ole mitään varmuutta siitä, että käyttämämme testit suorittavat kaiken ohjelmakoodin - vaikka maailman osaavin testausammattilaisten tiimi black-box testaisi mitä tahansa järjestelmää, on silti hyvin mahdollista, että peräti 70 prosenttia kaikesta koodista ei suoritettaisi kertaakaan! (Mitchell & Black, 2015)
Boris Beizer kirjoittaa kirjassaan Software Testing Techniques (ITC Press, 1990) yleisiä sääntöjä liittyen ohjelmakoodin suoritukseen ja bugien todennäköisyyteen:
1. Testaamatta jätetty koodinpätkä jättää järjestelmään bugeja. Bugien määrää voidaan arvioida kaavalla: testaamaton koodi * bugien todennäköisyys
2. Ohjelman yleisimpien suoritusteiden (pathien) testaus, varsinkin yksikkötestitasolla, ei ole niin tärkeää kuin harvinaisten suoritusteiden, koska järjestelmän toiminta kokonaisuudessaan testataan vielä myöhemmin järjestelmätasolla.
3. Logiikkavirheet tai logiikan sumeus (fuzzy thinking) ovat kääntäen verrannollisia pathin suorittamisen todennäköisyyteen.
4. Ohjelmoijat eivät useinkaan osaa arvioida ohjelman käyttämien pathien suoritustodennäköisyytttä - vain analyysi kertoo, mitä patheja suoritetaan todennäköisimmin.
5. Koodisegmenttien tärkeyden arviointi on subjektiivista ja voi johtaa virheisiin. Ohjelmoija voi olla niin ylpeä kauniista koodistaan tai tekemästään monimutkaisesta algoritmista, että testaa sen monta kertaa, mutta jättää testaamatta yksinkertaisen for-loopin, koska ajattelee "Mikä noin yksinkertaisessa lauseessa voi mennä pieleen?".
Listassa on ainakin muutama hyvä syy, miksi testaajan on tärkeää tietää suoritetun koodin määrä ja miksi järjestelmiä pitäisi aina testata white-box testauksella - testaus on siis sitä helpompaa, mitä enemmän tietää ohjelman suorittamista reiteistä tai koodin määrästä. Mustat laatikot kannattaa suosiolla jättää lentokoneisiin.
Lähteet:
Mitchell, Jamie L. & Black, Rex. "Advanced Software Testing, Vol. 3. Second Edition". (2015). p. 24-26. Rocky Nook.
Beizer, Boris. "Software Testing Techniques". (1990). ITC Press.
Musta laatikko (Black-box) on järjestelmä, jonka sisäinen toimintalogiikka on tuntematon. Pystymme havaitsemaan järjestelmään liitetyt sisääntulot (input) ja siitä lähtevät ulostulot (output), muttemme tiedä, miten ulostuloa on tässä välissä muokattu. Usein pystymme päättelemään sisään- ja ulostulon eroista, mitä muutoksia järjestelmä tekee sisääntuloon, muttemme voi varmuudella sanoa, miten tai millä logiikalla ne on toteutettu.
Valkoinen laatikko (White-box) on järjestelmä, jonka sisäinen toimintalogiikka on tunnettu. Meillä on tietoa järjestelmän toteutuksen teknisistä yksityiskohdista ja sen logiikkaa kuvaava tekninen dokumentaatio. Logiikkakuvauksen avulla tiedämme täsmälleen, miten tai millä logiikalla järjestelmä muokkaa sisääntuloa.
Entä näiden laatikoiden testaus? Mitä black-box & white-box testing tarkoittavat käytännössä ja mitä eroja niillä on?
White-box testauksessa (tunnetaan myös nimellä Structure-based testing) järjestelmän sisäisestä rakenteesta johdetaan dynaamisesti testicaset, kun taas black-box testauksessa meillä on käytössä vain tiettyjä, järjestelmän ulkoisiin ominaisuuksiin nojaavia, spesifejä testejä. White-box testaus on siis testaajan kannalta monta kertaa mukavampaa ja tehokkaampaa, koska tiedämme, miten järjestelmä toimii, eikä sitä tarvitse arvuutella. Black-box testauksessa olemme täysin omillamme, eikä meillä ole mitään varmuutta siitä, että käyttämämme testit suorittavat kaiken ohjelmakoodin - vaikka maailman osaavin testausammattilaisten tiimi black-box testaisi mitä tahansa järjestelmää, on silti hyvin mahdollista, että peräti 70 prosenttia kaikesta koodista ei suoritettaisi kertaakaan! (Mitchell & Black, 2015)
Boris Beizer kirjoittaa kirjassaan Software Testing Techniques (ITC Press, 1990) yleisiä sääntöjä liittyen ohjelmakoodin suoritukseen ja bugien todennäköisyyteen:
1. Testaamatta jätetty koodinpätkä jättää järjestelmään bugeja. Bugien määrää voidaan arvioida kaavalla: testaamaton koodi * bugien todennäköisyys
2. Ohjelman yleisimpien suoritusteiden (pathien) testaus, varsinkin yksikkötestitasolla, ei ole niin tärkeää kuin harvinaisten suoritusteiden, koska järjestelmän toiminta kokonaisuudessaan testataan vielä myöhemmin järjestelmätasolla.
3. Logiikkavirheet tai logiikan sumeus (fuzzy thinking) ovat kääntäen verrannollisia pathin suorittamisen todennäköisyyteen.
4. Ohjelmoijat eivät useinkaan osaa arvioida ohjelman käyttämien pathien suoritustodennäköisyytttä - vain analyysi kertoo, mitä patheja suoritetaan todennäköisimmin.
5. Koodisegmenttien tärkeyden arviointi on subjektiivista ja voi johtaa virheisiin. Ohjelmoija voi olla niin ylpeä kauniista koodistaan tai tekemästään monimutkaisesta algoritmista, että testaa sen monta kertaa, mutta jättää testaamatta yksinkertaisen for-loopin, koska ajattelee "Mikä noin yksinkertaisessa lauseessa voi mennä pieleen?".
Listassa on ainakin muutama hyvä syy, miksi testaajan on tärkeää tietää suoritetun koodin määrä ja miksi järjestelmiä pitäisi aina testata white-box testauksella - testaus on siis sitä helpompaa, mitä enemmän tietää ohjelman suorittamista reiteistä tai koodin määrästä. Mustat laatikot kannattaa suosiolla jättää lentokoneisiin.
Lähteet:
Mitchell, Jamie L. & Black, Rex. "Advanced Software Testing, Vol. 3. Second Edition". (2015). p. 24-26. Rocky Nook.
Beizer, Boris. "Software Testing Techniques". (1990). ITC Press.
Paljonko bugit maksavat?
Paljonko virheet koodissa voivat pahimmillaan maksaa? Tämähän on se syy, miksi testataan - jotta vältyttäisiin katastrofeilta ja miljoonien eurojen vahingonkorvauksilta. Tiedämme, että määrittelyvaiheessa löydetyn bugin hinta on keskimäärin 100€, laatutestausvaiheessa 1500€ ja tuotannossa 10 000 euroa (Leon, 2015). Toisten arvioiden mukaan hintaluokka kasvaa aina tason noustessa yhdellä nollalla. Joka tapauksessa kallista. Ja aina silloin tällöin epätodennäköisiltäkin vaikuttaneet riskit voivat realisoitua ja pahin tapahtua.
Tähän alas olen kerännyt muutaman esimerkin projekteista, joissa testaus on pettänyt ja kaikki on mennyt pahimman laatuisesti pieleen:
- Ariana 5 avaruusraketti:
Ariane 5:n ensimmäinen testilento 4.6.1996 päättyi näyttävään räjähdykseen 37 sekuntia lähtönsä jälkeen, koska sitä ohjanneessa ohjelmistossa oli bugi - tyyppimuunnos 64-bittisestä liukuluvusta (floating point number)16-bittiseksi etumerkilliseksi kokonaisluvuksi (signed integer) aiheutti virheen, koska liukuluku oli liian suuri esitettäväksi 16-bittisenä etumerkillisenä kokonaislukuna.
BUGIN HINTA: Raketin lähdön hinnaksi oli arvioitu 165 - 220 miljoonaa dollaria (Wikipedia, 2016)
- Toyotan takaisinveto:
Elokuussa 2009 neljää matkustajaa kuljettanut Toyota Lexus ES350 alkoi yllättäen kiihdyttää yli 160 km/h nopeuteen, kunnes ajoi ulos tieltä, tappaen matkustajat. Toyotan mukaan autossa oli ohjelmistovirhe, joka aiheutti lagia auton lukituksenestojärjestelmässä. Toyota päätyi vetämään maailmanlaajuisesti takaisin yli 9 miljoonaa autoa vuonna 2010.
BUGIN HINTA: Takaisinvedot, vahingonkorvausvelvoitteet ja markkinointikulujen arvioidaan maksaneen Toyotalle jopa 3 miljardia dollaria. (Leon, 2015)
-Knight Capital:
Vuonna 2012 pörssivälitysyhtiö Knight Capital otti käyttöön uuden osakkeiden välitysohjelmansa. Valitettavasti ohjelman osto- ja myyntialgoritmi toimi hieman kehnosti, se nimittäin osti osakkeita pyydetyllä hinnalla, mutta myi ne välittömästi 15 prosenttia halvemmalla.
BUGIN HINTA: Vääriä välityksiä tapahtui 40 kertaa sekunnissa, 2400 kertaa minuutissa ja ne polttivat rahaa Knight Capitalilta lähes 440 miljoonaa dollaria. (Gang, 2016)
Tästä voi ottaa vain opiksi. Testaa tai itke.
Lähteet:
Ariane 5, Wikipedia. Saatavilla: https://en.wikipedia.org/wiki/Ariane_5
Janet Leon, "The True Cost of a Software Bug: Part One". 28.02.2015. Celerity. Saatavilla: http://blog.celerity.com/the-true-cost-of-a-software-bug
Gang, T. Penn State University. Saatavilla: http://www.cse.psu.edu/~gxt29/bug/softwarebug.html
Tähän alas olen kerännyt muutaman esimerkin projekteista, joissa testaus on pettänyt ja kaikki on mennyt pahimman laatuisesti pieleen:
- Ariana 5 avaruusraketti:
Ariane 5:n ensimmäinen testilento 4.6.1996 päättyi näyttävään räjähdykseen 37 sekuntia lähtönsä jälkeen, koska sitä ohjanneessa ohjelmistossa oli bugi - tyyppimuunnos 64-bittisestä liukuluvusta (floating point number)16-bittiseksi etumerkilliseksi kokonaisluvuksi (signed integer) aiheutti virheen, koska liukuluku oli liian suuri esitettäväksi 16-bittisenä etumerkillisenä kokonaislukuna.
BUGIN HINTA: Raketin lähdön hinnaksi oli arvioitu 165 - 220 miljoonaa dollaria (Wikipedia, 2016)
- Toyotan takaisinveto:
Elokuussa 2009 neljää matkustajaa kuljettanut Toyota Lexus ES350 alkoi yllättäen kiihdyttää yli 160 km/h nopeuteen, kunnes ajoi ulos tieltä, tappaen matkustajat. Toyotan mukaan autossa oli ohjelmistovirhe, joka aiheutti lagia auton lukituksenestojärjestelmässä. Toyota päätyi vetämään maailmanlaajuisesti takaisin yli 9 miljoonaa autoa vuonna 2010.
BUGIN HINTA: Takaisinvedot, vahingonkorvausvelvoitteet ja markkinointikulujen arvioidaan maksaneen Toyotalle jopa 3 miljardia dollaria. (Leon, 2015)
-Knight Capital:
Vuonna 2012 pörssivälitysyhtiö Knight Capital otti käyttöön uuden osakkeiden välitysohjelmansa. Valitettavasti ohjelman osto- ja myyntialgoritmi toimi hieman kehnosti, se nimittäin osti osakkeita pyydetyllä hinnalla, mutta myi ne välittömästi 15 prosenttia halvemmalla.
BUGIN HINTA: Vääriä välityksiä tapahtui 40 kertaa sekunnissa, 2400 kertaa minuutissa ja ne polttivat rahaa Knight Capitalilta lähes 440 miljoonaa dollaria. (Gang, 2016)
Tästä voi ottaa vain opiksi. Testaa tai itke.
Lähteet:
Ariane 5, Wikipedia. Saatavilla: https://en.wikipedia.org/wiki/Ariane_5
Janet Leon, "The True Cost of a Software Bug: Part One". 28.02.2015. Celerity. Saatavilla: http://blog.celerity.com/the-true-cost-of-a-software-bug
Gang, T. Penn State University. Saatavilla: http://www.cse.psu.edu/~gxt29/bug/softwarebug.html
tiistai 27. joulukuuta 2016
Mitä ominaisuuksia ohjelmistotestaaminen vaatii testaajalta? Mitä ominaisuuksia vaaditaan hyvältä testaajalta? Voidaanko luetella lista ominaisuuksia, jotka testaajan tulisi täyttää ollakseen alansa ammattilainen? Entä tulevaisuudessa?
Jan Mellemanin kirjoituksen "What type of human will still be a tester in 2025?" (Neil's Quest for Quality, 2014) mukaan tulevaisuuden testaaja on puhdasverinen, pur sang, ammattilainen, jonka osaaminen perustuu tietoon (knowledge), taitoihin(skills) ja kokemukseen (experience). Hänen mielestään testiammattilaisen pitää seurata alansa kehitystä, uusimpia työkaluja ja innovaatioita ja oikeasti haluta käyttää niitä jokapäiväisessä testauksessa. Testausammattilaisen pitää kehittää persoonansa emotionaalisia puolia, jotta hänestä tulee tiimipelaaja, joka ymmärtää missä bisneksen arvo (value) ja edut (benefits) majailevat. Testausmmattilainen on se ihmislinkki, joka yhdistää eri osastot ja järjestelmät toisiinsa ja valvoo niiden laatua. Testausmmattilainen kuuntelee asiakkaan toiveet, muuttaa ne vaatimusmäärittelyiksi ja rakentaa siltoja ohjelmisto-arkkitehdin ja kehittäjien välille.
Aika moneen pitäisi testaajan siis taipua.
Voisiko tuon edellisen kappaleen tiivistää listaksi hyvän testaajan ominaisuuksia? Kokeillaan:
Aika moneen pitäisi testaajan siis taipua.
Voisiko tuon edellisen kappaleen tiivistää listaksi hyvän testaajan ominaisuuksia? Kokeillaan:
Luova, utelias, analyyttinen, hyvä kuuntelija, proaktiivinen, nopea oppija, tekninen suuntautunut, asiakassuuntautunut, organisointi- ja priorisointikyvykäs, laatusuuntautunut, määrätietoinen ja peräksiantamaton. Tällaisia ominaisuuksia ISTQB koe -harjoitussivusto (ISTQB Exam Certification) listaa hyvälle testaajalle.
Okei, lista näyttää jo vähän selkeämmältä. Mutta mitä nuo ominaisuudet tarkoittavat käytännössä? Mitä taitoja ohjelmistotestaajalta vaaditaan käytännön työelämässä? Tmap Nextin (2006, Chapter 16 Test Roles) Testaajien roolit -luvun määritelmän mukaan Test Team Leaderin vaatimuksena on, että testaaja on laajalti tietoinen TMap life cycle -mallista sekä primaarisista testiaktiviteeteista, hänellä on erikoisosaamista testauksen arvioinnissa ja testisuunnittelutekniikoissa, hän osaa käyttää testityökaluja, hänellä on yleiset tiedot ja taidot informaatiotekniikassa, hänellä on tietoa järjestelmien kehityksestä ja kyvykkyys määrittää testauksen laajuus, johtamistaitoja, kokemusta projektisuunnittelusta ja -johtamisesta ja kyvykkyys valmentaa muita.
Mutta hyväksi testaajaksi ei pääse (pelkästään) lukemalla kirjoja. Hyväksi testaajaksi kasvaminen on pitkä ja vaikea prosessi. Jonkin tietyn kyvyn (lähes) täydellinen oppiminen vie ihmiseltä aikaa keskimäärin n. 10 000 tuntia, tai toisin sanoen, 10 vuotta jokapäiväistä parin tunnin harjoittelua. Eli helppoa tietä hyväksi testaajaksi ei ole. Ainoa, mikä siihen auttaa on testaus. Ja testaus. Ja testaus. Enää 9 000 tuntia jäljellä...
Lähteet:
Neil's Quest for Quality - A TMap HD Story (Alder Boersma & Erik Vooijs, 2014). "What type of human will still be a tester in 2025?". Jan Mellema. pp. 224 - 225. Sogeti.
ISTQB Exam Certification, istqexamcertification.com. (2016). Saatavilla: http://istqbexamcertification.com/software-tester/
TMap Next: for result-driven testing (2006). Chapter 16 Test Roles, s. 726. Sogeti Nederland B. V.
Neil's Quest for Quality - A TMap HD Story (Alder Boersma & Erik Vooijs, 2014). "What type of human will still be a tester in 2025?". Jan Mellema. pp. 224 - 225. Sogeti.
ISTQB Exam Certification, istqexamcertification.com. (2016). Saatavilla: http://istqbexamcertification.com/software-tester/
TMap Next: for result-driven testing (2006). Chapter 16 Test Roles, s. 726. Sogeti Nederland B. V.
keskiviikko 21. joulukuuta 2016
Neil’s Quest for Quality – A TMap HD Story (Alder Boersma & Erik Vooijs, 2014) on mielenkiintoinen yhdistelmä fiktiivistä tarinankerrontaa ja ohjelmistotestauksen teoriaa. Kirjassa seurataan päähenkilö Neilin silmin, millaista elämä on Test Managerina suuressa vakuutusalan yrityksessä ja sitä, miten Neil pärjää yrityksen uuden ohjelmistoprojektin Seabiscuitin testauksen toteuttamisessa. Fiktiivisen tarinan väliin on ripoteltu testauksen rakennuspalikoita (building blocks), jotka taustoittavat tarinassa etenevää testausprosessia aina lukujen välissä.
Kirjan nimessä oleva HD ei
viittaa tässä teräväpiirtotarkkuuteen, vaan ihmisvetoisuuteen – Human Driven. Kirjan parasta antia onkin
sen ihmiskeskeinen näkökulma testausprosessiin. Testaajien henkilökemioiden ja
motivaation merkityksen huomioiminen on jotakin, mikä on puuttunut esimerkiksi
alkuperäisestä TMap Nextistä (Sogeti
Netherlands, 2006).
Kaunokirjallisena teoksena kirja jää vaisuksi. Kielelliset kikkailut
on jätetty suosiolla pois ja tekstistä on pyritty tekemään mahdollisimman
funktionaalista ja selkeää. Päähenkilö Neil jätetään harmittavan etäiseksi,
eikä tähän tutustuta pintaa syvemmin. Tiedämme sivulauseiden perusteella, että
hän viettää liikaa aikaa töissä ja tämä aiheuttaa kitkaa kotona odottavan
Danielle-vaimon kanssa. Neilin sisäinen dialogi on käytännössä pohtimista
testauksesta kirjan kirjoittajien äänellä, mikä on toisaalta oiva tapa saada
yhdistetty draamaa ja teoriaa, mutta samalla se vie tilaa Neilin
hahmonkehitykseltä jättäen tämän ontoksi.
Monet sivuhahmot jäävät työrooliensa vangeiksi ja litistyvät karikatyyrimäisiksi
kuvauksiksi testianalyytikon, projektijohtajan, business managerin ja senior
managerin rooleista. Onneksi valopilkkujakin on – pohjoismaalainen testausasiantuntija
Mr. Mikkel on salamyhkäisyydessään herkullinen hahmo, jonka suulla sanotaan
kirjan mieleenpainuvimmat viisaudet. Usein Mr. Mikkelin hahmo toimii Neilille
pelastavana enkelinä, kun tämä kohtaa testaukseen liittyvän pulman, eikä tiedä,
miten edetä. Tämä onkin kirjan draaman kaari – aina luvun alussa Neil törmää
joko testauksen suunnitteluun tai toteutukseen liittyvään ongelmaan ja yrittää
ratkoa sitä, kunnes luvun lopussa Mr. Mikkel pelastaa tilanteen tarjoamalla
tälle uutta testauksen rakennuspalikkaa.
Varsinainen testaussisältö on hyvin oivallista ja rakentaa TMapin
viitoittamalle pohjalle. Kirjassa esitellään neljä testauksen rakennuspalikkaa:
Integrate (yhdistä), Industrialize (teollista), People (inhimillistä) ja Simplify (yksinkertaista). Näiden
neljän palikan päälle rakentuu Confidence,
luottamus tuotteen laatuun. Rakennuspalikat
myös nivoutuvat hyvin juonen etenemiseen ja antavat kirjalle helppolukuisen rakenteen.
Teoriaa annostellaankin sopivan pituisissa pätkissä ja tärkeimmät ideat esitetään
selkeästi ja havainnollisesti erilaisten taulukoiden ja kaavioiden avulla.
Yleisesti ottaen kirja on onnistunut kokeilu yhdistää testauksen teoriaa ja käytäntöä. Vaikka osa kaunokirjallisesta osuudesta on välillä ohutta, kirja etenee vauhdilla ja uusia rakennuspalikoita tuodaan lukijan eteen ennen kuin tämä ehtii kyllästyä. Kirja sopiikin pokkarimuodossaan helposti luettavaksi testaajan matkaevääksi, jonka pääasiat on esitetty viihteellisessä kehyksessä napakasti. Kirja tarjoaa rennon sukellusmatkan testauksen maailmaan ilman ikävää saarnaamiseen makua. Kirjaa voi surutta suositella kaikille ohjelmistotestauksesta kiinnostuneille, erityisesti, jos ei ole siitä aikaisempaa kokemusta.
Neil’s
Quest for Quality – A TMap HD Story (Alder
Boersma & Erik Vooijs, 2014). 240s. Sogeti.
Tilaa:
Blogitekstit (Atom)