Transcript TestauksenAutomatiso..

Testauksen automatisointi
Maaret Pyhäjärvi
<[email protected]>
Tekijä mainittava, Maaret Pyhäjärvi & Erkki Pöyhönen
http://creativecommons.org/licenses/by/1.0/fi/
Katsaus testiautomaatioon ja
testauksen tukemisen välineisiin
Päivä 1:
Testauksen automatisointi
hallittavana prosessina
Työkalun valinnasta käyttöön
Automatisoitavan testauksen kohteita
Automatisointikeskeisten testaustyyppien
erityispiirteet
Testauksen automatisointi käyttöliittymän
kautta
Päivä 2:
Testausautomaation
toteutus
Testauksen automatisointi rajapintojen
kautta
Testattavuuden arviointi, luominen ja
mittaaminen
Testausautomaation perussäännöt
Monday, 13 April 2015 Page 2
Käyttöliittymä vs. ohjelmointirajapinta vs.
yksikkötestauskehikko
Oleellisesti eri tason mekanismit järjestelmään kiinnittymiseen
• Minkä kiinnittymismekanismin kautta tämän järjestelmätyypin virheet ovat
nähtävissä?
• Osien eristäminen ja virheiden paikallistaminen pienempiin osiin on edullisempi
vaihtoehto korjauskustannuksille
Mikä sopii yhdelle ei välttämättä ole paras toiselle
• Järjestelmät ovat erilaisia
• Organisaatiot ja osaamiset ovat erilaisia
Yleisesti: mitä alemman tason testiin mennään, sitä suuremmat vaatimukset
tekniselle osaamiselle kohdistuvat
Järjestelmän arkkitehtuuriin liittyvät ratkaisut merkittävässä roolissa
• Voi olla että käyttöliittymä on ainoa liittymä kaikkeen toiminnallisuuteen
• Voi olla että keskeinen osa toiminnallisuudesta ei ole saavutettavissa käyttöliittymän
kautta
Monday, 13 April 2015 Page 3
Automatisointitasojen vertailu
Yksikkö
API
GUI
Kuka voi tehdä?
Kehittäjät
Kehittäjät/käyttäjät
Testaajat +
automaatioosaajat
Vaadittu
työkalutuki
Yksikkötestauskeh Skriptauskehikko
ikko (public
(public domain,
domain)
myös kaupallisia)
GUI testaustyökalu
(kaupallisia)
Vaadittu koulutus
Testit samalla
kielellä kuin tuote
Tarvitsee APIymmärrystä
Vaatii
työkalukoulutusta
Joustavuus
Kuka tahansa voi
ajaa
Kuka tahansa voi
ajaa
Vaaditaan
työkalulisenssi
ajamiseen
Monday, 13 April 2015 Page 4
Nauhoita/Toista -automaatio
Perusajatus:
• Uusintatestaus vaatii toistoa ja sen
automatisoinnin luulisi olevan helppoa
• Nauhoitetaan testaajan toimet
testatessa
• Toistetaan samat toimet myöhemmille
versioille
• Jos jokin eroaa, se on varmaankin
virhe
Ongelmia:
• Paljon pieniä muutoksia joita ei halua
huomioida – määriteltävä mikä
lasketaan samaksi
• Käyttöliittymämuutoksiin
valmistautuminen
• Eri konfiguraatiot ja ympäristöt
• Testattavan ohjelman tilan seuranta
• Aineiston rajoitteet uudelleenkäytölle
• Järjestelmän instrumentointi voi
vaikuttaa toimintaan
• Automaatioteknologia kehittyy
askeleen jäljessä
Monday, 13 April 2015 Page 5
Julkaistua kritiikkiä Nauhoita/Toista automaatiostrategiasta
"The maintenance costs associated with captured test cases are unacceptable." — Cem Kaner,
“Avoiding Shelfware: A Manager's View of Automated GUI Testing.” 1998.*
"This method [record/playback] is fraught with problems, and is the most costly of all methods over
the long term" — Keith Zambelich, “Totally Data-Driven Automated Testing.” 1998. http://www.sqatest.com/w_paper1.html *
"Unfortunately, every time someone makes a small change to the software, the tests break." —
David M Bennett, "Scripted Validation," STQE Magazine, July 2000.
"You can't just whip up a bunch of automated tests and expect them to repay your investment. You
have to plan your automation strategy.“— Brian Marick, "Automating Testing", STQE, Sept 1999.
http://www.stqemagazine.com/webinfo_detail.asp?id=102
"Writing scripts by hand takes less time and is less error prone than record & playback, once you
know the automated test tool." — Elisabeth Hendrickson, “The Difference between Test Automation
Failure and Success.” 1998. http://www.qualitytree.com/feature/dbtasaf.pdf
"People should not expect to install the testing tool, turn on the capture function and begin recording
tests that will be used forever and ever." — Kerry Zaller, "Practical Experience in Automated Testing"
in Methods & Tools, Spring 2000, http://www.martinig.ch/mt/DMT0100.pdf
Monday, 13 April 2015 Page 6
Julkaistua kritiikkiä Nauhoita/Toista automaatiostrategiasta
“The (recorded) scripts required a lot of maintenance when the software changed. He spent weeks
arguing with developers to stop changing the software because it broke the automated tests.
Eventually, the scripts required so much maintenance that there was little time left for testing.“—
Harry Robinson, “Intelligent Test Automation,” STQE Magazine, September 2000.
http://www.geocities.com/harry_robinson_testing/Intelligent_Test_Automation.htm
“But this method [capture/replay] only really works for the simplest of test environments.“—
Christopher Meisenzahl and Ferry Firmansjah, “Breaking the Language Barrier,” STQE Magazine,
Nov 2000.
“The automated test tool vendors claim that their tools are easy to use in capture/replay mode. They
imply that business professionals without programming skills can simply automate test cases by
having a tool observe and capture their actions, and then play back the recorded test cases. Some
people naively assume they can install a tool, and record test cases which will last indefinitely without
any maintenance. This one assumption alone is probably responsible for the majority of automated
test tool software that is gathering dust on shelves in companies around the world. I would just love
to see one of these salespeople try it themselves in a real-world scenario.”—Ross Collard, Software
Testing & Quality Assurance, February 2000 (Version 6.2) Volume 15, p. 25.
Monday, 13 April 2015 Page 7
Aineisto-ohjattu ja avainsanaohjattu
testaus
Aineisto-ohjattu testaus (data-driven)
• Hyvä testauskäytäntö kannustaa
lajittelemaan testiaineiston taulukoihin
• Kovakoodatut arvot skripteissä
vaikeuttavat katselmointia
• Lisäpalvelu jossa skriptit lukevat
aineiston tietyn muotoisesta taulukosta
• Erotetaan aineisto ja toiminta
Avainsanaohjattu testaus (keyword /
action word driven)
• Haluaisit helppolukuisia testiskriptejä
joita sovellusalueasiantuntijat voivat
luoda olematta ohjelmoijia
• Määritellään avainsanoja ja niihin
liittyviä parametrejä, toteutus
alemmalla tasolla
• Oleellisesti abstraktiokerros (tai
useampi)
• Vain alemman tason kirjastoja
muutettava käyttöliittymän muuttuessa
Monday, 13 April 2015 Page 8
Testisuorituksen tehon lisääminen
Kombinaatioiden määrän kasvattaminen
Useammin, nopeammin, pidempään
Vaihtelun lisääminen suorituksessa
Diagnostiikan parantaminen
Hyödynnä ohjelmointia
• Ehtojen asettaminen
• Monipuolinen seuranta
• Järjestelmän ja testattavan kohteen hallinta
Monday, 13 April 2015 Page 9
Automatisoidun testauksen mekanismeja
Uusintatestaus
Suorituskykytestaus (kuorma/stressi)
Malliperusteinen testaus
Suuren määrän automatisointi (high-volume test automation)
todennäköisyyksiin tai satunnaisuuteen perustuen
Monday, 13 April 2015 Page 10
Tyypillisiä automaatiolähtökohtia
Yhdenmukaisuus
• Tallennetaan tilanne ja varmistetaan että
muutosten jälkeen järjestelmä vastaa
aiempaa – ohjelma toimii oraakkelina
• Vaatii testausrajapinnan vakautta,
toistettavia tuloksia
• Vastaa tavoitteisiin: aloitustestaus,
alustatestaus, todiste uusintatestauksesta,
versiotestaus
• Vertailu: näytöt, tilat, tulokset, kannat,
resurssien käyttö
• Testaa muutamia asioita, joskus hyvinkin
Pieni, valikoitu otos
• Valitaan huolellisesti otos testejä, esim.
Pitkäkestoinen ja yksityiskohtainen
tarkastelu
• Käytössä olevan järjestelmän
varmistaminen, rajattu laitteisto
• Paljon verrattavaa
Kattava otos
• Rajattu syöteavaruus, parametrit tunnistettavissa
• Turvallisuus- tai liiketoimintakriittisille osille
Satunnainen, tilastollinen
• Kuorman ja pitkäkestoisen käytön testaus
• Voi perustua malleihin
• Etsitään monimutkaisten syötesarjojen
vaikutuksia
• Virheiden toistaminen voi olla haastavaa,
diagnostiikka kriittinen
• Heikko oraakkeli
• Kattavuuden yliarviointi
Malliperusteinen testaus
• Mallin järjestelmällinen läpikäynti, usein tilamalli
• Mallin tekeminen voi olla työlästä
• Ei siedä kovin hyvin monimutkaista ja muuttuvaa
tuotetta
Monday, 13 April 2015 Page 11
Automatisoidun testauksen
lähestymistapojen lajittelu
Testien lähde:
Vanhoja
Tarkoituksella uusia
Satunnaisesti uusia
Testien sarjallinen
riippuvuus:
Itsenäisiä
Suoritusjärjestyksellä merkitystä
Arviointistrategia:
Testijoukon koko:
Pieni
Suuri
Täysin kattava
Vertailu talletettuun tulokseen
Vertailu oraakkeliin
Vertailu laskennalliseen tai loogiseen
malliin
Vertailu heuristiseen ennusteeseen
Kaatuminen
Diagnostiikka
Tilamalli
Monday, 13 April 2015 Page 13
Käyttöliittymäautomaatio parhaimmillaan
Jo lähes toimiva ohjelmisto
Muutostarpeet käyttöliittymätasolla eivät suuria
• Käyttöliittymä ei uudistu jokaiselle tuoteversiolle
• Ei tarvetta rakentaa joustoa käyttöliittymän muokkaamiseen
Toistuva testauksen suoritus tai toistuvien aineistojen syöttö käyttöliittymän
kautta
Kyky tunnistaa virheitä tehokkaasti käyttöliittymän näyttämistä tiedoista
• Usein yhdistetään tarkistuksiin myös pinnan alta, esim. tietokanta
Visuaalisten ilmiöiden tarkastelu
Käyttöliittymien kautta automatisointi on helppoa, mutta automatisointi
ylläpidettävin rakentein vaikeaa!
Monday, 13 April 2015 Page 14
Rajapinta-automaatio parhaimmillaan
Tarve päästä varhain projekteissa testaamaan toiminnallisuutta ja
osajärjestelmiä
Toimintojen, aineiston ja yhdistelmien testaus
Toimintalogiikka on merkityksellistä ja saavutettavissa ilman graafisen
käyttöliittymän mukanaoloa
• Erinomainen rajapinta automatisoinnille on komentorivirajapinta (CLI – Command
Line Interface)
Rajapinnat ovat erilaisia:
• Näkymättömiä käyttäjälle
• Vaativat tietämystä sisäisestä toimintalogiikasta
• Vaativat ohjelmointitaitoja testaajalta
• Usein monimutkaisia ja kompleksisia
Monday, 13 April 2015 Page 15
Yksikkötestauskehikot parhaimmillaan
Testattavan koodin rakentaminen yksityiskohta kerrallaan
Saman kielen käyttö kuin toteutuksessa vähentää kielen
opiskelutarvetta
Kiinnittyminen pieniin palasiin pitää muutossietoisuuden parempana ja
vähentää ylläpitotyötä
• Käytännössä nämäkin rakenteet voivat muodostua monimutkaisiksi ja
laajoiksi ja sisältää riippuvuussuhteita toisiin osiin ja testeihin
Ideana uusissa toimintatavoissa enemmän “suunnittelu esimerkkien
kautta” kuin “testataan kaikki kattavasti
Erinomainen väline muutoshavainnointitavoitteen
uusintatestausautomaatioon
Monday, 13 April 2015 Page 16
Ylläpidettävyyttä on korostettava
Ylläpidettävyys on onnistuneen testiautomaation keskeisin
onnistumiskriteeri
• Erota aineisto skripteistä
• Suunnittele rakenteet uudelleenkäyttöä ja muutosten paikallisuutta
silmälläpitäen
• Nauhoita-toista ei ole hyvä pitkän aikavälin lähestymistapa
• Käytä koodausstandardeja luomaan yhteistä tyyliä eri tekijöiden välillä
• Testaustyökalut vaativat ohjelmointitaitoja
Monday, 13 April 2015 Page 17
Työkalu ja automatisointikehikko
Automatisointikehikko (framework)
Työkalu
Työkalu
Työkalu
testiautomaatiojärjestely
Monday, 13 April 2015 Page 18
Esimerkki automaatioarkkitehtuurista
Lähde: Doug Hoffman.


