Mitä on ohjelmistotestaus? 100+ ilmaista manuaalisen testauksen opetusohjelmaa

Täydellinen ohjelmistotestauksen opas, jossa on 100+ manuaalisen testauksen opetusohjelmaa, joissa on testauksen määritelmä, tyypit, menetelmät ja prosessin yksityiskohdat:

Mitä on ohjelmistotestaus?

Ohjelmistotestaus on prosessi, jossa sovelluksen toiminnallisuus todennetaan ja kelpuutetaan, jotta saadaan selville, onko se määriteltyjen vaatimusten mukainen. Se on prosessi, jossa löydetään sovelluksen virheet ja tarkistetaan, missä sovellus toimii loppukäyttäjän vaatimusten mukaisesti.

Mitä on manuaalinen testaus?

Manuaalinen testaus on prosessi, jossa verrataan kehitetyn koodinpätkän (ohjelmiston, moduulin, API:n, ominaisuuden jne.) käyttäytymistä odotettuun käyttäytymiseen (vaatimuksiin).

Luettelo manuaalisen ohjelmistotestauksen opetusohjelmista

Tämä on syvällisin ohjelmistotestausta käsittelevä opetusohjelmien sarja. Käy läpi tässä sarjassa mainitut aiheet huolellisesti oppiaksesi testauksen perus- ja edistyneet tekniikat.

Tämä opetusohjelmasarja rikastuttaisi tietojasi ja parantaisi puolestaan testaustaitojasi.

Practice End-to-End Manual Testing Free Training on a Live Project:

Tutoriaali #1: Manuaalisen ohjelmistotestauksen perusteet
Tutoriaali #2: Live-projektin esittely
Tutoriaali #3: Testiskenaarioiden kirjoittaminen
Tutoriaali #4: Testisuunnitelmadokumentin kirjoittaminen alusta alkaen
Tutoriaali #5: Testaustapausten kirjoittaminen SRS-dokumentista
Tutoriaali #6: Testin suorittaminen
Opajakurssi #7: Vikojen seuranta ja testin allekirjoittaminen
Opajakurssi #8: Ohjelmistotestauksen kurssi

Ohjelmistotestauksen elinkaari:

Opajakurssi #1: STLC

Webtestaus:

Tutorial #1: Web Application Testing
Tutorial #2: Cross Browser Testing

Test Case Management:

Tutorial #1: Test Cases
Tutorial #2: Sample Test Case Template
Tutorial #3: Requirements Traceability Matrix (RTM)
Tutorial #4: Test Coverage
Tutorial #5: Test Data Management

Testien hallinta:

Ohje #1: Testausstrategia
Ohje #2: Testisuunnitelmamalli
Ohje #3: Testiarviointi
Ohje #4: Testinhallintatyökalut
Ohje #5: HP ALM opetusohjelma
Ohje #6: Jira
Tutorial #7: TestLink Tutorial

Testausmenetelmät:

Tutorial #1: Käyttötapaustestaus
Tutorial #2: Tilasiirtymätestaus
Tutorial #3: Raja-arvoanalyysi
Tutorial #4: Ekvivalenssijako
Tutorial #5: Ohjelmistotestausmetodologiat
Tutorial #6: Ketterät metodologiat

Virheiden hallinta:

Tutorial #1: Bug Life Cycle
Tutorial #2: Bug Reporting
Tutorial #3: Defect Priority
Tutorial #4: Bugzilla Tutorial

Functional Testing

Tutorial #1: Unit Testing
Tutorial #2: Sanity and Smoke Testing
Tutorial #3: Regression Testing
Tutorial #4: System Testing
Tutorial #5: Hyväksymistestaus
Tutorial #6: Integrointitestaus
Tutorial #7: UAT Käyttäjien hyväksymistestaus

Ei-toiminnallinen testaus:

Tutorial #1: Ei-toiminnallinen testaus
Tutorial #2: Suorituskykytestaus
Tutorial #3: Tietoturvatestaus
Tutorial #4: Verkkosovelluksen tietoturvatestaus
Tutorial #5: Käytettävyystestaus
Tutorial #6: Yhteensopivuuden testaus
Tutorial #7: Asennuksen testaus
Tutorial #8: Dokumentaation testaus

Ohjelmistotestauksen tyypit:

