Johtajuutta testauksessa: testien suoritustyökalut

Testien (suorittamisen) automatisointi

Testien automatisointi (yleensä graafisen käyttöliittymän kautta) on useimpien testaajien ja testipäälliköiden asialistalla korkealla. Pintapuolisesti nämä työkalut vaikuttavat erittäin lupaavilta, mutta monet organisaatiot, jotka haluavat automatisoida osan tai kaiken toiminnallisesta testauksestaan, törmäävät ongelmiin.

Emme perehdy tässä artikkelissa teknisiin yksityiskohtiin kovin syvällisesti, mutta käsittelemme joitakin sellaisia ongelmia, jotka ovat merkityksellisiä testaus- ja projektipäälliköille, joiden on laadittava automaation liiketoimintaperustelu. Tarkastelemme seuraavia aiheita:

• Mitä testien suorittamisen työkalut tarjoavat ja mitä eivät
• Graafisen käyttöliittymän (GUI) testien automatisointi
• API- ja palvelutestien automatisointi
• Regressiotestaus
• Testiautomaatiokehykset

On tärkeää asettaa realistiset odotukset sille, mitä automaatio voi ja ei voi tehdä, joten seuraavat osiot saattavat vaikuttaa jokseenkin pessimistisiltä.

Mitä testien suorittamisen työkalut tarjoavat ja mitä eivät

Testasitpa Windows-työpöytäsovelluksia, verkkosivustoja tai mobiililaitteita, testiautomaation periaatteet, hyödyt ja sudenkuopat ovat samankaltaisia. Työkalut tarjoavat seuraavaa:

• Väsymättömän, oletettavasti virheettömän robotin, joka suorittaa haluamasi komentosarjoitetut testit tarvittaessa niin usein kuin haluat.
• Tarkan vertailun testien tulosteen ja/tai lopputuloksen sekä ennalta määritettyjen odotettujen tulosten välillä sillä tarkkuustasolla, jonka olet valmis ohjelmoimaan työkaluun.

Et saa seuraavia:

• Joustavuutta ja sujuvaa reagointia poikkeamiin, virheisiin tai kyseenalaiseen toimintaan.
• Ihmistestaajan silmiä ja ajattelua eli kykyä tehdä päätöksiä testattavan järjestelmän toiminnan tutkimiseksi, kyseenalaistamiseksi, kokeilemiseksi ja haastamiseksi.
• Testejä ilmaiseksi. Sinun on esimerkiksi edelleen suunniteltava testit sekä valmisteltava testidata ja odotetut tulokset.
• Vaikka testien suorittamisen työkalut tarjoavat monenlaisia toimintoja, niistä puuttuu usein kehittyneitä tietojen tallennusominaisuuksia. Jos haluat kattavamman ratkaisun, tutustu saatavilla olevaan parhaaseen tietokantojen hallintaohjelmistoon.

Tarkastellaanpa näiden hyötyjen ja ongelmien merkitystä.

Jos olet kohtuullisen taitava ohjelmoija, ihmisten suorittamien proseduraalisten testien toteuttaminen automaattisina proseduurina työkalusi komentosarjakielellä on suoraviivaista, ja työkalu voi suorittaa ne tarkasti.

Niin kauan kuin testisovelluksesi käyttämä ympäristö ja data pysyvät yhdenmukaisina, voit odottaa testiesi suorittuvan luotettavasti yhä uudelleen. Tämä on testien automatisoidun suorittamisen ilmeinen lupaus.

Automatisoidut testit eivät kuitenkaan simuloi tarkasti sitä, mitä (hyvät) testaajat tekevät testatessaan.

Työkalun suorittama testi EI vastaa ihmisen suorittamaa samaa testiä.

Jos testi on komentosarjoitettu, se saattaa kertoa testaajalle, mitä tehdä. Testaajat voivat kuitenkin tarkastella yksinkertaisen näytöllä näkyvän tuloksen ja odotetun tuloksen välistä vertailua laajemmin.

