Paranna ohjelmiston laatua ja säästä aikaa infrastruktuuritestauksella

Infrastruktuuri on termi, jolla kuvaamme kaikkea laitteistoa, pilvipalveluita, verkkoyhteyksiä, tukiohjelmistoja ja testattavaa sovellustamme, joita tarvitaan järjestelmiemme kehittämiseen, testaamiseen, käyttöönottoon ja ylläpitoon.

Määritelmäämme ei kuitenkaan ole järkevää rajoittaa teknologiaan. Datakeskukset, toimitilat, työpöydät, pöytätietokoneet, kannettavat tietokoneet, taulutietokoneet ja matkapuhelimet omine asennettuine ohjelmistopinoineen ovat kaikki osa ekosysteemiä, jota tarvitaan järjestelmien kehittämiseen, testaamiseen ja käyttöönottoon.

Kun mukaan lasketaan kehittäjätyökalut, DevOps-työkalut ja -menettelyt, testaustyökalut sekä tarvittavat liiketoimintaprosessit ja alakohtainen asiantuntemus, kokonaisuus laajenee entisestään.

Kaikkein arkisimmatkin asiat – kuten rakennuksiin pääsyyn käytettävät kulkukoodit tai älykortit – voivat muuttua kriittisiksi, jos niitä ei ole saatavilla.

Infrastruktuuri kaikissa muodoissaan on olemassa järjestelmien kehittämisen, testaamisen, käyttöönoton ja käytön tukemiseksi. Se on joko testauksen kannalta kriittistä tai sitä on testattava.

Käsittelemme seuraavassa artikkelissa kehittämiseen, testaamiseen ja yhteistyöhön tarkoitettuja työkaluja. Tässä artikkelissa tarkastelemme sitä, mitä useimmat ihmiset pitävät testiympäristöinä, ja tutustumme lyhyesti siihen, mitä usein kutsutaan infrastruktuurin testaukseksi. Käsittelen seuraavia aiheita:

• Testiympäristöt
• Kehitysympäristöt
• Järjestelmätason testiympäristöt
• Data-ympäristöt
• Infrastruktuurin testaus

Aloitetaan.

Testiympäristöt

Kaikki testaaminen perustuu implisiittiseen, kriittiseen ja yksinkertaistavaan oletukseen: testimme suoritetaan tunnetussa ympäristössä.

Mikä on ympäristö?

Kaikki järjestelmät on testattava asiayhteydessään. Jotta testi olisi merkityksellinen, järjestelmä on asennettava, määritettävä, otettava käyttöön tai rakennettava realistisessa ympäristössä, joka simuloi todellista maailmaa, jossa sitä tullaan käyttämään. 

Voimme esimerkiksi käyttää testiskenaarioita, jotka haastavat järjestelmien toiminnallisuuden, suorituskyvyn tai tietoturvan, mutta nämä ovat testien ominaisuuksia, eivät ympäristön.

Realistinen ympäristö jäljittelisi kaikkia liiketoimintaan, teknologiaan ja organisaatioon liittyviä ympäristöjä. Suuri osa tästä koostuu datasta, jota käytetään liiketoimintaprosessien ohjaamiseen, järjestelmän määrittämiseen ja viitetietojen tarjoamiseen.

Täydellisen realistiset ympäristöt ovat kuitenkin yleensä epäkäytännöllisiä tai aivan liian kalliita (jopa korkean kriittisyyden järjestelmien, kuten lentokoneiden, ydinreaktorien tai aivoskannereiden, testaajien on jossain vaiheessa tehtävä kompromisseja). Lähes kaikki testaus tapahtuu ympäristöissä, jotka simuloivat todellista maailmaa jollakin hyväksyttävällä kompromissitasolla.

Autoja testataan vierintäalustoilla, tuulitunneleissa, tärinäalustoilla ja yksityisillä testiradoilla ennen kuin niitä testataan yleisillä teillä. Tietojärjestelmiä testaavat ohjelmoijat ja ohjelmistotestaajat ohjelmistolaboratorioissa ennen kuin loppukäyttäjiä pyydetään kokeilemaan niitä tuotantoa muistuttavassa ympäristössä.

Varmistaaksesi, että testiympäristösi täyttävät alan standardit, harkitse jonkin näistä parhaiksi arvioiduista testauksenhallinta-alustoista integroimista.