Tutorial #1: Testauksen tyypit
Tutorial #2: Mustalaatikkotestaus
Yleisopas #3: Tietokantatestaus
Yleisopas #4: End to end -testaus
Yleisopas #5: Tutkiva testaus
Yleisopas #6: Inkrementaalinen testaus
Yleisopas #7: Esteettömyystestaus
Tutorial #8: Negatiivinen testaus
Tutorial #9: Backend-testaus
Tutorial #10: Alpha-testaus
Tutorial #11: Beetatestaus
Tutorial #12: Alfa vs. beta-testaus
Tutorial #13: Gamma-testaus
Tutorial #14: ERP-testaus
Tutorial #15: Staattinen ja dynaaminen testaus
Tutorial #16: Adhoc-testaus
Tutorial #17: Lokalisointi- ja kansainvälistymistestaus
Ohje #18: Automaatiotestaus
Ohje #19: White box -testaus

Ohjelmistotestauksen ura:

Ohje #1: Ohjelmistotestauksen uran valinta
Ohje #2: Kuinka saada QA-testaustyö – Täydellinen opas
Ohje #3: Uravaihtoehdot testaajille
Ohje #4: Non-IT to Software Testing Switch
Tutorial #5: Kick Start Your Manual Testing Career
Tutorial #6: Lessons Learned from 10 Years in Testing
Tutorial #7: Survive and Progress in Testing Field

Interview Preparation:

Tutorial #1: QA Resume Preparation
Tutorial #2: Manuaalisen testauksen haastattelukysymykset
Tutorial #3: Automaatiotestauksen haastattelukysymykset
Tutorial #4: QA haastattelukysymykset
Tutorial #5: Käsittele mitä tahansa työpaikkahaastattelua
Tutorial #6: Hanki testaustyöpaikka vasta-alkajana

Testaus eri toimialueiden sovelluksissa:

Tutorial #1: Pankkisovellusten testaus
Tutorial #2: Terveydenhuoltosovellusten testaus
Tutorial #3: Payment Gateway Testing
Tutorial #4: Testaa myyntipisteen (POS) järjestelmää
Tutorial #5: Verkkokaupan verkkosivujen testaus

Testaus QA-sertifiointi:

Ohje #1: Ohjelmistotestauksen sertifiointiopas
Ohje #2: CSTE-sertifiointiopas
Ohje #3: CSQA-sertifiointiopas
Ohje #4: ISTQB-opas
Ohje #5: ISTQB edistynyt

Edistyneemmän manuaalisen testauksen aiheet:

Ohje #1: Syklomaattinen kompleksisuus
Tutoriaali #2: Migraatiotestaus
Tutoriaali #3: Pilvitestaus
Tutoriaali #4: ETL-testaus
Tutoriaali #5: Ohjelmistotestauksen mittarit
Tutoriaali #6: Verkkopalvelut

Valmistaudu katsomaan tämän manuaalisen testausta käsittelevän sarjan 1. opetusohjelma !!!!

Esittely manuaaliseen ohjelmistotestaukseen

Manuaalinen testaus on prosessi, jossa verrataan kehitetyn koodinpätkän (ohjelmiston, moduulin, API:n, ominaisuuden jne.) käyttäytymistä odotettuun käyttäytymiseen (Vaatimuksiin).

Ja mistä tiedät, mikä on odotettu käyttäytyminen?

Tietäisit sen lukemalla tai kuuntelemalla vaatimukset huolella ja ymmärtämällä ne täysin. Muista, että vaatimusten täydellinen ymmärtäminen on erittäin erittäin tärkeää.

Ajattele itsesi sen loppukäyttäjäksi, mitä aiot testata. Sen jälkeen et ole enää sidottu, ohjelmistovaatimusasiakirjaan tai siinä oleviin sanoihin. Silloin voit ymmärtää keskeisen vaatimuksen, etkä vain tarkista järjestelmän käyttäytymistä sen perusteella, mitä on kirjoitettu tai kerrottu, vaan myös oman ymmärryksesi perusteella ja sellaisten asioiden perusteella, joita ei ole kirjoitettu tai kerrottu.

Joskus voi olla vaatimus, jota ei ole otettu huomioon (epätäydellinen vaatimus) tai implisiittinen vaatimus (jokin asia, jota ei tarvitse mainita erikseen, mutta jonka pitäisi täyttyä), ja sinun on testattava tämäkin.