Testaajien on siirryttävä testin sijaintiin ja tarkkailtava valppaasti poikkeavaa toimintaa – komentojen vastetta, vasteen nopeutta, näytön ulkoasua sekä niiden objektien toimintaa, joihin sovelluksen muuttuva tila vaikuttaa.

Havaitessaan poikkeaman ihmistestaaja saattaa pysähtyä, palata vaiheitaan taaksepäin tai tarkastella sovellusta tai dataa syvällisemmin, ennen kuin hän päättelee sovelluksen toimivan oikein (tai ei) ja päättää, jatkaako komentosarjoitettua testiä, muuttaako testin dataa ja komentosarjaa vai jatkaako suunnitellulla tavalla.

Ihmiset ovat joustavia, kun taas työkalut tekevät vain täsmälleen sen, mitä ohjelmoit niiden tekemään. Näyttöpohjaisessa tapahtumassa työkalu syöttää tietoja, napsauttaa painiketta ja tarkistaa viestin tai näytetyn tuloksen – ja siinä kaikki. Ihmistestaajat tuovat mukanaan paljon enemmän sellaista, mitä pidämme itsestään selvänä. 

Periaatteessa työkalu on mahdollista ohjelmoida suorittamaan kaikki tarkistukset, jotka ihminen tekee vaistomaisesti – mutta silloin joudut kirjoittamaan paljon koodia ja käyttämään aikaa testiesi virheenkorjaukseen. Silloinkaan et saa ihmisen kykyä päättää, mitä seuraavaksi tehdään – pysähtyä, jatkaa, muuttaa testiä kesken kaiken tai tutkia poikkeamaa perusteellisemmin.

Työkalujen joustamattomuus tulee selvimmin esiin silloin, kun komentosarjan synkronointi testattavan järjestelmän kanssa menetetään. Ehkä odotettu tulos ei täsmää, järjestelmä kaatuu tai käyttöliittymän toiminta (esimerkiksi kenttien muuttunut järjestys tai uusi kenttä) poikkeaa siitä, mitä komentosarja odottaa. Mitä työkalu tekee? Se yrittää jatkaa, minkä seurauksena syntyy valtava määrä komentosarjavirheitä tai kaatumisia. 

Kyllä, komentosarjassa voi ja kannattaa olla suunnittelemattomien tapahtumien käsittelijöitä testien epäonnistumisten sieppaamista varten. Synkronoinnin menetys, järjestelmän tilan ja testitietojen väliset ristiriidat, kenttien järjestyksen muutokset, uudet kentät tai poistettavat kentät ovat asioita, jotka testaaja voi tunnistaa ja joiden perusteella hän voi toimia ilman, että testaus pysähtyy kokonaan. Työkalut eivät pysty tähän ilman huomattavaa ohjelmointityötä.

Myös ihmisten käyttämiseen komentosarjapohjaisten testien suorittamiseen liittyy haittoja. Testaajat voivat keskittyä liikaa komentosarjan noudattamiseen ja unohtaa käyttää havainnointikykyään. He saattavat jättää ilmeiset poikkeamat huomaamatta, koska keskittyvät komentosarjan seuraamiseen. Tämä epäoptimaalinen lähestymistapa on juuri se, mitä saamme testien suorituksen automatisoinnilla.

Testikomentosarjojen sokea noudattaminen on ihmistestaajille huono ajatus, mutta testiautomaatiossa se on parasta, mitä voimme tehdä.

Tässä vertaillessamme komentosarjoja seuraavia testaajia testejä suorittaviin työkaluihin emme ole tarkastelleet, mitä tutkivat testaajat tekevät. Tutkiva lähestymistapa antaa testaajille vapauden tutkia ja testata missä ja miten he haluavat. 

Työkalut eivät selvästikään pysty simuloimaan tätä toimintaa. Vielä tärkeämpää on, etteivät työkalut pysty määrittämään järjestelmän toiminnallisuuden ja riskien laajuutta, asettamaan niitä tärkeysjärjestykseen ja mallintamaan niitä sekä suunnittelemaan testejä niiden mukaisesti.