Testaa realistisissa ympäristöissä

Simuloidut ympäristöt ovat erehtyväisiä aivan kuten vaatimuksemme ja testimallimme, mutta meidän on hyväksyttävä tämä.

Meidän on suunniteltava testit, jotka ovat merkityksellisiä käytettävissä olevissa ympäristöissä, ja testitulokset tarkoittavat sitä, miten niitä tulkitsemme.

Testitulosten luotettavuus riippuu ympäristöstä, jossa testit suoritetaan. Jos testi suoritetaan virheellisesti määritetyssä ympäristössä:

• Epäonnistuva testi voi antaa ymmärtää, että järjestelmässä on vikaa, vaikka se todellisuudessa toimii oikein.
• Hyväksytty testi voi antaa ymmärtää, että järjestelmä toimii oikein, vaikka se todellisuudessa on viallinen.

Molemmat tilanteet ovat tietenkin erittäin epätoivottavia.

Ympäristöjen määrittäminen ja toimittaminen ajoissa

Vaikka pilvi-infrastruktuuri on yleistynyt, testiympäristöjen määrittäminen ja ylläpito voi olla vaikeaa ja kallista.

Kun tukitiimit työskentelevät uuden tuotantoympäristön parissa, testaajat tarvitsevat testiympäristöjä (ja mahdollisesti useita). Myöhemmin testauksen aikana tukitiimeillä on usein keskenään kilpailevia vaatimuksia.

Kehittäjäympäristöt tai myöhemmät testausvaiheet voidaan toimittaa myöhässä tai jättää kokonaan toimittamatta, tai niitä ei ehkä ole määritetty tai hallittu vaatimusten mukaisesti. Tämä viivästyttää väistämättä testausta ja/tai heikentää luottamusta testauksen tuloksiin.

Keskeinen tehtävä on määrittää testauksessa käytettävän ympäristön tarve ja vaatimukset sekä kyseisen ympäristön muutosten hallintamekanismi – mahdollisimman pian.

Infrastruktuuri koodina on viimeaikainen kehitysaskel siinä, miten ympäristöjä voidaan rakentaa käyttämällä menettelyjä noudattavia työkaluja ja ympäristön määritykseen tarkoitettua deklaratiivista koodia. 

Vaikka peruskäyttöjärjestelmäalustat (palvelimet) voidaan luoda helposti pilvessä tai omina virtuaalikoneina, täysin määritellyt erityiskäyttöön tarkoitetut palvelimet, joissa on kaikki tarvittavat ohjelmistot, tiedot, määritykset ja rajapinnat, vaativat enemmän työtä.

Testausinfrastruktuuria määritettäessä on erittäin tärkeää integroida luotettava tietokantojen hallintaohjelmisto optimaalisen suorituskyvyn varmistamiseksi

Kun ne on kuitenkin määritetty, ne tarjoavat erittäin tehokkaan tavan ympäristöjen luomiseen. Infrastruktuurikoodi voidaan versionhallita kuten mikä tahansa sovelluskoodi, ja sitä voidaan hallita muutosten kautta.

Jatkuvan toimituksen keskeinen periaate on, että mahdollisimman pian toimitusputken läpi pitäisi viedä jotakin ohjelmistoa – vaikka se ei olisi edes hyödyllistä – jotta voidaan osoittaa prosessien toimivan. 

Tämä edellyttää tietenkin toimivia ympäristöjä koontiversioille, jatkuvan integraation työkaluille, järjestelmätason testaukselle ja käyttöönotolle. Tavoitteena on ottaa testi- ja tuotantoympäristöt käyttöön ilman rajoitteita. Kun ympäristöjen määritykset ja käyttöönottoprosessit ovat paikallaan, ympäristöjen luomisesta tulee automatisoitu ja rutiininomainen tehtävä.

Olosuhteista riippumatta näiden ympäristöjen määritykset ovat projektin varhainen toimitettava tuotos.

Kehitysympäristöt

Kehittäjätestaus keskittyy sellaisten ohjelmistokomponenttien rakentamiseen, jotka tuottavat ominaisuuksia sovelluksen sisäiseen käyttöön tai käyttäjä- tai esitystasolle. 

Testejä ohjaa yleensä tieto koodin sisäisestä rakenteesta, eikä niiden suorittamiseen välttämättä käytetä tai tarvita realistista dataa. Matalan tason komponenttien tai palveluiden testit suoritetaan yleensä API:n kautta käyttämällä mukautettuja tai omistusoikeudellisia ohjaimia tai työkaluja.