Myöskään vaatimuksen ei välttämättä tarvitse olla dokumentoitu. Sinulla voi hyvinkin olla tietoa ohjelmiston toiminnallisuudesta tai voit jopa arvailla ja testata sitten askel kerrallaan. Kutsumme sitä yleensä ad-hoc-testaukseksi tai eksploratiiviseksi testaukseksi.

Katsotaanpa asiaa tarkemmin:

Ymmärretään ensin se tosiasia – Verrataanpa testausta ohjelmistosovellukseen tai johonkin muuhun (vaikkapa ajoneuvoon), käsite pysyy samana. Lähestymistapa, työkalut ja prioriteetit saattavat vaihdella, mutta ydintavoite pysyy SAMANA ja se on SIMPLE eli todellisen käyttäytymisen vertaaminen odotettuun käyttäytymiseen.

Toiseksi – Testaus on kuin asenne tai ajattelutapa, jonka pitäisi tulla sisältäpäin. Taitoja voi oppia, mutta sinusta tulee menestyvä testaaja vain, kun sinulla on muutama ominaisuus sisälläsi oletusarvoisesti. Kun sanon, että testaustaitoja voi oppia, tarkoitan keskittynyttä ja muodollista koulutusta ohjelmistotestausprosessin ympärillä.

Mutta mitkä ovat menestyvän testaajan ominaisuuksia? Voit lukea niistä alla olevasta linkistä:

Lue se täältä =>Qualities of Highly Effective Testers

Suosittelen lämpimästi edellä mainitun artikkelin läpikäymistä ennen kuin jatkat tätä opetusta. Se auttaa sinua vertaamaan ominaisuuksiasi niihin ominaisuuksiin, joita odotetaan ohjelmistotestaajan roolissa.

Sille, joilla ei ole aikaa käydä artikkelia läpi, tässä tiivistelmä:

”Uteliaisuudellasi, tarkkaavaisuudellasi, kurinalaisuudellasi, loogisella ajattelukyvylläsi, intohimollasi työtä kohtaan ja kyvylläsi purkaa asioita on paljon väliä ollaksesi tuhoisan menestyksekäs testaaja. Se toimi minulle ja uskon vahvasti, että se toimii myös sinulle. Jos sinulla on jo näitä ominaisuuksia, niin todellakin sen on toimittava myös sinun kohdallasi.”

Olemme puhuneet ohjelmistotestaajaksi ryhtymisen keskeisistä ennakkoedellytyksistä. Nyt ymmärretään, miksi manuaalisella testauksella on ja tulee aina olemaan itsenäinen olemassaolonsa riippumatta siitä, onko automaatiotestaus kasvanut vai ei.

Miksi manuaalista testausta tarvitaan?

Tiedätkö, mikä on parasta testaajana, vieläpä manuaalisena testaajana, toimimisessa?

Se on se, että täällä ei voi luottaa vain taitoihin. Sinulla täytyy olla/kehittää ja parantaa ajatteluprosessiasi. Tätä ei todellakaan voi ostaa muutamalla dollarilla. Sinun on itse tehtävä töitä sen eteen.

Sinun on kehitettävä tapa kysyä kysymyksiä ja sinun on kysyttävä niitä joka minuutti, kun testaat. Useimmiten sinun pitäisi esittää nämä kysymykset pikemminkin itsellesi kuin muille.

Toivottavasti olet käynyt läpi artikkelin, jota suosittelin edellisessä osiossa (eli erittäin tehokkaiden testaajien ominaisuudet). Jos kyllä, niin silloin tietäisit, että testausta pidetään ajatusprosessina ja se, miten menestyt testaajana, riippuu täysin niistä ominaisuuksista, joita sinulla on ihmisenä.

Katsotaanpa tätä yksinkertaista kulkua:

• Tehdään jotakin (suoritetaan toimintoja) samalla, kun havainnoidaan sitä jollakin tarkoituksella (verrataan odotettuun). Nyt havainnointikykysi ja kurinalaisuutesi suorittaa asioita tulee tässä kuvaan.
• Voila! Mitä tuo oli? Huomasit jotain. Huomasit sen, koska kiinnitit täydellistä huomiota edessäsi oleviin yksityiskohtiin. Et anna sen mennä ohi, koska olet utelias. Tämä ei kuulunut suunnitelmaasi, että jotain odottamatonta/erikoista tapahtuu, huomaat sen ja tutkit sitä tarkemmin. Mutta nyt teette sen. Voitte päästää sen menemään. Mutta Sinun ei pitäisi antaa sen mennä.
• Olet onnellinen, sait selville syyn, vaiheet ja skenaarion. Nyt kerrot tästä kunnolla ja rakentavasti kehitystiimille ja muille tiimisi sidosryhmille. Saatat tehdä sen jonkin vikaseurantatyökalun avulla tai suullisesti, mutta sinun on varmistettava, että kommunikoit asiasta rakentavasti.
• Oops! Entä jos teen sen tuolla tavalla? Entä jos kirjoitan syötteeksi oikean kokonaisluvun, mutta johtavilla valkoisilla välilyönneillä? Mitä jos… …Mitä jos… …Mitä jos? Se ei lopu helposti, sen ei pitäisi loppua helposti. Kuvittelet paljon tilanteita & skenaarioita ja tosiaan sinua houkutellaan myös suorittamaan niitä.

Alla oleva kaavio kuvaa testaajan elämää:

Lue nuo neljä edellä mainittua kohtaa vielä kerran. Huomasitko, että pidin sen hyvin lyhyenä, mutta toin silti esiin rikkaimman osan manuaalisen testaajan työstä? Ja huomasitko lihavoidun korostuksen muutaman sanan kohdalla? Ne ovat juuri ne tärkeimmät ominaisuudet, joita manuaalinen testaaja tarvitsee.

Nyt, luuletko todella, että nämä teot voidaan korvata täysin millään muulla? Ja tämän päivän kuuma trendi – voiko sitä koskaan korvata automatisoinnilla?

SDLC:ssä millä tahansa kehitysmenetelmällä muutama asia pysyy aina vakiona. Testaajana kulutat vaatimukset, muunnat ne testiskenaarioiksi/testitapauksiksi. Sitten suoritat nuo testitapaukset tai automatisoit ne suoraan (tiedän, että muutamat yritykset tekevät niin).

Kun automatisoit, keskittymisesi on tasaista, eli kirjoitettujen vaiheiden automatisointi.

Palaamme takaisin muodolliseen osaan eli manuaalisesti kirjoitettujen testitapausten suorittamiseen.

Tässä keskitytään paitsi kirjoitettujen testitapausten suorittamiseen, myös suoritat paljon eksploratiivista testausta samalla. Muistatko, että olet utelias? Ja sinä kuvittelet. Etkä pysty vastustamaan, teet todellakin sen, mitä kuvittelit.

Alla oleva kuva kuvaa, miten testitapausten kirjoittamista yksinkertaistetaan:

Olen täyttämässä lomaketta, ja olen valmis ensimmäisen kentän täyttämiseen. Olen liian laiska hakemaan hiirtä siirtääkseni fokuksen seuraavaan kenttään. Painan ’tab’-näppäintä. Olen täyttänyt myös seuraavan ja viimeisen kentän, nyt minun täytyy klikata Lähetä-painiketta, fokus on edelleen viimeisessä kentässä.

Oops, painoin vahingossa ’Enter’-näppäintä. Tarkistan mitä tapahtui. TAI siellä on submit-painike, aion tuplaklikata sitä. En ole tyytyväinen. Napsautan sitä useita kertoja, liian nopeasti.

Oletko huomannut? Mahdollisia käyttäjän toimintoja on niin paljon, sekä tarkoituksellisia että ei-tarkoituksellisia.

Et onnistu kirjoittamaan kaikkia testitapauksia, jotka kattavat testattavan sovelluksesi 100-prosenttisesti. Tämän on tapahduttava tutkivalla tavalla.

Lisäät uusia testitapauksia sitä mukaa, kun testaat sovellusta. Nämä tulevat olemaan testitapauksia vikoja varten, joita olet kohdannut ja joita varten ei aiemmin ole kirjoitettu testitapauksia. Tai testauksen aikana jokin laukaisi ajatusprosessisi ja sait muutaman uuden testitapauksen, jotka haluat lisätä testitapaussarjaan ja suorittaa.

