Testauksen automatisointi

1. Testauksen automatisointi Maaret Pyhäjärvi <maaret.pyhajarvi@f-secure.com> Tekijä mainittava, Maaret Pyhäjärvi & Erkki Pöyhönenhttp://creativecommons.org/licenses/by/1.0/fi/

2. Katsaus testiautomaatioon ja testauksen tukemisen välineisiin Työkalun valinnasta käyttöön Päivä 1: Testauksen automatisointi hallittavana prosessina Automatisoitavan testauksen kohteita Automatisointikeskeisten testaustyyppien erityispiirteet Testauksen automatisointi käyttöliittymän kautta Testauksen automatisointi rajapintojen kautta Päivä 2: Testausautomaation toteutus Testattavuuden arviointi, luominen ja mittaaminen Testausautomaation perussäännöt

3. 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

4. Automatisointitasojen vertailu

5. 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ä Nauhoita/Toista -automaatio

6. 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.sqa-test.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

7. 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.

8. 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 Aineisto-ohjattu ja avainsanaohjattu testaus

9. 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

10. Automatisoidun testauksen mekanismeja • Uusintatestaus • Suorituskykytestaus (kuorma/stressi) • Malliperusteinen testaus • Suuren määrän automatisointi (high-volume test automation) todennäköisyyksiin tai satunnaisuuteen perustuen

11. 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 Tyypillisiä automaatiolähtökohtia

12. Automatisoidun testauksen lähestymistapojen lajittelu Testien lähde: Vanhoja Tarkoituksella uusia Satunnaisesti uusia Testien sarjallinen riippuvuus: Itsenäisiä Suoritusjärjestyksellä merkitystä Testijoukon koko: Pieni Suuri Täysin kattava Arviointistrategia: Vertailu talletettuun tulokseen Vertailu oraakkeliinVertailu laskennalliseen tai loogiseen malliin Vertailu heuristiseen ennusteeseen Kaatuminen Diagnostiikka Tilamalli

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!

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

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

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

17. Työkalu ja automatisointikehikko Automatisointikehikko (framework) Työkalu Työkalu Työkalu testiautomaatiojärjestely

18.  Testware Test List Tester        Automation Engine  SUT  Test Results Data Set   Esimerkki automaatioarkkitehtuuristaLähde: Doug Hoffman. 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)

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

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

21. Testiautomaation lokipalveluLähde: Pekka Laukkanen, Qentinel Mahdollisuus suodattaa kiinnostava tieto eri tarpeisiin luodaan perusrakenteita miettiessä. • Ei läpi (fail) • Ei läpäistyn testin kirjaaminen suorituslokiin • Läpi (pass) • Läpäistyn testin kirjaaminen suorituslokiin • 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.

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)

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

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.

25. Erota käsitteet Testijakso Testiaineisto Testitapaus Testiympäristö Testikierros

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” • ...

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ä

28. Testattava kohde ja testioraakkeliLähde: Mukaillen Doug Hoffman Tulos Testattava järjestelmä Syöte Odotettu tulos Aineisto ennen Aineisto jälkeen Ohjelman tila ennen Ohjelman tila jälkeen Testioraakkeli Ympäristö-syötteet Ympäristö-tulos

29. Testitapausten määrän mittaaminen aika

30. Harjoitus: käyttöliittymä- ja rajapinta-automaation 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

31. Työpajan (13.12.2004) yhteenveto, osallistujina: 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) Työpajan tavoitteena oli: 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 Ryhmänä meillä oli kokemuksia: Käyttöliittymäautomaatiosta Mercuryn, Seguen ja Compuwaren välineillä Rajapinta-automaatiosta skriptikielillä (Perl, Python, C) 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ä Toiminnallisen testauksen ja suorituskykytestauksen automatisoinnista 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 FiWST-1 Onnistunut testausautomaatio

32. Katsaus testiautomaatioon ja testauksen tukemisen välineisiin Työkalun valinnasta käyttöön Päivä 1: Testauksen automatisointi hallittavana prosessina Automatisoitavan testauksen kohteita Automatisointikeskeisten testaustyyppien erityispiirteet Testauksen automatisointi käyttöliittymän kautta Testauksen automatisointi rajapintojen kautta Päivä 2: Testausautomaation toteutus Testattavuuden arviointi, luominen ja mittaaminen Testausautomaation perussäännöt

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

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

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

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)

37. Käyttöliittymäautomaation hyötyjen arviointi • Raportit ympäri maailman kyseenalaistavat vahvasti tyypillisten GUI-automaatiohankkeiden 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.

38. Case 1: Konsultointiavusteinen lähtötilanne Perusrakenteet kuntoon ulkoistetulla osaamisella Haasteena tiedonsiirto ja jatkokehitys Käytännössä kaksi konsultointikierrosta ennen riittävää omaa panostusta Case 2: Omin voimin liikkeelle Testikirjastojen luominen “Koko putken” automatisointi asennuksesta arviointiin Osansa haasteita ratkottavana: Muutossietoisuus Uudelleenkäyttökyky Epäluotettava verkko Case: käyttöliittymäautomaation oppeja

39. Katsaus testiautomaatioon ja testauksen tukemisen välineisiin Työkalun valinnasta käyttöön Päivä 1: Testauksen automatisointi hallittavana prosessina Automatisoitavan testauksen kohteita Automatisointikeskeisten testaustyyppien erityispiirteet Testauksen automatisointi käyttöliittymän kautta Testauksen automatisointi rajapintojen kautta Päivä 2: Testausautomaation toteutus Testattavuuden arviointi, luominen ja mittaaminen Testausautomaation perussäännöt

40. Testauksen automatisointi rajapintojen kautta • Työkalu ja tukirakenteet – mitä tarvitaan? • Prosessi ja käytännöt – vaatimukset rajapinta-automatisoinnin näkökulmasta • Rajapinta-automatisoinnin osaaminen ja automatisoinnin organisointi • Rajapinta-automaation hyötyjen arviointi • Case: rajapinta-automaation oppeja

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

42. 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 Prosessi ja käytännöt – vaatimukset rajapinta-automatisoinnin näkökulmasta

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ä

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

45. Case 1: Kehityksenaikainen testaus lähtökohtana Ajoissa mukaan, palautteen nopeudella säästettiin paljon työtä Käyttöliittymän puute toi luonnollisen reitin automatisointiin Case 2: Ulkoisesti määriteltävä protokolla lähtökohtana Määrittelyn laadun parantaminen testauksen tekemisen mahdollistajana Tietyn muotoisen määrittelyn perusteella automatisointi suoraviivaista Case: Rajapinta-automaation oppeja

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?

47. Katsaus testiautomaatioon ja testauksen tukemisen välineisiin Työkalun valinnasta käyttöön Päivä 1: Testauksen automatisointi hallittavana prosessina Automatisoitavan testauksen kohteita Automatisointikeskeisten testaustyyppien erityispiirteet Testauksen automatisointi käyttöliittymän kautta Testauksen automatisointi rajapintojen kautta Päivä 2: Testausautomaation toteutus Testattavuuden arviointi, luominen ja mittaaminen Testausautomaation perussäännöt

48. Testattavuuden arviointi, luominen ja mittaaminen • Testattavuuden vaikutukset automatisointiin • Testattavuuden luomisen periaatteet ja käytännöt • Testattavuuden seuranta ja mittaaminen

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

50. Järjestelmän testattavuus tyypillisessä organisaatiossa Liiketoiminta-suunnittelija Ohjelmisto-suunnittelija Testisuunnittelija Ohjelmisto-kehittäjä Testien kehittäjä Testattava järjestelmä Testaus-järjestelmä