Kehitystyökalujen, alustojen ja niin kutsuttujen integroitujen kehitysympäristöjen (IDE:t) valikoima on valtava. Tässä artikkelissa voimme käsitellä vain joitakin ympäristöjen tärkeimpiä testaukseen liittyviä vaatimuksia ja ominaisuuksia.

Kehityksen ja kehittäjien vastuulla olevan testauksen tukemiseksi ympäristöjen on tuettava seuraavia toimintoja. Tämä on vain valikoima – tilanteessasi näitä toimintoja voi olla enemmän tai ne voivat poiketa näistä:

• ’Hiekkalaatikko’-ympäristö uuden ohjelmiston kokeilemiseen. Hiekkalaatikoita käytetään usein uusien kirjastojen testaamiseen, poisheitettävän prototyyppikoodin kehittämiseen tai ohjelmointitekniikoiden harjoittelemiseen. Kaikissa yleisissä ohjelmointikielissä on satoja tai tuhansia ohjelmistokirjastoja. Hiekkalaatikoihin asennetaan ja niissä testataan ohjelmistoja, jotka eivät vielä kuulu kehityksen päähaaraan, jotta niitä voidaan arvioida ja niiden käyttöä harjoitella. Näitä ympäristöjä voidaan pitää kertakäyttöisinä ympäristöinä.
• Paikallinen kehitysympäristö. Tässä ympäristössä kehittäjät ylläpitävät jaetusta koodivarastosta paikallista kopiota sovelluksensa lähdekoodin osasta tai koko lähdekoodista ja voivat luoda järjestelmäkoonteja paikallista testausta varten. Tämä ympäristö antaa kehittäjille mahdollisuuden tehdä muutoksia koodin paikalliseen kopioon ja testata muutoksia. Jotkin testit ovat tilapäisiä, eikä niitä ehkä koskaan toisteta. Muut testit ovat automatisoituja. Automatisoidut testit säilytetään yleensä pysyvästi, erityisesti jos niissä noudatetaan testivetoista lähestymistapaa.
• Jaettu (jatkuvan integraation) ympäristö. Kun kehittäjät luottavat siihen, että heidän koodinsa on valmis, he siirtävät muutoksensa jaettuun, hallittuun koodivarastoon. CI-ympäristö suorittaa automatisoidut koonnit ja testit koodivarastoa käyttäen. Tässä vaiheessa uusi tai muutettu koodi integroidaan ja testataan. CI-järjestelmä suorittaa automatisoidut testit pyynnöstä, tunneittain tai päivittäin, ja koko tiimi saa ilmoituksia ja voi tarkastella uusimman integroidun koonnin testien tilaa. Virheet tuodaan nopeasti esiin ja käsitellään kiireellisinä.

Kehitys- tai CI-ympäristö tukee kehittäjien testausta, mutta muut järjestelmän täydentävät sovelluspalvelimet, verkkopalvelut, viestinvälitys- tai tietokantapalvelimet eivät ehkä ole käytettävissä. 

Jos näitä rajapintajärjestelmiä ei ole, koska niitä ei ole rakennettu tai koska ne kuuluvat yhteistyökumppanille ja käytettävissä on vain tuotantokäytössä oleva järjestelmä eikä testiversiota, kehittäjien on toteutettava näille rajapinnoille vähintään tynkä- tai valetoteutukset voidakseen testata omaa koodiaan. 

Valetoteutustyökalut voivat olla kehittyneitä, mutta valetoteutetut rajapinnat eivät yleensä pysty tukemaan testejä, jotka edellyttävät useiden järjestelmien välistä integroitua dataa.

Jos kehittäjillä on käytettävissään rajapinta testitietokantapalvelimeen, heidän testidatansa voi olla vähäistä, integroimatonta tai epäyhtenäistä eikä se välttämättä vastaa tuotantodataa. 

Tiimin yhteiskäytössä olevat kehitystietokannat ovat yleensä epätyydyttäviä. Jos tämän jaetun resurssin hallintaan ei ole hyviä käytäntöjä, kehittäjät saattavat käyttää uudelleen, turmella tai poistaa toistensa tietoja.

Järjestelmätason testiympäristöt