Kaiken tämän jälkeenkään ei ole mitään takeita siitä, ettei piilossa olevia vikoja ole. Ohjelmisto, jossa on nolla virhettä, on myytti. Voit vain pyrkiä viemään sen lähelle nollaa, mutta se ei vain voi tapahtua ilman, että ihmismieli pyrkii jatkuvasti samaan, samaan tapaan kuin edellä näkemämme esimerkkiprosessi, mutta ei pelkästään siihen rajoittuen.

Ainakaan tällä hetkellä ei ole olemassa ohjelmistoa, joka ajattelisi kuin ihmismieli, havainnoisi kuin ihmissilmä, kysyisi kysymyksiä ja vastaisi kuin ihminen ja sitten suorittaisi aiottuja ja ei-tahtotarkoituksenmukaisia toimia. Vaikka sellainen tapahtuisi, kenen mieltä, ajatuksia ja silmää se jäljittelee? Sinun vai minun? Me ihmiset emme myöskään ole samanlaisia oikeita. Olemme kaikki erilaisia. Sitten?

Tarvitaan manuaalista testausta, kun automaatio on olemassa:

Automaatiotestauksella on oma osuutensa loistosta näinä päivinä, ja sitä tulee olemaan vielä enemmän tulevina vuosina, mutta se ei yksinkertaisesti voi korvata manuaalista laadunvarmistustestausta (lue inhimillistä/eksploratiivista testausta).

Olet varmaan kuullut ennenkin, että – ”testausta ei automatisoida, vaan tarkistaminen automatisoidaan”. Tämä lause kertoo paljon siitä, missä tilanteessa manuaalinen QA-testaus on automaatiotestauksen myötä. Monet suuret nimet ympäri maailmaa ovat kirjoittaneet ja puhuneet tästä aiheesta, joten en aio korostaa tätä paljon.

Automaatio ei voi korvata inhimillistä testausta, koska:

• Se vaatii ajoaikaisia arvioita kaikesta siitä, mitä tapahtuu silmiesi edessä (testatessasi) ja muutamissa tapauksissa myös kulissien takana.
• Se vaatii selkeää ja jatkuvaa tarkkailua.
• Se vaatii kyseenalaistamista.
• Se vaatii tutkimista.
• Se vaatii päättelyä.
• Se vaatii suunnittelemattomia toimia tarpeen mukaan testauksen aikana.

Testauksen voi korvata työkalulla/koneella, joka pystyy omaksumaan yksityiskohdat, käsittelemään ne, käskemään toimia ja suorittamaan ne ihmismielen ja ihmisen tavoin, ja kaikki tämä ajoaikana ja kaikissa mahdollisissa yhteyksissä. Tämän työkalun on taas oltava samanlainen kuin kaikkien mahdollisten ihmisten.

Lyhyesti sanottuna, inhimillistä testausta ei voi korvata. Ehkä joku Hollywoodin scifi-leffa muutaman vuoden päästä näyttää läheltä sitä, mutta tosielämässä en näe sitä tulevan muutamaan sataan vuoteen, sen voin kuvitella. En kirjoita sitä ikuisiksi ajoiksi pois, koska uskon loputtomiin mahdollisuuksiin.

Erottelussa, vaikka se todella tapahtuisi muutaman sadan vuoden kuluttua, kuva jonka voin kuvitella on varmasti pelottava maailma. Transformereiden aikakausi. 🙂

=>> Suositeltavaa luettavaa – Parhaat manuaalisen testauksen palveluyritykset

Miten automaatio täydentää manuaalista testausta?

Totesin jo aiemmin ja sanon sen uudestaan, että automaatiota ei voi enää sivuuttaa. Maailmassa, jossa jatkuvasta integroinnista, jatkuvasta toimituksesta ja jatkuvasta käyttöönotosta on tulossa pakollisia asioita, jatkuva testaus ei voi istua toimettomana. Meidän on keksittävä keinoja, miten se tehdään.

Useimmiten yhä useamman työntekijän käyttöönotto ei pitkällä aikavälillä auta tässä tehtävässä. Näin ollen testaajan (testauspäällikön/arkkitehdin/johtajan) on päätettävä varovasti, mitä automatisoidaan ja mitä tehdään edelleen manuaalisesti.