Testien analysointi- ja suunnittelutoimet ovat tarpeen riippumatta siitä, suorittaako testin ihminen vai työkalu.

Testien suoritustyökalujen mahdollisuuksia rajoittavat lisäksi seuraavat seikat:

• Testien suoritustyökalut tekevät täsmälleen sen, mitä ohjelmoit niiden tekemään – eivät enempää eivätkä vähempää
• Työkalut eivät yleensä suorita ympäristöjen ja sovellusten koontia ja määrityksiä eivätkä lataa testitietoja
• Työkalut eivät suunnittele testitapauksia tai komentosarjoja eivätkä valmistele testitietoja ja odotettuja tuloksia
• Työkalut eivät pysty tekemään harkittuja päätöksiä odottamattomien tapahtumien yhteydessä.

Testien suoritusprosessien optimoimiseksi niiden integrointi vankkaan testinhallintaohjelmistoon voi tarjota sujuvammat työnkulut ja paremmat raportointimahdollisuudet.

Graafisen käyttöliittymän (GUI) testauksen automatisointi

Graafisen käyttöliittymän testiautomaatiotyökalujen tulosta markkinoille on kulunut noin kaksikymmentäviisi vuotta, mutta epäonnistuneiden graafisen käyttöliittymän testityökalujen käyttöönottojen määrä on edelleen suuri. Tämä johtuu pääasiassa siitä, että automaatiolle asetetaan liian suuria odotuksia – ja ilman kurinalaisuutta käytetyt työkalut eivät koskaan täytä niitä.

Graafisen käyttöliittymän testiautomaatiotyökaluilla on maine tuotteina helppokäyttöisinä, mutta vaikeasti hallittavina, kun testattavia sovelluksia (ja siten testikomentosarjoja) on muutettava. Nämä työkalut ovat erittäin herkkiä käyttöliittymän muutoksille. Sijainnin, järjestyksen tai koon muutokset sekä näyttöobjektien lisääminen tai poistaminen voivat kaikki vaikuttaa komentosarjoihin. Myös teknisemmät muutokset, kuten näyttöobjektien uudelleennimeäminen tai ”näkymättömien” upotettujen graafisen käyttöliittymän kirjastojen muuttaminen, aiheuttavat ongelmia.

Graafisen käyttöliittymän testiautomaatio toimii parhaiten, kun seuraavista asioista huolehditaan kurinalaisesti:

• Kehitysprosessia sekä muutoksia ja julkaisuja hallitaan huolellisesti. Esimerkiksi muutosten vaikutukset analysoidaan ja niistä ilmoitetaan testaajille. 
• Testikomentosarjojen kehittämistapa. Kokeneet testiautomaatioinsinöörit käyttävät järjestelmällisiä nimeämiskäytäntöjä, hakemistorakenteita, modulaarisia ja uudelleenkäytettäviä komponentteja, ennakoivan ohjelmoinnin tekniikoita ja niin edelleen.

Testiautomaatioskriptien kirjoittaminen on tehtävä, joka edellyttää perustason ohjelmointitaitoja enemmän ja ennen kaikkea automaation sekä käytettävän työkalun tuntemusta. Kun testejä automatisoidaan laajassa mittakaavassa, tarvitaan myös suunnittelutaitoja. 

Riippumatta siitä, miten toimittajat kuvailevat työkalujaan – ”komentosarjattomiksi”, ”muiden kuin ohjelmoijien käytettäviksi” tai ”myös käyttäjät voivat automatisoida” – tarvitset silti ohjelmoijan ajattelutavan, suunnittelutaitoja ja järjestelmällisen lähestymistavan.

API- ja palvelutestauksen automatisointi

Kun komponentteja tai toiminnallisuuksia otetaan käyttöön palveluina, joita kutsutaan ohuista tai mobiiliasiakasohjelmista, testaus suoritetaan API:n avulla tai palvelukutsujen kautta. Tämä testaustapa toteutetaan joko kehittäjien kirjoittamalla mukautetulla koodilla tai käyttämällä erillisiä API- tai palvelutestaustyökaluja. Joka tapauksessa tavanomainen lähestymistapa on automatisoida testaus tavalla tai toisella.