Järjestelmätason testauksessa keskitytään komponenttien ja alijärjestelmien yhteistoiminnalliseen integrointiin. 

Nämä ympäristöt tarjoavat alustan laajamittaisemman integroinnin, toiminnallisuuden validoinnin ja järjestelmätoimintojen tavoitteiden tukemiseen käyttäjä- tai liiketoimintaprosessien yhteydessä. 

Ympäristöt voidaan myös omistaa järjestelmän ei-toiminnallisille osa-alueille, kuten suorituskyvylle, tietoturvalle tai palvelunhallinnalle.

Yksi yleisimmistä testauksen sudenkuopista syntyy, kun järjestelmätestaaja kohtaa ympäristössään jonkinlaisen virheen, mutta kehittäjä tai testaaja ei kaikista yrityksistään huolimatta pysty toistamaan virhettä kehitysympäristössä.

Tämä johtuu lähes varmasti siitä, että nämä kaksi ympäristöä eivät ole yhdenmukaisia. Käyttäytymisen ero voi johtua määrityksistä, ohjelmistoversioiden eroista tai tietokannan tietojen eroista.

Ongelman aiheuttamat dataerot ovat ensimmäinen tarkistettava asia. Ne on yleensä helppo tunnistaa, ja ne voidaan usein ratkaista nopeasti.

Kun kyseessä on ohjelmistoversion tai määrityksen ristiriita, testaajat ja kehittäjät voivat käyttää paljon aikaa käyttäytymiseron syyn selvittämiseen. 

Kun näitä ongelmia ilmenee, se tarkoittaa usein kehittäjän ja testauksen välisen viestinnän katkeamista. Se voi myös viitata määritysten hallinnan menettämiseen kehitys- tai testiympäristön määrityksessä tai käyttöönottoprosessissa.

Infrastruktuuri koodina ja automatisoitu ympäristöjen käyttöönotto tekevät ympäristöjen yhdenmukaisuusongelmista historiaa.

Erillisten testiympäristöjen tyypit

Järjestelmä-, hyväksymis- ja ei-toiminnallisen testauksen tukemiseksi ympäristöjen on tuettava seuraavia toimintoja (organisaatiossasi voi olla muitakin):

• (Toiminnallinen) järjestelmätestausympäristö. Tässä ympäristössä järjestelmä validoidaan koko järjestelmää koskevia dokumentoituja vaatimuksia vasten. Vaatimukset voivat olla laajoja tekstiasiakirjoja, jotka sisältävät järjestelmätestiä varten määritettyjä taulukoituja testitapauksia. Ketterissä projekteissa tämä ympäristö voi olla tarpeen, jotta testaajat voivat tutkia integroitua järjestelmää rajoittamatta itseään tiettyihin ominaisuuksiin.
• Päästä päähän -testausympäristö. Siinä missä CI-ympäristö mahdollistaa komponenttien integroinnin alijärjestelmiin, liiketoimintaprosessit voivat edellyttää muiden rajapintajärjestelmien (jotka eivät ole kehittäjien hallinnassa) olevan käytettävissä. Laaja-alaisia ympäristöjä tarvitaan laajamittaisen integroinnin, liiketoimintaprosessien tai kokonaisvaltaisen hyväksymistestauksen suorittamiseen. Yleensä data on kopio tuotantodatasta tai ainakin asianmukaisen kokoinen. Kun laajamittainen integraatio on todistettava, data- ja ohjausvirtoja käsitellään pidempien käyttäjäpolkujen avulla ja integroitujen järjestelmien datan riippumattomilla täsmäytyksillä. Datan hallinta testiympäristöissä on ratkaisevan tärkeää. Jos käytät jo Jiraa, harkitse datanhallintaominaisuuksiesi parantamista Jiralle suunnitelluilla edistyneillä testinhallintatyökaluilla.
• Suorituskyky-ympäristö. Näiden ympäristöjen on tarjottava tarkoituksenmukainen alusta järjestelmän (tai valittujen alijärjestelmien) suorituskyvyn arviointiin. Arkkitehtuurissa voidaan tehdä kompromisseja, jos käytössä on palvelinten redundanssia tai kloonausta. Datan määrien on kuitenkin vastattava tuotannon mittakaavaa, vaikka data olisi synteettistä. Ympäristön on ehdottomasti oltava riittävän laaja tukemaan tuotannon tapahtumamääriä, jotta järjestelmien tuotantosuorituskyvystä voidaan tehdä hyödyllisiä ennusteita.
• Saatavuus-, vikasietoisuus- ja hallittavuusympäristöt (ARM). Nämä ympäristöt muistuttavat joiltakin osin suorituskyky-ympäristöjä, mutta testitavoitteesta riippuen vaihtelut voivat olla väistämättömiä. Saatavuustestauksella pyritään varmistamaan, että järjestelmä voi toimia pitkiä ajanjaksoja ilman vikaantumista. Vikasietoisuustestauksella (jota kutsutaan usein vikasietotestaukseksi) tarkistetaan, etteivät järjestelmän komponenttien vikaantumiset aiheuta toimitettuun palveluun kohtuuttomia häiriöitä. Hallittavuus- eli operointitestauksella pyritään osoittamaan, että järjestelmän hallinta-, ylläpito- sekä varmuuskopiointi- ja palautusmenettelyt toimivat tehokkaasti.