Test
Results
Testware
Test List
Tester



Automation
Engine





SUT

Data
Set

1. Testauksen materiaalien versionhallinta ja konfiguraation hallinta
2. Testien osajoukon valinta ajoon
3. Ympäristömuuttujien asetus ja tallennus
4. Testien ajaminen
5. Testien aikaisen tapahtumien monitointi
6. Oleellisten tulosten tallentaminen
7. Todellisten ja odotettujen tulosten vertailu
8. Testien lopputuleman raportointi (pass/fail)
Monday, 13 April 2015 Page 19
Automatisointikehikon vaatimuksia
Selkeä kiinnittymiskohta testattavaan järjestelmään
Muutettavuus: ei vain ylläpidettävä, vaan rakennettu muuttumaan
Laajennettavuus
Yksinkertaisuus
Luotettavuus
Osien korvaaminen toisilla, riippumattomuus ”yhdestä toimittajasta”.
Toteutustapa:
• Inkrementaalisesti, toteutuserä kerrallaan pienin askelin
• Ei välttämättä isoa tukirakennetta, vaan tarpeeseen suunnaten
Monday, 13 April 2015 Page 20
Virhetilanteista toipuminen
Tukirakenne joka nollaa tilanteen testin epäonnistuessa.
• Ilman toipumisjärjestelyä, testijaksot ovat alttiita seurannaisvirheille dominovaikutus
Toipumistukirakenne voi
• Sulkea ylimääräiset sovellusikkunat
• Sammuttaa ja käynnistää tuotteen uudelleen
• Käynnistää uudelleen laitteiston
• Nollata testaustiedostot
• Alustaa uudelleen tietokannan
• Kirjata virhetilanteen
 Palauttaa perustilan