Koska API on testattavaan koodiin ”lähempänä”, testit voidaan kohdistaa paljon tarkemmin testattavaan toiminnallisuuteen. Käyttöliittymässä navigoinnin ja itse käyttöliittymän kautta testaamisen monimutkaisuudet voidaan epäilemättä ohittaa. Tästä syystä yleinen sääntö on:

Jos testattava toiminnallisuus (koodi- tai komponenttitasolla) voidaan testata funktiokutsulla, API:n tai palvelun kutsulla, automaatio on helpompaa – ja sitä suositellaan.

API:n kautta testaamisella on selviä etuja.

• Vaikka sinun on käytettävä tai kirjoitettava koodia, itse testien suorittaminen on paljon helpompaa (käyttöliittymästä ei tarvitse huolehtia).
• Kun API-kutsu on skriptattu, sinun tarvitsee vain taulukoida testitapausten joukko, jota haluat käyttää. Suoritettavien testien määrää ei ole rajoitettu.
• API-pohjaiset testit suoritetaan yleensä paljon nopeammin, joten tämä testaustyyli soveltuu hyvin jatkuvan toimituksen lähestymistapoihin, joissa käyttöönottoputki on pitkälle automatisoitu ja sen on reagoitava nopeasti.

”Testiautomaation pyramidi” (Google-haku näyttää satoja esimerkkejä kuvasta) on otettu lähes yleisesti käyttöön suosituksena siitä, että testiautomaatiota tulisi painottaa enemmän kehittäjä- tai API-testaukseen kuin GUI:n kautta testaamiseen.

• Käytä UI-testejä silloin, kun käyttäjän työnkulku on suoritettava, mutta vähäisessä määrin, koska testit ovat kalliita ja niiden suorittaminen voi olla hidasta.
• Käytä API- tai palvelukutsuja silloin, kun testattava toiminnallisuus voidaan eristää ja kun automaation nopeus ja helppous ovat olennaisia.

Regressiotestaus

Automaattisten työkalujen perinteinen käyttötarkoitus on regressiotestien suorittaminen. Nämä testit suoritetaan kerran, ja niiden oletetaan kuvaavan odotettua toimintaa tarkasti. Kun testattavan sovelluksen koodi, siihen liittyvät uudelleenkäytettävät kirjastot tai testiympäristö muuttuvat, nämä testit antavat jonkin verran varmuutta siitä, ettei muutos ole vaikuttanut haitallisesti vaadittuun toiminnallisuuteen.

Voit kuvitella automaattiset testit muotiksi, johon testattava järjestelmä sopii. Testien pitäisi tietenkin ”läpäistä” kaikki aiemmin suoritetut tarkistukset. Suorittamalla testit uudelleen pyrit osoittamaan uuden ohjelmistoversion toiminnallisen vastaavuuden aiempaan versioon verrattuna. Sinun on noudatettava muutamia yksinkertaisia periaatteita:

• Ensinnäkin suorittamasi testit ja tarkistukset on valittava siten, että voit luottaa siihen, ettei toiminnassa esiinny ei-toivottuja muutoksia. Nämä testit toimivat ”laukaisulankana”, joka havaitsee toiminnan erot.
• Kun virheitä korjataan tai ohjelmistoon tehdään muita muutoksia, toiminnassa voi olla tapauksia, joita muutetaan (oikein), mutta jotka testiesi kohdatessa aiheuttavat tarkistuksen epäonnistumisen. Sinun on joko muutettava testejä etukäteen tai annettava niiden epäonnistua ja korjattava ne jälkikäteen. Joskus on nopeampaa poistaa epäonnistuvat testit kokonaan ja luoda niiden tilalle uudet testit alusta alkaen. Joka tapauksessa nämä muutetut testit on suoritettava loppuun asti, ja niiden on läpäistävä testit.
• Jos testattava järjestelmä ei ole vakaa, siinä on paljon virheitä tai siihen tehdään laajoja muutoksia julkaisujen välillä, automaattisten testien joukon ylläpito ei ehkä ole taloudellisesti järkevää. Vaikka järjestelmän toiminnallisuus ei muuttuisi, käyttöliittymä saattaa edelleen kehittyä – epävakaa UI vaikeuttaa myös automaation ylläpitoa. Testien epäonnistumisten tutkimisen ja testien ylläpidon kustannukset voivat ylittää niiden hyödyt. Voi olla järkevää testata järjestelmän epävakaampia osia manuaalisesti, kunnes ne vakiintuvat.