Data ympäristöissä

Joissakin erittäin suurissa projekteissa voi olla jopa 20 tai 30 laajamittaista ympäristöä, jotka on omistettu testauksen, koulutuksen, datamigraation ja harjoitusvaihtojen eri osa-alueille. Pienemmissä projekteissa ympäristöjä on vähemmän, ehkä vain yksi jaettu ympäristö tai jatkuvan toimituksen toimintamalli – ja kaikki testaus voidaan toteuttaa automaattisesti ympäristöissä, jotka luodaan vain yhtä käyttökertaa varten ja puretaan sen jälkeen.

Kaikki ympäristöt tarvitsevat dataa, mutta datan mittakaava ja realistisuusaste voivat vaihdella. Seuraavassa on joitakin yleisiä toimintamalleja testidatan hankintaan ja hallintaan. Näissä toimintamalleissa keskitytään omistajuuteen (paikallinen tai jaettu), luontitapaan (manuaalinen, automatisoitu tai tuotannosta kopioitu) ja mittakaavaan:

• Paikallinen, manuaalisesti luotu, pienimuotoinen data – soveltuu kehittäjien tai testaajien suorittamaan tapauskohtaiseen testaukseen.
• Paikallinen, automaattisesti luotu synteettinen data. Soveltuu kehittäjien automatisoituihin testeihin tai ympäristöihin, joissa tiettyjen moduulien tai ominaisuuksien toiminnallisuus voidaan kattaa.
• Jaettu, manuaalisesti luotu data. Käytetään integraatio- ja järjestelmätestausympäristöissä, usein silloin, kun testidata on kehittynyt samanaikaisesti manuaalisesti suoritettujen testien kanssa. Varmuuskopioidaan ja palautetaan tarvittaessa.
• Jaettu, automaattisesti luotu data. Käytetään integraatio- ja järjestelmätestausympäristöissä, joissa testidata on kehittynyt samanaikaisesti automaattisesti tai manuaalisesti suoritettujen testien kanssa. Luodaan ja/tai palautetaan varmuuskopioista tarvittaessa.
• Jaettu laajamittainen synteettinen/satunnainen data. Suorituskyky- ja ARM-testaukset edellyttävät johdonmukaista dataa suurina määrinä. Tämän datan ei yleensä tarvitse olla merkityksellistä – satunnaistettu data toimii hyvin, ja se luodaan tarvittaessa tai luodaan alun perin ja palautetaan varmuuskopioista.
• Jaettu laajamittainen merkityksellinen data. Päästä päähän -testaus, hyväksymistestaus tai käyttäjätestaus edellyttää yleensä merkityksellistä dataa suuressa mittakaavassa. Joskus käytetään kopioita tai poimintoja tuotantodatasta. Varo kuitenkin rikkomasta datasäädöksiä, jos et sekoita tai anonymisoi dataa.
• Uudelleentestaus ja regressiotestaus. Tarvitset tunnetun ja hallitun tietojoukon tunnetussa tilassa, joten se palautetaan yleensä varmuuskopioista. Tämä koskee kaikkia edellä mainittuja ympäristöjä, sillä nämä testit on suoritettava uudelleen datalla, joka on tunnetussa tilassa, jotta virheet voidaan toistaa luotettavasti.

Infrastruktuurin testaus