On erittäin tärkeää, että testit/tarkastukset on kirjoitettu erittäin tarkasti, jotta ne voidaan automatisoida ilman poikkeamia alkuperäisistä odotuksista ja jotta niitä voidaan käyttää tuotteen regressioinnin yhteydessä osana ”jatkuvaa testausta”.

Huomautus: Termistä ’Jatkuva testaus’ löytyvään sanaan ’jatkuva’ kohdistuu samanlaisia ehdollisia ja loogisia kutsuja kuin muihin edellä käyttämiimme termeihin, joilla on sama etuliite. Jatkuva tarkoittaa tässä yhteydessä enemmän ja useammin, nopeammin kuin eilen. Merkitykseltään se voi hyvinkin tarkoittaa sekunnin tai nanosekunnin välein.

Jollei inhimillisiä testaajia ja automatisoituja testejä (testit, joissa on tarkat vaiheet, odotettu tulos ja kyseisen testin poistumiskriteerit dokumentoituna) soviteta täydellisesti yhteen, Jatkuvan testauksen saavuttaminen on hyvin vaikeaa, ja tämä puolestaan vaikeuttaa jatkuvaa integrointia (continuous integration), jatkuvaa toimitusta (continuous delivery) ja jatkuvaa käyttöönottoa (continuous deployment).

Käyttämäni termi ”testin poistumiskriteerit” on käytetty tarkoituksella edellä. Automaatiopukumme eivät voi enää olla samanlaisia kuin perinteiset. Meidän on varmistettava, että jos ne epäonnistuvat, niiden pitäisi epäonnistua nopeasti. Ja jotta ne epäonnistuvat nopeasti, myös poistumiskriteerit on automatisoitava.

Esimerkki:

Sanotaan, että on estävä vika, jossa en pysty kirjautumaan Facebookiin.

Login-toiminnallisuuden on tällöin oltava ensimmäinen automatisoitu tarkistus, eikä automaatiopakettisi saisi suorittaa seuraavaa tarkistusta, jossa kirjautuminen on ennakkoedellytys, kuten statuksen julkaiseminen. Tiedät hyvin, että se on pakko epäonnistua. Tee siitä siis nopeammin epäonnistuva ja julkaise tulokset nopeammin, jotta vika voidaan korjata nopeammin.

Seuraavaksi on taas jotain, minkä olet varmasti kuullut jo aiemmin – Kaikkea ei voi eikä pidä yrittää automatisoida.

Valitse sellaiset testitapaukset, jotka automatisoituina hyödyttävät huomattavasti ihmistestaajia ja joiden sijoitetun pääoman tuotto on hyvä. Tästä asiasta on olemassa yleinen sääntö, joka sanoo, että sinun pitäisi yrittää automatisoida kaikki prioriteetti 1 -testitapaukset ja jos mahdollista, sitten prioriteetti 2.

Automaatio ei ole helppo toteuttaa ja se on aikaa vievää, joten on suositeltavaa välttää matalan prioriteetin tapausten automatisointia ainakin siihen asti, kunnes olet saanut korkean prioriteetin tapaukset valmiiksi. Valitsemalla automatisoitavat asiat ja keskittymällä niihin parannetaan sovelluksen laatua, kun niitä käytetään ja ylläpidetään jatkuvasti.

Johtopäätös

Toivottavasti olet nyt ymmärtänyt, miksi ja miten paljon manuaalista/ihmisten tekemää testausta tarvitaan laadukkaiden tuotteiden tuottamiseen ja miten automaatio täydentää sitä.

Käsin tekemän testauksen merkityksen hyväksyminen ja tietäminen siitä, miksi manuaalinen testaaminen on erikoislaatuista, on ensimmäinen askel kohti erinomaista manuaalista testaajuutta.

Tulevissa manuaalisen testauksen opetusohjelmissamme käsittelemme yleistä lähestymistapaa manuaalisen testauksen tekemiseen, miten se toimii rinnakkain automaation kanssa ja monia muita tärkeitä näkökohtia.

Olen varma, että tulet saamaan valtavasti tietoa ohjelmistotestauksesta, kun käyt läpi koko luettelon tämän sarjan opetusohjelmista.

Varmasti tulet saamaan valtavasti tietoa ohjelmistotestauksesta, kun käyt läpi koko luettelon tämän sarjan opetusohjelmista.
Varmasti tulet saamaan valtavasti tietoa ohjelmistotestauksesta.