Käyttöliittymän kautta testaaminen voi joskus olla hankalaa, kallista ja hidasta. Ennen kuin aloitat GUI-testiautomaation tai edes automatisoit yhden skriptin, on järkevää pohtia, olisiko keskeisten toiminnallisuuksien testaaminen helpompaa, nopeampaa ja taloudellisempaa API:n avulla.

Automaattisten työkalujen perinteinen käyttötarkoitus on regressiotestien suorittaminen. Varmistaaksesi, että käytät tähän tehokkaimpia työkaluja, tutustu luetteloomme parhaista ohjelmistotestauksen työkaluista

Testiautomaation viitekehykset

Testausviitekehykset ovat olennainen osa onnistunutta automaattista testausprosessia. Ajattele niitä ohjeistona, jota käytetään testitapausten luomiseen ja suunnitteluun. Niiden käyttö voi nopeuttaa ja tehostaa testitiimisi toimintaa, parantaa testien tarkkuutta, vähentää riskejä ja pienentää testien ylläpitokustannuksia. Tarkastelemme nyt kahta niistä.

Testiautomaation viitekehyksistä keskusteltaessa on olennaista ottaa huomioon QA-automaatiotyökalujen rooli tehokkaan testaustrategian muovaamisessa.

Yksikkötestauksen viitekehykset

Yksikkötestauksen viitekehyksiä on ollut olemassa jo useita vuosia, ja ohjelmoijat käyttävät niitä laajasti koodinsa testaamiseen. Kehittäjien testit ovat yleensä melko paikallisia – ne testaavat yleensä yhden komponentin, jonka rajapinnat muihin komponentteihin tai tietokantoihin on jäljitelty tai korvattu tynkärajapinnoilla. Vaikka yksikkötestit edellyttävät valmistelu- ja purkuvaiheita ennen testien suorittamista ja niiden jälkeen, nämä tehtävät rajoittuvat yleensä yhden komponentin testien suorittamiseen. Jokaiselle komponentille olisi erillinen testisarja.

Kehittäjien luomat yksikkötestit ovat yleensä versionhallinnassa, ja niitä hallitaan rinnakkain komponenttikoodin kanssa. Tyypillisesti jatkuvan integraation palvelut ottavat lähdekoodin ja kaikki yksikkötestit ja suorittavat ne jokaisen uuden koodin ja/tai testien vahvistuksen jälkeen. Kaikki kehittäjät näkevät näiden testien tulokset, joten testin epäonnistuminen jatkuvan integraation ympäristössä tulee hyvin näkyväksi. Epäonnistuneiden testien ja koodin korjaaminen on jatkuvaa integraatiota tällä tavoin käyttävissä tiimeissä ensisijaisen tärkeää, jotta järjestelmän uusin versio läpäisee jatkuvan integraation kaikki testit jatkuvasti.

Integraatio- ja järjestelmätestien automatisointikehykset

Viime vuosina graafisen käyttöliittymän testityökaluja on integroitu jatkuvan integraation työkaluihin käyttämällä virtualisoituja testilaitteita ja -ympäristöjä sekä komentorivikäyttöliittymän kautta tapahtuvaa suoritusta. Monet organisaatiot ovat pystyneet integroimaan yksikkö-, rajapintatason ja graafisen käyttöliittymän testien suorittamisen kokonaan jatkuvan integraation palveluihin.

Monet testaustiimit käyttävät kuitenkin edelleen omia testiympäristöjään erillään kehityksestä tai jatkuvan integraation palveluista. Nämä tiimit rakentavat yleensä omat testien automatisointikehyksensä, koska jatkuvan integraation työkalut ovat liian kehittäjäsuuntautuneita tai omisteiset työkalut ovat riittämättömiä.

