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
Tilaa:
Blogitekstit (Atom)