Tämän artikkelin alussa tarkastelimme, mitä infrastruktuuri sisältää, ja sen jälkeen olemme keskittyneet pääasiassa teknisiin komponentteihin eli ohjelmistojärjestelmiin sekä olettaneet, että laitteisto – fyysinen tai virtuaalinen – on käytettävissä.

Kun rakennamme järjestelmiä alun perin, oletamme infrastruktuurin olevan olemassa ja toimivan oikein, suorituskykyisesti, turvallisesti ja vikasietoisesti.

Voimme testata kaikkia näitä osa-alueita, kun olemme integroineet sovelluksemme, ja epäilemättä tuoda esiin infrastruktuurin puutteita suhteellisen myöhäisessä vaiheessa projektejamme. Infrastruktuuriongelmien löytäminen näin myöhään projektissa on kuitenkin yleensä erittäin häiritsevää.

• Infrastruktuurin vikaantumisten korjaamiseen tarvittavat muutokset saattavat edellyttää sovelluksemme merkittävää uudelleensuunnittelua ja muuttamista.
• Sovelluksemme tai koko järjestelmän testauksen tulokset on toistettava.
• Jos kolmannen osapuolen komponentit, kuten tietokanta-, verkko-, verkkopalvelu- tai viestintäpalvelut, vikaantuvat, olemme niitä tukevien toimittajien (tai avoimen lähdekoodin yhteisön) armoilla.

Varmistaaksemme, että luottamuksemme infrastruktuurikomponentteihin on perusteltua, voimme hyödyntää omaa tai muiden aiempaa kokemusta niiden käytöstä. Vaihtoehtoisesti meidän on arvioitava niiden luotettavuus testaamalla ennen kuin sitoudumme käyttämään niitä järjestelmämme suunnittelussa ja rakentamisessa.

Tutkittavasta infrastruktuurista riippuen käyttämämme ympäristö voi vaihdella yksittäisestä palvelimesta lähes täydelliseen infrastruktuurialustaan. 

Vaikka jotkin testit tehdään manuaalisesti, käytämme enimmäkseen työkaluja, ajureita tai robotteja simuloimaan sovelluksemme tuottamaa tapahtumakuormaa. Meidän on ehkä jäljiteltävä tai korvattava nämä rajapinnat tyngillä:

• Rajapinnat, jotka eivät ole tällä hetkellä käytettävissä
• Rajapinnat komponentteihin, joihin luotamme ja joita on helppo simuloida
• Rajapinnat, jotka eivät kuulu soveltamisalaan eivätkä vaikuta testattavaan infrastruktuuriin.

Infrastruktuuri ei luonnollisestikaan yleensä toimi käyttäjä- tai graafisen käyttöliittymän kautta.

Sovelluksemme integrointi infrastruktuuriin tapahtuu enimmäkseen viestien tai etäpalvelukutsujen muodossa. Usein simuloitava liikenne edellyttää API-kutsuja verkko- tai sovelluspalvelimille, viesti- tai tietokantapalvelimille tai pilven kautta tai etäsijainneista toimitettaville palveluille.

Suorituskyky- ja ARM-tavoitteet saattavat olla tiedossa, jolloin voidaan suorittaa testejä sen varmistamiseksi, että nämä tavoitteet saavutetaan.

Infrastruktuuri on kuitenkin usein jaettu muidenkin kuin omien sovellustemme kanssa, joten sen enimmäiskapasiteetin tunteminen auttaa arvioimaan, kuinka paljon kapasiteettia jää jäljelle, kun sovelluksemme otetaan käyttöön.

Tässä tapauksessa infrastruktuurin testauksella käsitellään riskiä, joka kohdistuu omaan sovellukseemme ja mahdollisesti muihin sovelluksiin, jotka tulevaisuudessa perustuvat siihen. 

Tilaa The QA Lead -uutiskirje, niin saat ilmoituksen, kun sarjan uudet osat julkaistaan. Nämä kirjoitukset ovat otteita Paulin Johtaminen testauksessa -kurssista, jota suosittelemme lämpimästi tämän ja muiden aiheiden syvällisempään tarkasteluun. Jos teet sen, käytä ainutlaatuista kuponkikoodiamme QALEADOFFER ja saat 60 dollaria alennusta kurssin täydestä hinnasta!

Suositeltavaa luettavaa: 10 PARASTA AVOIMEN LÄHDEKOODIN TESTAUKSENHALLINTATYÖKALUA