Graafisen käyttöliittymän testit toteuttavat yleensä päästä päähän -testejä tai käyttäjäpolkuja, joissa käytetään eri sovelluksia, laitteita ja ympäristöjä. Näissä testeissä integroidut testiympäristöt ja valmistellut testitiedot on pystyttävä määrittämään saumattomasti eri alustoille, mikä edellyttää käyttöoikeuksiltaan rajoitettuja ja monimutkaisia menettelyjä sekä erilaisia teknisiä käyttöympäristöjä. Valtaosa graafisen käyttöliittymän testien automatisointia käyttävistä tiimeistä rakentaa oman ainutlaatuisen mutta tehokkaan automatisointikehyksensä.

Graafisen käyttöliittymän automatisointikehykset vaihtelevat yksikkötestien kaltaisista työkaluista monimutkaisiin ja kattaviin ratkaisuihin, joita tarvitaan ympäristöjen, sovelluskoontiversioiden, valtavien testitietomäärien, alustojen ja ympäristöjen välisen viestinnän ja synkronoinnin sekä tiimin jäsenten viestinnän ja ilmoitusten hallintaan.

Joidenkin omisteisten työkalujen mukana toimitetaan apuohjelmia tai testikehyksiä automatisoitujen testikokoelmien hallintaan, suorittamiseen ja raportointiin. Niiden hyödyllisyys vaihtelee, joten monet organisaatiot kirjoittavat omat testien automatisointikehyksensä laajentaakseen niiden toiminnallisuutta. Viime vuosina automatisointikehysten laajuus on kasvanut, eikä niille ole enää olemassa yhtä ainoaa tai yksinkertaista määritelmää. Tarkastelemme nyt, mitä testien automatisointikehykset voivat tehdä ohjelmistotiimien hyväksi.

Testien automatisointikehys laajentaa testien suoritusmoottorien toiminnallisuutta.

Testikokoelman määritys

Kehys yhdistää automatisoidut testit tarkoituksenmukaisiksi testikokoelmiksi tai -ryhmiksi. Näitä kokoelmia voidaan määrittää siten, että testit voidaan suorittaa hierarkkisina sarjoina, ryhminä tai mielivaltaisina valintoina. Työkaluihin voi sisältyä ominaisuuksia, joiden avulla testejä ohjataan testitietojen valmistelluilla taulukoilla. Tämä on yksinkertaisin kehystyyppi — suositut työkalut tarjoavat yleensä jonkinlaisen testikokoelman määrityksen.

Alustus ja purku

Kehys käsittelee yksittäisen testin, kokoelman tai kokonaisen testikokoelman kaikki alustus- ja purkutoimet. Alustus voi tarkoittaa testiympäristöjen luomista tyhjästä, täydellisten määritysten tekemistä sekä testitietokantojen ja muiden tietolähteiden esilataamista alusta alkaen. Purku voi tarkoittaa testitietojen siivoamista tai osittaisten tai kokonaisten ympäristöjen palauttamista alkutilaan tai poistamista. Kehys voi integroitua työnkulun orkestrointityökaluihin ja olla niiden hallinnassa.

Poikkeusten käsittely

Kaikkien testien epäonnistuminen – johtuipa se testattavasta järjestelmästä tai synkronoinnin menettämisestä – voidaan käsitellä johdonmukaisesti raportoimalla tapahtumasta ja yleensä sallimalla kyseisen kokoelman jäljellä olevien testien suorittamisen. Kehys voidaan ohjelmoida käsittelemään testin tarkistusten epäonnistumisia, synkronoinnin menettämistä, suorituksen aikakatkaisuja ja muita valittuja testituloksia – jokaista mukautetuilla menettelyillä.

Lokitus ja viestintä