Monday, 13 April 2015 Page 21
Testiautomaation lokipalvelu
Lähde: Pekka Laukkanen, Qentinel
Ei läpi (fail)
• Ei läpäistyn testin kirjaaminen suorituslokiin
Läpi (pass)
• Läpäistyn testin kirjaaminen suorituslokiin
Mahdollisuus suodattaa
kiinnostava tieto eri tarpeisiin
luodaan perusrakenteita
miettiessä.
Vakava (fatal)
• Testien ajoa kokonaisuutena ei voida jatkaa, esim. ympäristövirheen vuoksi
Virhe (error)
• Testissä oleva odotettu tulos ei vastaa todellista tulosta
• Yksittäistä testiä ei voida suorittaa loppuun
Varoitus (warning)
• Virhe ei luultavasti vaikuta testien suoritukseen, mutta on hyvä tiedostaa, esim. väliaikaistiedostoa ei voitu
poistaa
Tiedoksi (info)
• Normaalin etenemisen kirjaaminen muistiin
Virheen paikallistaminen (debug)
• Yksityiskohtia testauskehikon toiminnasta korjaustarkoituksiin.
Jäljitys (trace)
• Paikallistamista yksityiskohtaisempi tietotaso.
Monday, 13 April 2015 Page 22
Testien tilan asettamisen logiikka
Testin
suoritus
Tarkistukset
Odotus:
ei läpi
Odotus:
ei läpi
Ei läpi
(odotettu)
Läpi
(normaali)
Läpi
(virhe korjattu)
Ei läpi (uusi)
Ei läpi (tunnettu)
Monday, 13 April 2015 Page 23
Automatisointikielen valinta
Järjestelmien ohjelmointikielet
• Yleensä optimoitu suorituskyvyn ja skaalattavuuden, ei nopean ohjelmoinnin
tarpeisiin
• Jo hallussa niillä jotka toteuttavat muutenkin ohjelmistoa
Skriptauskielet
• Olemassa olevien palasten yhdistelyyn, nopean ohjelmoinnin tarpeisiin
• Yleiskäyttöisiä, osaajia saatavilla, nopeahko omaksua ohjelmointitaitoiselle
• Testiautomaation suorituskyky ei useinkaan ongelma, koska ajasta leijonanosa
kuluu odottaen järjestelmävasteita
Toimittajien omat skriptauskielet (vendor-script)
• Osaajat automaatiotyökalun osaajia, osaaminen erikoistunutta
• Ohjelmointiominaisuuksissa voi olla toivomisen varaa
• Yhteensopivuus muiden työkalujen ja kielten kanssa vaihtelee
Monday, 13 April 2015 Page 24
Onko leikkaa-liimaa pahasta?
Yleissääntö
• Vältä leikkaa-liimaa –tekemistä
• Toistettu koodi ei ole hyvä ylläpidon kannalta
• Sen sijaan luo funktioita
Testauksessa on poikkeuksia
• Testit sisältävät luonnostaan paljon toistoa
• Testit on helpompi katselmoida jos ne eivät sisällä liikaa ehtolauseita ja
funktiokutsuja
• Testit ovat vähemmän luotettavia jos ne ovat monimutkaisempia
Näin ollen, testiautomaatiossa saman toisto on sallittua jos se tekee
testeistä helpommin muutettavia – vaikea tasapaino.
Monday, 13 April 2015 Page 25
Erota käsitteet
Testijakso
Testiaineisto
Testitapaus
Testiympäristö
Testikierros
Monday, 13 April 2015 Page 26
Vaatiiko automatisointi vaatii tarkat tiedot
testitapauksista?
Vai vaatiiko?
• Kokemukset ovat osoittaneet että suunnitellut testitapaukset kelpaavat
harvoin suoraan automatisointiin, erilainen jäsennys
Automatisoidessa tulee tallennettua tarkat tiedot
• Tietokoneen ”tyhmyys” – omat huomiot ja sisäänrakennetut huomiot
Huomioi oraakkelin moniulotteisuus
• ”kirjoittaa ruudulle käyttäjän nimen”
• ”tekee sen alle 10 sekunnissa”
• ...
Monday, 13 April 2015 Page 27
Testioraakkeli
Sanalla kaksi toisistaan hieman eroavaa merkitystä
• Vertailufunktio: Kysytään mikä oikea arvo on.
• Vertailu- ja arviointifunktio: Kysytään onko ohjelma läpäissyt testin.
Käytettäessä oraakkelia, ohjelman tulosta verrataan vertailuarvoon
(ennustettu) ja päätetään sen perusteella onko ohjelma läpäissyt
testin.
• Deterministinen oraakkeli: ero tarkoittaa virhettä
• Todennäköisyysperusteinen oraakkeli: ero tarkoittaa mahdollista virhettä
Monday, 13 April 2015 Page 28
Testattava kohde ja testioraakkeli
Lähde: Mukaillen Doug Hoffman
Syöte
Testattava
järjestelmä
Tulos
Odotettu
tulos
Aineisto
ennen
Aineisto
jälkeen
Ohjelman
tila ennen
Ohjelman
tila jälkeen
Ympäristösyötteet
Testioraakkeli
Ympäristötulos
Monday, 13 April 2015 Page 29
Testitapausten määrän mittaaminen
aika
Monday, 13 April 2015 Page 30
Harjoitus: käyttöliittymä- ja rajapintaautomaation keskeiset kysymykset
Jakaannutaan kahteen ryhmään:
• Käyttöliittymäautomaatio
• Rajapinta-automaatio
Työstetään yhteinen näkemys keskeisistä kysymyksistä ja niiden
vastauksista:
• Työkalu ja tukirakenteet – mitä tarvitaan?
• Prosessi ja käytännöt – vaatimukset automatisoinnin näkökulmasta
• Automatisoinnin osaaminen ja automatisoinnin organisointi
• Automaation hyötyjen arviointi
Monday, 13 April 2015 Page 31
FiWST-1 Onnistunut testausautomaatio
Työpajan (13.12.2004) yhteenveto,
osallistujina:
Ryhmänä meillä oli kokemuksia:
• Käyttöliittymäautomaatiosta Mercuryn, Seguen ja
Compuwaren välineillä
Maaret Pyhäjärvi (testausOSY:n vetäjä), Erkki
Pöyhönen (Nokia), Tuija Ojalammi (Conformiq
Software), Tomi Kaleva (Tietokarhu), Risto
Kumpulainen (F-Secure), Tuula Pääkkönen
(Nokia), Pekka Laukkanen (Qentinel), Juha
Saaristo (Nice Business Solutions), Marko
Komssi (F-Secure), Mika Katara (Tampereen
teknillinen yliopisto), Petri Kuikka (F-Secure),
Paavo Häkkinen (Compuware), Jouni Hynynen
(SoftaTest)
• Rajapinta-automaatiosta skriptikielillä (Perl, Python,
C)
Työpajan tavoitteena oli:
• Toiminnallisen testauksen ja suorituskykytestauksen
automatisoinnista
• Keskustella onnistumiskokemuksista
testausautomaatiovälineiden valinnassa,
käyttöönotossa ja käytössä
• Vetää yhteen osallistujien tuntemia hyviä
käytäntöjä.
• Oppia testausautomaatiosta pintaa syvemmältä
peilaten omia kokemuksia toisten kokemuksiin
• Yksikkötestauksesta Junitilla
• Mallipohjaisesta testauksesta ja testien
automaattisesta generoinnista Tampereen
teknillisen yliopiston tilakoneperusteisella
välineprototyypillä sekä Conformiqin vastaavalla
kaupallisella välineellä
• Aineisto-ohjatusta ja avainsanaohjatusta
testiautomaatiosta
• Automatisoinnista Windows- ja Unix-maailmassa
sekä laitteistoläheisissä ympäristöissä
• Kaikkien tarpeellisiksi tunnistettujen testien
automatisoinnista ohjelmointirajapintaa vastaan
• Onnistumisesta ja epäonnistumisesta - ja siitä että
joskus tuntuu että automatisointi on pettymystä
toisen jälkeen.
• Toimisesta välineitä myyvän sekä käyttävän
organisaation puolella
Monday, 13 April 2015 Page 32
Katsaus testiautomaatioon ja
testauksen tukemisen välineisiin
Päivä 1:
Testauksen automatisointi
hallittavana prosessina
Työkalun valinnasta käyttöön
Automatisoitavan testauksen kohteita
Automatisointikeskeisten testaustyyppien
erityispiirteet
Testauksen automatisointi käyttöliittymän
kautta
Päivä 2:
Testausautomaation
toteutus
Testauksen automatisointi rajapintojen
kautta
Testattavuuden arviointi, luominen ja
mittaaminen
Testausautomaation perussäännöt
Monday, 13 April 2015 Page 33
Testauksen automatisointi käyttöliittymän
kautta
Työkalu ja tukirakenteet – mitä tarvitaan?
Prosessi ja käytännöt – vaatimukset käyttöliittymäautomatisoinnin
näkökulmasta
Käyttöliittymäautomatisoinnin osaaminen ja automatisoinnin
organisointi
Käyttöliittymäautomaation hyötyjen arviointi
Case: käyttöliittymäautomaation oppeja
Monday, 13 April 2015 Page 34
Työkalu ja tukirakenteet – mitä tarvitaan?
Käyttöliittymäautomaation osalta yleisesti käytetään jotakin valmista
työkalua
Älä kuitenkaan odota että työkalu tarjoaisi kaikki tarvitsemasi
rakenteet valmiina
• Suunnittele ylläpidettävyyttä varten
• Aineistoperusteinen ja avainsanaperusteinen automaatiotapa keskeisiä
käsitteitä
Edelleen kyseessä on oleellisesti ohjelmistokehitysprojekti
vaatimuksista toteutukseen ja testaukseen
• Pilkottava pieniin palasiin ilman ylläpidettävyydestä luopumista
Monday, 13 April 2015 Page 35
Prosessi ja käytännöt – vaatimukset
käyttöliittymäautomatisoinnin näkökulmasta
Erillisten testaajien odotus on että GUI-automaatiossa
automatisoidaan samoja testitapauksia kuin nykyisin käsin
• Usein aktiivisesti haetaan 1:1 käsin vs. automatisoidusti, uudenlaisen
rakenteen mieltäminen haastavaa
Automaation osalta uudelleenkäyttö- ja tehostumisvaatimus kuitenkin
kannustavat kattamaan enemmän kuin testin kerrallaan
Monday, 13 April 2015 Page 36
Käyttöliittymäautomatisoinnin osaaminen
ja automatisoinnin organisointi
Myyntiargumentti: GUI-automaatio vaatii vähemmän
ohjelmointiosaamista, voi käyttää nauhoita-toista –toiminnallisuutta
Todellisuus: onnistuneet ylläpidettävät rakenteet vaativat
ohjelmointitaitoja ja nauhoita-toista on vain tapa oppia uutta
ohjelmointikieltä
Uudelleenkäytön rakenteet vaativat tukea organisoitumiselta ja eri
osapuolilla on erilaiset kiinnostuksen kohteet
• Testaajan (käyttäjän) näkökulma oleellisesti erilainen kuin automatisoijan
(toteuttajan)
Monday, 13 April 2015 Page 37
Käyttöliittymäautomaation hyötyjen
arviointi
Raportit ympäri maailman kyseenalaistavat vahvasti tyypillisten GUIautomaatiohankkeiden hyödyt
• Käyttöliittymiä ei haluta etenkään tietyissä sovellusalueissa kiinnittää
aikaisin
• Muutosten sietokyky on ollut rajallinen ja jättänyt paljon toivomisen varaa
• Teknologioissa toimittajat pysyvät perässä (aina hiukan jälkijättöisesti)
tarjotakseen tavan kiinnittyä uusiin teknologioihin
Oma kokemukseni: 80/20 ei-onnistuneita / onnistuneita
• Riippuu myös onnistumisen kriteeristä: jos onnistumiseen riittää
tyytyväisemmät testaajat, suhde on parempi onnistumisen kannalta.
Monday, 13 April 2015 Page 38
Case: käyttöliittymäautomaation oppeja
Case 1: Konsultointiavusteinen
lähtötilanne
Case 2: Omin voimin liikkeelle
• Testikirjastojen luominen
• Perusrakenteet kuntoon ulkoistetulla
osaamisella
• “Koko putken” automatisointi
asennuksesta arviointiin
• Haasteena tiedonsiirto ja jatkokehitys
• Osansa haasteita ratkottavana:
• Käytännössä kaksi
konsultointikierrosta ennen riittävää
omaa panostusta
• Muutossietoisuus
• Uudelleenkäyttökyky
• Epäluotettava verkko
Monday, 13 April 2015 Page 39
Katsaus testiautomaatioon ja
testauksen tukemisen välineisiin
Päivä 1:
Testauksen automatisointi
hallittavana prosessina
Työkalun valinnasta käyttöön
Automatisoitavan testauksen kohteita
Automatisointikeskeisten testaustyyppien
erityispiirteet
Testauksen automatisointi käyttöliittymän
kautta
Päivä 2:
Testausautomaation
toteutus
Testauksen automatisointi rajapintojen
kautta
Testattavuuden arviointi, luominen ja
mittaaminen
Testausautomaation perussäännöt
Monday, 13 April 2015 Page 40
Testauksen automatisointi rajapintojen
kautta
Työkalu ja tukirakenteet – mitä tarvitaan?
Prosessi ja käytännöt – vaatimukset rajapintaautomatisoinnin näkökulmasta
Rajapinta-automatisoinnin osaaminen ja automatisoinnin
organisointi
Rajapinta-automaation hyötyjen arviointi
Case: rajapinta-automaation oppeja
Monday, 13 April 2015 Page 41
Työkalu ja tukirakenteet – mitä tarvitaan?
Enemmistön valinta selkeästi sisäisesti kehitetyt ratkaisut
• Yleiskäyttöisissä ratkaisuissa tarvitaan välikappale, adapteri
Erilaiset skriptauskielet tuntuvat lisäävän suosiotaan
Monelta osin rakenteet vastaavat käyttöliittymäautomaatiota
• Keskeinen kysymys uudelleenkäyttö ja yhdistelmät
Monday, 13 April 2015 Page 42
Prosessi ja käytännöt – vaatimukset
rajapinta-automatisoinnin näkökulmasta
Tuntuisi etenevän mukavasti
kehitysaikaisena testaustapana
Vaatii kehittäjien ja testaajien
yhteistyötä
Testien suunnittelu on oleellisesti
sarjojen tunnistusta testitavoitteisiin
sitoutuen
• Parametrien tunnistaminen ja
eristäminen
• Mekanismit arvioida saatuja
paluuarvoja
Testaajan valinnan keskeiset
kysymykset:
• Parametrien valinta
• Kiinnostavien arvojen valinta
• Raja-arvot
• Parametrien yhdistelmät
• Tallennetun aineiston ja laskennan
laukaiseminen
• Yksin sallitut arvot voivat olla
kiellettyjä yhdistelminä
• Kutsujärjestyksen merkitys
• Kaikkien yhdistelmien läpikäynti
lähes mahdotonta
Monday, 13 April 2015 Page 43
Rajapinta-automatisoinnin osaaminen ja
automatisoinnin organisointi
Monet onnistumisista tällä puolella pienen mittakaavan projekteja, 1-2
automatisoijaa, oma peruskehikko
Selkeästi ohjelmointitehtäviä, kuitenkin testausongelmien ratkaisussa
Yleisiä haasteita:
• Sovellusaluetiedon puute johtaa vääriin painotuksiin suhteessa riskeihin
• Dokumentoinnissa lähtökohtana on useinkin toivomisen vapaa
• Lähdekoodiin ei välttämättä pääsyä
• Aikarajoitteet, vaatii pienissä paloissa hyödyllisyyttä
Monday, 13 April 2015 Page 44
Rajapinta-automaation hyötyjen arviointi
Metsän näkeminen puilta tuntuu haasteelta: mitä testataan ja miksi
hämärtyy teknisten yksityiskohtien tieltä
• Paluu perusteisiin: Riskialttiit API-kutsut, parametrit, arvot, ei vain mitä
määrittelyssä
Hyötysuhde teknisen testauksen automaatiossa verrattuna käsin
tehtävään voi olla jopa parempi
• Yksityiskohtien kärsivällisessä tarkistelussa automaatio ihmistä parempaa
Monday, 13 April 2015 Page 45
Case: Rajapinta-automaation oppeja
Case 1: Kehityksenaikainen testaus
lähtökohtana
Case 2: Ulkoisesti määriteltävä
protokolla lähtökohtana
• Ajoissa mukaan, palautteen
nopeudella säästettiin paljon työtä
• Määrittelyn laadun parantaminen
testauksen tekemisen mahdollistajana
• Käyttöliittymän puute toi luonnollisen
reitin automatisointiin
• Tietyn muotoisen määrittelyn
perusteella automatisointi
suoraviivaista
Monday, 13 April 2015 Page 46
Harjoitus: Kohteiden valinta ja priorisointi
Valitse itseäsi lähellä olevien testattavien järjestelmien osalta kolme
mahdollista automatisointikohdetta:
• Olisiko GUI-automaatio mahdollinen?
• Olisi API-automaatio mahdollinen?
Miten valitset näistä kolmesta vaihtoehdosta yhden?
Kuinka paljon työtä olettaisit tarvitsevasi valitsemasi kohteen kanssa?
Monday, 13 April 2015 Page 47
Katsaus testiautomaatioon ja
testauksen tukemisen välineisiin
Päivä 1:
Testauksen automatisointi
hallittavana prosessina
Työkalun valinnasta käyttöön
Automatisoitavan testauksen kohteita
Automatisointikeskeisten testaustyyppien
erityispiirteet
Testauksen automatisointi käyttöliittymän
kautta
Päivä 2:
Testausautomaation
toteutus
Testauksen automatisointi rajapintojen
kautta
Testattavuuden arviointi, luominen ja
mittaaminen
Testausautomaation perussäännöt
Monday, 13 April 2015 Page 48
Testattavuuden arviointi, luominen ja
mittaaminen
Testattavuuden vaikutukset automatisointiin
Testattavuuden luomisen periaatteet ja käytännöt
Testattavuuden seuranta ja mittaaminen
Monday, 13 April 2015 Page 49
Testattavuuden määritelmä
Testattavuudella tarkoitetaan
• kykyä suorittaa kustannustehokasta testausta (Gelperin)
• ominaisuuksia jotka vaikuttavat muutetun ohjelmiston varmistamisen
työmäärään (ISO9126)
• mahdollisuuksia, jotka muut osapuolet antavat testaaville osapuolille
Testattavuus voi kohdistua:
• testattavaan järjestelmään
• testauksen pohjana oleviin vaatimuksiin, määrittelyihin ja dokumentaatioon
Monday, 13 April 2015 Page 50
Järjestelmän testattavuus tyypillisessä
organisaatiossa
Liiketoimintasuunnittelija
Ohjelmistosuunnittelija
Testisuunnittelija
Ohjelmistokehittäjä
Testien kehittäjä
Testattava
järjestelmä
Testausjärjestelmä
Monday, 13 April 2015 Page 51
Tavoiteltava järjestelmän testattavuus
Liiketoimintasuunnittelija
Ohjelmistosuunnittelija
Testisuunnittelija
Ohjelmistokehittäjä
Testien kehittäjä
Testattava
järjestelmä
Testausjärjestelmä
Monday, 13 April 2015 Page 52
Harjoitus: Testattavuuden keskeiset
haasteet
Keskustellaan 2-3 hengen ryhmissä:
• Millaisia testattavuuteen liittyviä ongelmia olet kohdannut?
• Miten näitä ongelmakohtia voisi korjata?
Monday, 13 April 2015 Page 53
Seurauksia heikosta järjestelmän
testattavuudesta
Virheiden paikallistaminen vie paljon aikaa
Joidenkin asioiden testaaminen ei ole mahdollista
Ei ymmärretä että on tarve testata jotain todellisen käytön kannalta
oleellista
Testauksen määrämuotoistaminen haastavaa – ensimmäinen kerta,
ylläpito ja uusintatestaus vaativat paljon
Epädeterministisyys, ei voida tietää kaikkia tapahtumaan liittyviä
tekijöitä ja toistaa virheitä.
Monday, 13 April 2015 Page 54
Järjestelmän testattavuuden keskeisimmät
tekijät
Hallinta
• Helppo testata
• Liittymä, jota kautta käyttö mahdollista
• Kyky käyttää järjestelmän osia hallitusti (syötteet, tapahtumien käynnistys,
metodikutsut, GUI-elementtien käyttö, rajapinnat, erityinen testausliittymä)
• Kyky tuottaa syötteitä ja saavuttaa ohjelmiston tiloja
Näkyvyys
• Helppo tulkita tuloksia
• Kyky seurata testattavan ohjelmiston tiloja ja syötteistä seuraavia tuloksia.
• Virhetilanteen syiden jäljittäminen helppoa, tapahtumien suhteet selvät
• Lasilaatikko, jonka sisälle nähdään (tulokset, tilat, ominaisuudet, järjestelmän
vuorovaikutus, resurssien käyttö, virheet)
Monday, 13 April 2015 Page 55
Mistä testattavuudessa on kyse?
Tuotteen/järjestelmän testauksen
helppoudesta
Tasosta jolla ohjelmistoa voidaan käyttää,
hallita ja seurata
Tuotteen kyvystä olla testattu ja
testijaksojen kyvystä testata
Toiminnallisten osien erottelusta – järkevä
arkkitehtuuri
Näkyvyydestä tarkastuspisteiden (hooks)
ja liittymien kautta
Pääsystä syötteisiin, välituloksiin ja
lopputuloksiin
Esimerkkejä:
• Näkyvyys funktioiden ja kokonaisuuksien
suorituksen historiaan
• Näkyvyys ajossa olevien funktioiden tilaan
• Mahdollisuus kiinnittää debuggeri funktioon
• Komentoriviohjelmat kaikille tuotteen
ominaisuuksille
• Useita kohtia välitulosten tarkasteluun
• Menetelmien lisääminen luokkiin joilla
nähdään niiden tila
• Lokit, etenkin virheiden osalta
• Paketointi (wrappers), joiden avulla
automatisoija voi havaita ja muokata viestejä
molempiin suuntiin.
Syötteiden ja tulosten muodosta
Oraakkelien saatavuudesta
Monday, 13 April 2015 Page 56
Minimoi riippuvuussuhteet
Tarvittava syöte
yhdestä paikasta –
mielellään osasta,
jota testataan
Monday, 13 April 2015 Page 57
Järjestelmän testattavuuden muita tekijöitä
Vakaus
• Muutosten laajuus ja muutostapahtumien tiheys
• Vaikuttaa testien ylläpitotarpeeseen
Yhdenmukaisuus
• Samanlaiset osat käyttäytyvät samalla tavalla
• Mahdollistaa testien uudelleenkäytön eri osissa
Luotettavuus
• Järjestelmä tekee mitä oli tarkoituskin
• Testien toistaminen samoissa tilanteissa tuottaa samat tulokset, eli saman tilanteet
voidaan saada aikaan
Dokumentaatio
• Tieto siitä kuinka järjestelmän piti toimia
Monday, 13 April 2015 Page 58
Testattavuuden seuranta ja mittaaminen
Testattavuus vaikea saada näkyväksi ja mitattavaksi
• Yrityksiä hakea mittaria koodin monimutkaisuuden ja rakenteiden osalta
• Toimivan suuntaa antavina, eivät ehdottomina sääntöinä
Keskeinen oppi säännöllisen palautekanavan luomisen tarve
arkkitehtien suuntaan
• Konkreettiset esimerkit siitä miten jonkin asian testaaminen on vaatinut
enemmän aikaa
• Muutoksia ja tarpeita saa mukaan paremmin projektin alkuvaiheissa
Monday, 13 April 2015 Page 59
Katsaus testiautomaatioon ja
testauksen tukemisen välineisiin
Päivä 1:
Testauksen automatisointi
hallittavana prosessina
Työkalun valinnasta käyttöön
Automatisoitavan testauksen kohteita
Automatisointikeskeisten testaustyyppien
erityispiirteet
Testauksen automatisointi käyttöliittymän
kautta
Päivä 2:
Testausautomaation
toteutus
Testauksen automatisointi rajapintojen
kautta
Testattavuuden arviointi, luominen ja
mittaaminen
Testausautomaation perussäännöt
Monday, 13 April 2015 Page 60
Onnistunut automatisointi on merkittävä
hanke
Testiautomaatioprojekteihin pätee samat säännöt kuin
ohjelmistokehitykseen yleensäkin
• Ymmärrä ja määrittele vaatimukset
• Hallinnoi lähdekoodia, testiaineistoa ja työkaluja
• Suunnittele ennen kuin ryntäät tekemään
• Katselmoi koodi
• Seuraa automaation virheitä virhekirjauskannan avulla
• Dokumentoi testiasetelma muille käyttähille
• Luo projektihallintarakenne säännöllisin virstanpyväinen tukemaan
viestintää ja osoittamaan etenemää
Monday, 13 April 2015 Page 61
Pidä automaatio yksinkertaisena
Testiautomaatiolla on tapana tehdä testauksesta monimutkaista
• Vältä monimutkaisia rakenteita
• Kaikkea mitä voi tehdä ei tarvitse tehdä
Testijakso itsessään pitää myös testata
• Ohjelmistokehityshanke
Varmista että testijakso vastaa alkuperäisiä tavoitteita
• Tietäväthän kaikki alkuperäiset tavoitteet – luottamus automaatioon?
Rakenna joustavasti
• Toimita pala kerrallaan
• Todista ja näytä hyödyt aikaisessa vaiheessa, ei pitkää pohjatyötä ilman tulosta
• Paketoi ja pidä huolta helposta käyttöönotosta
• Dokumentoi riippuvuudet
Monday, 13 April 2015 Page 62
Taustaa kustannuslaskentaan
Merkittävä osa automaation hyödyistä tulee analyysin ja suunnittelun
kurinalaisuudesta
Automaation takaisinmaksu on usein seuraavan projektin asia
Automatisointi usein aiheuttaa merkittävän negatiivisen aikataulu- ja
suoritusvaikutuksen aloitusvaiheessa
Automatisoidut testit ovat vaikeampia suunnitella ja laatua, ja
vaativat enemmän ohjelmointi- ja suunnitteluosaamista testaajilta
Automatisoitut testit vaativat ylläpitoa usein
Mittarit eivät ole puolueettomia tilastoja
Monday, 13 April 2015 Page 63
Automatisoidun testauksen hyöty suoralla
vertailulla?
Käsin
tehtävän
testauksen
kustannus
Automatisoidun
testauksen
kustannus
=
Käsin nyt
=
Työkalulla
nyt
+
Käsin ensi
vuonna
+
Työkalulla
ensi
vuonna
*
Testikierrokset
*
Testikierrokset
Monday, 13 April 2015 Page 64
Säästöpotentiaalin arvioiminen
projekteittain
•
Yksinkertainen työmäärälaskelma: kolme osaa
• Testikierrosten määrä
• Tarvittavien testaajien määrä
• Testikierroksen kesto
Tekijä
Nykyinen toimintatapa
Uusi toimintatapa
Vaikuttimet
Testikierrosten määrä
4-6 (12)
3
Selkeä prosessi ja
aloitus/lopetuskriteerit
Testaajien määrä
1-5 (8)
2
Testaajien osaaminen
Testikierroksen kesto
2-5 (30)
3
Testiautomaation käyttö
*Tunnistetut maksimit
Liian yksinkertaistettu, mutta toimii perusteena
automaatioprojektien aloitukselle vielä monissa organisaatioissa
Monday, 13 April 2015 Page 65
Automaation sijoituksen tuotto -laskelma
Kustannustekijä
Käsin tehtävä testaus
Automatisoitu testaus
Testitapausten suunnittelu
6 000 €
6 000 €
Työkalu
5 000 €
Testien automatisointi
11 000 €
Automatisoinnin kokonaiskustannus
16 000 €
Testien suorittaminen (täysi testikierros)
5 000 €
1 000 €
Testikierroksia per julkaisu
3
3
Testauskustannus per julkaisu
21 000 €
9 000 €
12 000 €
Säästö per julkaisu
Julkaisuja vuodessa
4
4
Hyöty vuodessa
48 000 €
Säästö vuodessa (hyöty – investointi)
32 000 €
Sijoituksen tuotto (säästöt/investointi)
200 %
Monday, 13 April 2015 Page 66
Liian yksinkertaistettu tapa laskea
Perustuu oletuksiin:
• Ylläpitokustannukset eivät ole merkittäviä
• Tulokset käsin tehdystä testauksesta on suoraan verrattavissa
automatisoituun
• Koska samaa testiä ei ajaisi niin usein käsin (pakko järkeistää), ei jokainen
suorituskerta ole yleensäkään tarpeen
• Testin arvo muuttuu myöhemmille kierroksille – vai onko N:s ajokerta yhtä
arvokas kuin toinen?
Monday, 13 April 2015 Page 67
Realismia talouslaskelmiin
Testauksen nykykustannus
• Muuttuu elinkaaressa – uusintatestauspainotus kasvava
• Kehitysaikainen testaus vs. erilliset testaajat
Laadun ja aikataulupidon arvo
• Näkyvyys etenemiseen
• Korjaustyöt
Automatisoinnin erityispiirteet
• Testien totuudenmukaisuus
• Todellinen löytymispotentiaali
• Laajentava uusintatestaus: ympäristöt, lokalisointi
• Kombinaatiot ja yhtäaikaisuus
• Suorituskyky
Monday, 13 April 2015 Page 68
Kustannuslaskelmilla on kaksi puolta
Kirjanpitokustannus
”paljonko rahaa asiaan
kiinnitetään”
Vaihtoehtoiskustannus
”mitä jää saamatta kun
raha kiinnitetään
niinkuin kiinnitetään”
Mieti mitä virheitä et löydä sinä aikana,
jonka käytät automaation työstämiseen?
Monday, 13 April 2015 Page 69
Mitattavia vaikutuksia
Testauksen läpimenoaika
Testauksen työmäärä
Automaation työmäärä
• Toteutusinvestointi
• Laajennusinvestointi
• Ylläpitokustannus
Ohjelmistokehityksen mittareilla voi
välittää haluamansa viestin, usein
vahingossakin. Lukujen kerääminen
vaatii merkittävää huomiota. Aina
mittarit eivät ole paras tapa ilmaista
etenemistä.
Virheiden määrät
Virheiden löytymisprofiili
Monday, 13 April 2015 Page 70
Vaikeasti mitattavia vaikutuksia
Automaatiolla voi olla positiivinen tai negatiivinen vaikutus:
• Testausorganisaation ammattimaisuus
• Testausorganisaation ulkopuolelta koettu tuottavuus
• Laajentuminen edistyneisiin testausasioihin
• Testien laatu
• Halukkuus kokeilla ja saada aikaan muutoksia osalla testausryhmää
• Luottamus testaajien ja johdon välillä
• Yrityksen kyky saada versioita nopeasti läpi testauksesta
• Testauskattavuus
• Testausryhmän kyky käyttää vapautunut aikansa tutkivaan testaukseen
Vaikeita arvioida realistisesti. Arvotus vaihtelee
organisaatioissa.
Monday, 13 April 2015 Page 71
Automatisointityön organisointi ja
resursointi
Vertaa
• Automatisointi eristyksissä, “in a silo”, erillisen henkilön tai ryhmän toimesta
• Automatisointi jokaisen testaajan tehtävänä
Erilaiset rakenteet toimivat eri ryhmissä
• Perusrakenteiden luominen ja ylläpitäminen vaatii erikoisosaamista automaatiosta
• Automaation pitää kuitenkin yhdistyä muihin testaustehtäviin.
Kaksi vaihtoehtoista tapaa sovittaa testiautomaatioarkkitehtuuri ja resursointi
yhteen:
• Valitse ensin arkkitehtuuri ja hanki tarvitsemasi osaaminen
• Valitse arkkitehtuuri vastaamaan nykyistä osaamisprofiilia
Monday, 13 April 2015 Page 72
Projektin rajaus
Laajuus
Monipuolisuus
Monday, 13 April 2015 Page 73
Joitakin oppeja (1/2)
Työkaluvalinnoissa tarvitaan suhteellisuudentajua
• Työkalujen lisenssihinnat ovat lopulta pieniä suhteessa palkkakustannuksiin
Ota huomioon niin lyhyen kuin pidemmän aikavälin tavoitteet sekä suhteet
toimittajiin
Älä perusta suunnitelmia liiassa määrin lupauksille, “promiseware” saattaa
kuulostaa paremmalta kuin on
Huolehti riittävästi eri osapuolten mukanaolosta automaatiohankkeessa ja
mahdollisimman varhain välttääksesi turhia yllätyksiä
Kun valitset työkalua, kokeile sitä aina omassa ympäristössäsi – ei yleissääntöä
toimivuudesta
Kun haluat luoda uudelleenkäytettäviä rakenteita, käytä tähän osaavia ihmisiä
Vaatimusmäärittelyn teko automaatiotyökalulle ei eroa muista
vaatimusmääritelyistä: muista niin toiminnalliset kuin ei-toiminnalliset vaatimukset
Monday, 13 April 2015 Page 74
Joitakin oppeja (2/2)
Pysy kohtuudessa – älä koita automatisoida kaikkea
Automatisoinnissa parhaat rakenteet eivät synny automatisoimalla
testitapaus testitapaukselta
• Peilaa siihen mitä olemme oppineet ohjelmistokehityksestä yleensä
Automaation osalta on voitava suuremmassa määrin luottaa
odotettujen lopputulosten oikeellisuuteen
Automatisointi on täysipäiväistä (ainakin lähes) hommaa eikä toimi
pöytälaatikkoprojektina
Ihmisiin liittyviä kysymyksiä ei voi aliarvioida automaatiota
kehittäessään ja hyödyntäessään
Monday, 13 April 2015 Page 75
Katsaus testiautomaatioon ja
testauksen tukemisen välineisiin
Päivä 1:
Testauksen automatisointi
hallittavana prosessina
Työkalun valinnasta käyttöön
Automatisoitavan testauksen kohteita
Automatisointikeskeisten testaustyyppien
erityispiirteet
Testauksen automatisointi käyttöliittymän
kautta
Päivä 2:
Testausautomaation
toteutus
Testauksen automatisointi rajapintojen
kautta
Testattavuuden arviointi, luominen ja
mittaaminen
Testausautomaation perussäännöt
Monday, 13 April 2015 Page 76
Koulutuksen yhteenveto
Mitä jäi mieleen?
Mihin kysymyksiin kaipaa edelleen vastausta?
Monday, 13 April 2015 Page 77
Odotukset ensimmäiseltä päivältä
Mitä kannattaa automatisoida?
Miten myydä – mitä oikeasti tehdään?
Perustelut asiakkaalle: miksi, missä määrin
Miten välttää samojen asioiden testaus käsin
Mittarit
Varmuus muutosten huomaamiseen
Työkaluvalinta
Millaista sovellusta järkevä automatisoida
Monday, 13 April 2015 Page 78
Lisätietoja automaatiosta
Näiden ihmisten osalta olen lukenut hyviä automatisointiartikkeleita, kirjoja ja –neuvoja:
• James Bach
• Hans Buwalda
• Danny Faught
• Mark Fewster
• Elizabeth Hendricks
• Cem Kaner
• Brian Marick
• Bret Pettichord
• Harry Robinson
Monday, 13 April 2015 Page 79
Hyviä testaustiedon lähteitä verkossa
Stickyminds – Forum for testing
• http://www.stickyminds.com/
”Better Software”-lehti, ilmestyi ennen nimellä
”Software Testing and Quality Engineering”
• http://www.bettersoftware.com/
Cem Kaner’s website
• http://www.kaner.com/
James Bach’s website
• http://www.satisfice.com/
Rex Black’s website
• http://www.rexblackconsulting.com/
Karl Wiegers website
• http://www.processimpact.com/
Tulevaisuudessa suomenkielistä materiaalia
Software Testing Hotlist
• http://www.io.com/~wazmo/qa/#test_tools
Brian Marick’s Website
• http://www.testing.com/
Bret Pettichord’s Website
• http://www.pettichord.com/
TestingEducation Promotion site
• http://www.testingeducation.org/
Suomalainen testausosaamisyhteisö
• http://www.pcuf.fi/sytyke/kerhot/testaus/
Suomalainen testaajien keskusteluryhmä
• http://groups.yahoo.com/groups/fi-testaus/
SoftaTest Moodle
• http://softatest.moodle.fi/
• http://www.testauskirja.com
Testauksen sertifiointia
• http://www.bcs.org.uk/iseb/
• http://www.istqb.org/
Kurssin materiaalit:
• http://www.testauskirja.com/automaatio.zip
Monday, 13 April 2015 Page 80