Kehys kirjaa testien suorituksen ja suorituksen tilan johdonmukaisesti kaikissa testikokoelmissa. Kehys joko käynnistää raportit testejä suorittavista työkaluista tai tarjoaa johdonmukaisen raportointipäiväkirjan kaikista testien alustukseen, suoritukseen ja purkuun liittyvistä toimista. Kehys voi olla vuorovaikutuksessa ChatOps-bottien kanssa ilmoittaakseen tiimille poikkeuksista ja antaakseen tiimin jäsenille mahdollisuuden keskeyttää, pysäyttää, toistaa tai käynnistää testikokoelmia uudelleen.

Testien abstraktio toimialakohtaisella kielellä

Markkinoille on syntynyt kaksi erilaista kehystyyppiä, jotka abstrahoivat testien suorittamisen koodin malleiksi tai ihmisen luettavaksi tai ei-tekniseksi tekstiksi:

• Avainsanapohjaisissa kehyksissä testit voidaan määrittää avainsanojen avulla. Kutsut suoritusmoottorin ominaisuuksiin toteutetaan englannin kaltaisina komentoina, joissa on paikkamerkkejä parametreille tai tiedoille. Käyttäjän määrittämiä, uudelleenkäytettäviä moduuleja voidaan määrittää ja kutsua pelkillä tekstikomennoilla samalla tavalla. Kehyksiä on kaikenlaisille käyttöliittymille, kuten graafisille käyttöliittymille, palveluille, rajapinnoille ja komentorivitulkeille. Skriptit voivat käyttää toiminnallisuutta eri käyttöjärjestelmä- ja laitealustoilla.
• Käyttäytymislähtöisen kehityksen (BDD) kehykset mahdollistavat ominaisuuksien käyttäytymistä kuvaavien tarinoiden ja skenaarioiden (esimerkkien) tallentamisen toimialakohtaisella kielellä (DSL). Suosituin kieli on niin sanottu Gherkin, joka käyttää esimerkkien kuvaamiseen ”olettaen … kun … niin …” -rakennetta. Olettaminen, kun ja niin edustavat käytännössä testitapausten esiehtoja, vaiheita ja jälkiehtoja. BDD-työkalut muuntavat olettaen-, kun- ja niin-tekstin ohjelmointikielisiksi ”vaihekutsuiksi”. Kehittäjän (tai testaajan) on toteutettava ”testivakiot” tai koodi, joka tekee kutsut testien suoritusmoottoriin. Näin vaatimus kielenä (tarina) voidaan yhdistää suoraan tekstin suorittavaan koodiin.

Mallipohjaiset kehykset

Tässä tapauksessa työkalujen avulla voidaan luoda testattavan järjestelmän malli. Se voidaan johtaa automaattisesti verkkosivulta, jolloin työkalu skannaa HTML-koodin, tunnistaa lomakkeet ja kentät sekä rakentaa mallin, jonka perusteella lomakkeiden läpi kulkevat polut voidaan joko luoda automaattisesti tai testaaja voi valita ne. Mobiilisovellusten tai muiden älylaitteiden objektikartat voidaan myös rakentaa manuaalisesti. Objektikartan läpi kulkevien polkujen avulla testien suoritusmoottorin toimintoihin tehdään kutsuja samalla tavalla kuin BDD- ja avainsanapohjaisilla työkaluilla. Periaatteessa testit voidaan rakentaa graafisesti ilman koodia. Tämän alueen työkalut ovat suhteellisen uusia ja kehittyvät nopeasti. Niiden käytön voi odottaa lisääntyvän tulevaisuudessa.

Tilaa The QA Lead -uutiskirje, niin saat ilmoituksen, kun sarjan uusia osia julkaistaan. Nämä kirjoitukset ovat otteita Paulin Leadership In Test -kurssista, jota suosittelemme lämpimästi, jos haluat perehtyä tähän ja muihin aiheisiin syvällisemmin. Jos päätät osallistua, käytä eksklusiivista kuponkikoodiamme QALEADOFFER ja säästä 60 dollaria kurssin täydestä hinnasta!

Aiheeseen liittyvä lukeminen: 10 PARASTA VERKKOPALVELINTEN VALVONTAAN TARKOITETTUA TYÖKALUA