Top 20 Junior QA tehnilise intervjuu küsimust ja vastust
Selles artiklis vaatame tehnilisi küsimusi, mida küsitakse sageli Junior Manual QA intervjuudel. Need küsimused puudutavad QA põhiteooriat, testdokumentatsiooni, bug reporte, testimise tüüpe ja tasemeid, nõuetega töötamist, kontrollide prioritiseerimist ning tööriistu, millega algaja testija võib kokku puutuda.
Artikli eesmärk on aidata mõista mitte ainult küsimusi endid, vaid ka intervjueerija loogikat: miks konkreetset küsimust küsitakse, milliseid teadmisi soovitakse kontrollida ja kuidas vastata rahulikult, selgelt ning struktureeritult.
See materjal sobib neile, kes valmistuvad oma esimeseks QA intervjuuks ja soovivad korrata hard skills’e: testimise põhimõisteid, praktilisi QA ülesandeid ning tüüpilisi tööolukordi, millega junior-spetsialist võib projektis kokku puutuda.
Artikli eesmärk on aidata mõista mitte ainult küsimusi endid, vaid ka intervjueerija loogikat: miks konkreetset küsimust küsitakse, milliseid teadmisi soovitakse kontrollida ja kuidas vastata rahulikult, selgelt ning struktureeritult.
See materjal sobib neile, kes valmistuvad oma esimeseks QA intervjuuks ja soovivad korrata hard skills’e: testimise põhimõisteid, praktilisi QA ülesandeid ning tüüpilisi tööolukordi, millega junior-spetsialist võib projektis kokku puutuda.
1. Mis on tarkvara testimine ja kvaliteedi tagamine?
Miks seda küsimust küsitakse:
Intervjueerija soovib aru saada, kas kandidaat tunneb testimise ja QA ehk kvaliteedi tagamise põhimõisteid. Samuti kontrollitakse, kas kandidaat mõistab erinevust testimise ja laiema kvaliteediga seotud tööprotsessi vahel.
Millest vastuses rääkida:
Tarkvara testimine on toote kontrollimise protsess: kas see töötab korrektselt ning vastab nõuetele ja kasutaja ootustele.
QA ehk Quality Assurance on laiem protsess. See aitab tagada toote kvaliteeti arenduse erinevates etappides. QA hõlmab nõuetega töötamist, riskide tuvastamist, testdokumentatsiooni ettevalmistamist, testimist, bug reportide loomist ja suhtlust tiimiga.
Peamine erinevus on see, et testimine on osa QA protsessist. Testimine aitab toodet kontrollida ja probleeme leida, samal ajal kui QA aitab parandada nii toote kui ka arendusprotsessi kvaliteeti tervikuna.
2. Milline on QA inseneri roll arendustiimis?
Miks seda küsimust küsitakse:
Intervjueerija kontrollib, kas kandidaat mõistab, kuidas QA teeb koostööd arendajate, analüütikute, disainerite, product manager’ide ja teiste tiimiliikmetega.
Millest vastuses rääkida:
QA insener vastutab mitte ainult valmis funktsionaalsuse testimise eest, vaid aitab tiimil luua kvaliteetset toodet kogu arendusprotsessi jooksul. QA võib olla kaasatud juba nõuete analüüsi etapis: küsida täpsustavaid küsimusi, leida ebaselgeid kohti, vastuolusid või puuduvaid stsenaariume. See aitab ennetada vigu juba enne arenduse algust.
Arenduse ajal teeb QA tihedat koostööd arendajatega, kontrollib valmis funktsionaalsust, kirjeldab leitud defekte ja aitab probleeme reprodutseerida. QA suhtleb ka analüütikute ja manager’idega, et veenduda, et toode vastab nõuetele ja kasutajate ootustele.
QA peamine roll tiimis on vähendada riske, tuvastada probleeme võimalikult vara ja aidata parandada toote kvaliteeti. Hea QA mõtleb mitte ainult sellele, kas funktsioon töötab, vaid ka sellele, kas see on kasutajale mugav, kas loogika on selge, kas süsteemis võib olla varjatud probleeme ja kas lahendus vastab ärieesmärkidele.
Näidisvastus intervjuul:
QA aitab arendustiimis tagada toote kvaliteeti erinevates etappides. See ei tähenda ainult bugide leidmist pärast arendust, vaid ka osalemist nõuete aruteludes, ebaselgete kohtade täpsustamist, võimalike riskide analüüsimist ja valmis funktsionaalsuse kontrollimist. QA suhtleb arendajate, analüütikute ja manager’idega, aitab leida probleeme varem ning muudab toote stabiilsemaks ja kasutajasõbralikumaks.
3. Mis on bug?
Miks seda küsimust küsitakse:
Kontrollitakse kandidaadi põhiteadmisi QA terminoloogiast ja seda, kas kandidaat oskab lihtsate sõnadega selgitada, mida loetakse toote probleemiks.
Millest vastuses rääkida:
Bug on erinevus tegeliku tulemuse ja oodatud tulemuse, nõuete või süsteemi tavapärase käitumise vahel.
Näiteks kui nõuete järgi peaks vorm avanema pärast nupule vajutamist, kuid midagi ei juhtu, on see bug. Kui kasutaja sisestab õige kasutajanime ja parooli, kuid ei saa süsteemi sisse logida, on see samuti bug. Bug võib olla ka vale veatekst, vale arvutus, katkine disain, valideerimisprobleem või olukord, kus süsteem ei tööta nii, nagu kasutaja ootab.
Oluline on mõista, et QA ülesanne ei ole ainult bugi leidmine, vaid ka selle korrektne kirjeldamine. Hea bug report peab aitama arendajal probleemi kiiresti mõista ja reprodutseerida. Seetõttu peaks bug report tavaliselt sisaldama samme probleemi kordamiseks, oodatud tulemust, tegelikku tulemust, keskkonda ning vajadusel ekraanipilti, videot või logisid.
4. Mis vahe on severity’l ja priority’l?
Miks seda küsimust küsitakse:
Selle küsimusega kontrollitakse, kas kandidaat mõistab, et bugid võivad erineda nii mõju kui ka parandamise kiireloomulisuse poolest. Mitte iga tõsine bug ei pea alati kohe parandatud saama ning mitte iga kiire bug ei ole süsteemi jaoks kriitiline.
Millest vastuses rääkida:
Severity näitab bugi tõsidust ehk seda, kui tugevalt defekt mõjutab rakendust või süsteemi.
Näiteks:
High Severity — rakendus jookseb kokku, kasutaja ei saa teha peamist toimingut või oluline ärifunktsioon, näiteks maksmine või registreerimine, ei tööta.
Medium Severity — funktsioon üldiselt töötab, kuid loogikas, arvutustes, andmete kuvamises või mõnes stsenaariumis on viga.
Low Severity — väikesed visuaalsed probleemid, kirjavead, vale vahe elementide vahel või muud väiksemad UI-probleemid, mis ei takista kasutajal põhitoiminguid teha.
Priority näitab bugi parandamise kiireloomulisust ehk seda, kui kiiresti peaks tiim bugi parandama.
Näiteks:
High Priority — bug tuleb parandada võimalikult kiiresti, sest see on oluline ärile, release’ile või kasutajatele.
Medium Priority — bug tuleks parandada, kuid see ei blokeeri release’i ega süsteemi põhifunktsionaalsust.
Low Priority — bugi võib parandada hiljem, kui selleks on aega, sest selle mõju ei ole suur.
Oluline on mainida, et severity’t hindab tavaliselt QA, sest QA analüüsib bugi tehnilist mõju süsteemile. Priority määrab sagedamini manager, product owner või kogu tiim, sest see sõltub ärilisest olulisusest, release’i tähtaegadest ja hetkeprioriteetidest.
5. Milliseid testimise tasemeid sa tead?
Miks seda küsimust küsitakse:
Kontrollitakse, kas kandidaat mõistab testimise struktuuri ja seda, et toote kvaliteeti kontrollitakse erinevatel tasemetel. Oluline on näidata, et testimine ei alga ainult valmis kasutajaliidese kontrollimisest, vaid võib toimuda ka üksikute koodiosade, moodulitevahelise suhtluse ja kogu süsteemi tasemel.
Millest vastuses rääkida:
Ma tean peamisi testimise tasemeid: komponenttestimine, integratsioonitestimine, süsteemitestimine ja vastuvõtutestimine.
Komponenttestimine ehk unit testing tähendab süsteemi väikeste eraldiseisvate osade kontrollimist, näiteks funktsiooni, meetodi, klassi või komponendi testimist. Tavaliselt kirjutavad selliseid teste arendajad, et veenduda, et konkreetne osa töötab õigesti eraldi teistest süsteemi osadest.
Integratsioonitestimine kontrollib komponentide, moodulite või süsteemide omavahelist suhtlust. Näiteks saab kontrollida, kas frontend saadab päringu backend’i õigesti, backend töötleb andmed korrektselt ja tagastab vajaliku vastuse.
Süsteemitestimine tähendab kogu süsteemi testimist ühe tervikliku tootena. Sellel tasemel kontrollitakse, kuidas toode töötab tervikuna: peamisi kasutajastsenaariume, äriloogikat, vigu, UI-d, API-d ja muid olulisi süsteemi osi.
Vastuvõtutestimine kontrollib, kas toode vastab nõuetele ja on valmis kasutamiseks kasutajate või kliendi poolt. Siin on oluline veenduda, et loodud funktsionaalsus lahendab päriselt ärilise ülesande ja töötab ootuspäraselt.
Need tasemed aitavad kontrollida toote kvaliteeti järk-järgult: alates süsteemi väikestest osadest kuni valmis toote täieliku kontrollini.
6. Mis on test case?
Miks seda küsimust küsitakse:
Kontrollitakse teadmisi testdokumentatsiooni kohta.
Millest vastuses rääkida:
Test case on dokumenteeritud kirjeldus konkreetsest kontrollist. Tavaliselt sisaldab see testimise samme, testandmeid, eeltingimusi ja oodatud tulemust.
Test case aitab QA-l kontrollida funktsionaalsust järjepidevalt ja selgelt. Tänu test case’idele saab sama stsenaariumi mitu korda korrata ning ka teine tiimiliige saab kontrolli läbi viia ja täpselt aru, mida tuleb testida.
7. Mis on test report?
Miks seda küsimust küsitakse:
Kontrollitakse, kas kandidaat mõistab, et testimine ei tähenda ainult bugide leidmist, vaid ka töö tulemuste fikseerimist. Test report aitab tiimil aru saada, mida kontrolliti, millised probleemid leiti, kui valmis on toode release’iks ja kas on alles riske.
Millest vastuses rääkida:
Test report on raport testimise tulemustest. Selles näitab QA, millist funktsionaalsuse osa kontrolliti, millised testid tehti, millised läbisid kontrolli, millised ebaõnnestusid, millised bugid leiti ja milline on toote üldine seis hetkel.
Test report sisaldab tavaliselt infot selle kohta, mida testiti, millises keskkonnas, millise perioodi jooksul, mitu test case’i käivitati, mitu neist õnnestus, ebaõnnestus või oli blokeeritud. Raport võib sisaldada ka leitud defektide nimekirja, nende severity’t ja priority’t, linke bug reportidele ning lühikest ülevaadet peamistest riskidest.
Oluline on see, et test report ei ole vajalik ainult QA-le. Seda võivad lugeda ka arendajad, product owner, project manager või äripoole esindajad. Seetõttu peab raport olema selge, struktureeritud ja näitama ausalt toote kvaliteedi tegelikku olukorda.
8. Mida peaks sisaldama hea bug report?
Miks seda küsimust küsitakse:
Selle küsimusega kontrollitakse, kas kandidaat mõistab, kuidas leitud defekte õigesti kirjeldada. Tiimi jaoks on oluline, et bug report oleks selge, täielik ja aitaks arendajal probleemi kiiresti reprodutseerida ilma lisaküsimusteta.
Millest vastuses rääkida:
Hea bug report peab andma tiimile kogu vajaliku info probleemi kohta: mis juhtus, kus see juhtus, kuidas seda korrata ja milline tulemus oli oodatud. Tavaliselt peaks bug report sisaldama:
- Pealkiri / Summary — lühike ja selge probleemi kirjeldus.
- Steps to reproduce — konkreetsed sammud, mida tuleb teha, et bugi näha.
- Actual result — mis tegelikult juhtus.
- Expected result — mis oleks pidanud juhtuma nõuete või süsteemi loogika järgi.
- Environment — kus probleem leiti: brauser, seade, operatsioonisüsteem, rakenduse versioon, testkeskkond.
- Lisamaterjalid — ekraanipildid, videod, logid, lingid või testandmed, kui need aitavad probleemi kiiremini mõista või reprodutseerida.
Severity ja priority lisatakse sageli samuti bug reporti, kuid see sõltub tiimi protsessist.
9. Kuidas sa testiksid sisselogimisvormi?
Miks seda küsimust küsitakse:
Kontrollitakse, kas kandidaat oskab mõelda nagu testija: näha mitte ainult üht positiivset stsenaariumi, vaid ka erinevaid süsteemi käitumise variante. Oluline on näidata, et QA kontrollib funktsionaalsust, valideerimist, veateateid, kasutusmugavust ja põhilisi turvariske.
Millest vastuses rääkida:
Alustaksin positiivsest stsenaariumist: sisestaksin korrektse e-posti või kasutajanime ja õige parooli, vajutaksin “Log in” nuppu ning kontrolliksin, et kasutaja pääseb edukalt süsteemi.
Seejärel kontrolliksin negatiivseid stsenaariume: tühi e-posti väli, tühi parooliväli, mõlemad väljad tühjad, vale parool, olematu kasutaja, vale e-posti formaat, liiga lühike või liiga pikk parool. Samuti on oluline kontrollida, milliseid veateateid kasutajale näidatakse ja kas need on arusaadavad.
Eraldi kontrolliksin vormi elementide käitumist: kas “Log in” nupp on aktiivne, kas vormi saab saata Enter-klahviga, kas parooli näitmise/peitmise funktsioon töötab, kas väljad ei tühjene pärast viga ootamatult ning kas “Forgot password” link töötab korrektselt.
Pööraksin tähelepanu ka turvalisusele: parool peab olema peidetud ja veateade ei tohiks avaldada liiga palju infot, näiteks kas selline kasutaja eksisteerib. Kui süsteemis on piirang sisselogimiskatsete arvule, kontrolliksin ka seda.
Lisaks võiks vormi kontrollida erinevates seadmetes ja brauserites, et veenduda, et see kuvatakse ja töötab korrektselt.
10. Mida sa teeksid, kui testitava ülesande nõuded on puudulikud või ebaselged?
Miks seda küsimust küsitakse:
Kontrollitakse, kas kandidaat oskab töötada ebakindluse olukorras ega alusta testimist “juhuslikult”. Päris töös ei ole nõuded alati ideaalselt kirjeldatud: osa infot võib olla ülesandes, osa disainis ja osa analüütiku, arendaja või product owner’i käes. Oluline on näidata, et QA oskab detaile täpsustada, olemasolevat infot analüüsida ja riske vähendada.
Millest vastuses rääkida:
Kõigepealt uuriksin hoolikalt nõudeid, ülesannet, disaine, acceptance criteria’t ja seotud dokumentatsiooni. Kui pärast seda jäävad mõned kohad endiselt ebaselgeks, sõnastaksin konkreetsed küsimused ja pöörduksin analüütiku, product owner’i, arendaja või teise tiimiliikme poole.
Oluline ei ole lihtsalt öelda “nõuded on ebaselged”, vaid selgitada, mis täpselt on ebaselge: milline peaks olema oodatud käitumine, millised andmed on lubatud, milliseid veateateid tuleb kuvada ja mis peaks juhtuma edge case’ide puhul.
Kui vastust on vaja kiiresti, dokumenteeriksin oma eeldused ja kooskõlastaksin need tiimiga, et kõik mõistaksid, millise loogika järgi testimine toimub. Samuti tooksin välja riskid: näiteks selle, et puudulike nõuete tõttu võivad mõned stsenaariumid jääda katmata või süsteemi käitumine võib erineda sellest, mida äri ootab.
11. Mida sa teeksid, kui arendaja ei nõustu bugiga?
Miks seda küsimust küsitakse:
See küsimus kontrollib mitte ainult tehnilist arusaamist, vaid ka kandidaadi suhtlemisoskust. QA töös tuleb sageli ette olukordi, kus arendaja arvab, et tegemist ei ole bugiga, vaid oodatud käitumise, implementatsiooni detaili või mittepiisavalt olulise probleemiga. Intervjueerija soovib aru saada, kas kandidaat oskab vaieldavaid olukordi rahulikult arutada ja oma seisukohta argumentidega toetada.
Millest vastuses rääkida:
Kui arendaja ei nõustu bugiga, on oluline mitte vaielda emotsionaalselt, vaid arutada olukorda rahulikult ja toetuda faktidele. Kõigepealt tuleb veenduda, et bug on õigesti kirjeldatud: olemas on selged reprodutseerimise sammud, actual result, expected result, keskkond ning vajadusel ekraanipildid või video.
Seejärel tasub kontrollida nõudeid või muud dokumentatsiooni. Kui süsteemi käitumine on vastuolus nõuetega, saab QA seda arendajale näidata ja selgitada, miks ta peab olukorda bugiks. Kui nõuetes puudub täpne kirjeldus, on parem arutada küsimust analüütiku, product owner’i või manager’iga. Võib juhtuda, et tegemist ei ole tehnilise bugiga, vaid ebaselge nõude või product-küsimusega.
Oluline on meeles pidada, et QA eesmärk ei ole “tõestada, et arendaja eksib”, vaid aidata tiimil teha õige otsus toote ja kasutaja jaoks.
12. Kuidas sa otsustaksid, milliseid parandatud buge esimesena üle testida?
Miks seda küsimust küsitakse:
Kontrollitakse, kas kandidaat oskab prioritiseerida fixed bugide retestimist, eriti olukorras, kus release’ini on vähe aega.
Millest vastuses rääkida:
Kõigepealt tuleks üle testida bugid, millel on kõige suurem mõju kasutajale, ärile ja release’ile. Alustaksin kriitilistest ja blokeerivatest bugidest: näiteks kui rakendus jooksis kokku, kasutaja ei saanud sisse logida, maksta, registreeruda või teha mõnda peamist toimingut. Seejärel kontrolliksin high priority buge, eriti kui need on seotud oluliste ärifunktsioonide või läheneva release’iga.
Arvestaksin ka seda, kui palju kasutajaid probleem mõjutab, kui sageli bug reprodutseerus, millises toote osas bug leiti ja kui riskantne võis olla tehtud parandus.
13. Mida sa teeksid, kui enne release’i ei ole piisavalt aega kõike testida?
Miks seda küsimust küsitakse:
Selle küsimusega kontrollitakse, kas kandidaat mõistab päris projektide piiranguid. Praktikas ei ole QA-l alati piisavalt aega, et absoluutselt kõike kontrollida. Seetõttu on oluline osata prioritiseerida, hinnata riske ja tiimi olukorrast õigel ajal teavitada.
Millest vastuses rääkida:
Kui saan aru, et enne release’i ei ole piisavalt aega kõike testida, siis ma ei jätkaks lihtsalt vaikides testimist. Kõigepealt teavitaksin tiimi või manager’i, et aega ei ole piisavalt, ja selgitaksin, millised toote osad on juba kontrollitud, millised ei ole veel kontrollitud ning millised riskid jäävad alles.
Seejärel keskenduksin kõige olulisematele ja riskantsematele stsenaariumidele:
- Kriitiline funktsionaalsus — login, registreerimine, maksmine, tellimuse vormistamine, peamised äriprotsessid.
- Funktsionaalsus, mida enne release’i muudeti — sest uute bugide risk on seal suurem.
- Sageli kasutatavad kasutajastsenaariumid — see, mida kasutajad kõige rohkem kasutavad.
Kui on kahtlusi, täpsustaksin tiimiga, mida on kõige olulisem esimesena kontrollida. Pärast seda saab dokumenteerida, mida testiti, mida ei jõutud katta ja millised riskid jäävad enne release’i alles.
14. Milliseid praktilisi QA ülesandeid oled õppeprojektides või praktika ajal teinud?
Miks seda küsimust küsitakse:
Kontrollitakse, kui hästi kandidaat mõistab, mida ta juba praktiliselt teha oskab, isegi kui tal ei ole veel kommertskogemust.
Millest vastuses rääkida:
Tasub rääkida õppeprojektidest, kursuse ajal tehtud praktikast, rakenduste testimisest, testdokumentatsiooni kirjutamisest ja bugidega töötamisest.
Näidisvastus intervjuul:
Mul on praktiline kogemus, mille sain õpingute käigus. Testisin õpperakendusi, analüüsisin nõudeid, koostasin checklist’e ja test case’e, kirjeldasin buge ning õppisin defekte tiimile selgelt kirjeldama. Harjutasin ka erinevaid testimise tüüpe ja mõistan QA põhiprotsessi: alates ülesande analüüsist kuni tulemuse kontrollimise ja leitud probleemide dokumenteerimiseni.
Kui mul oleks praktika kogemus, räägiksin sellest, milliseid QA ülesandeid ma päriselt tegin. Näiteks töötasin nõuetega, koostasin checklist’e ja test case’e, testisin rakenduse funktsionaalsust, leidsin buge ja lõin bug reporte. Võisin osaleda ka parandatud defektide retestimises ja ebaselgete kohtade aruteludes. Selline praktika aitas mul paremini mõista päris testimisprotsessi, õppida toodet tähelepanelikumalt analüüsima ja leitud probleeme selgemalt kirjeldama.
15. Milliseid tööriistu oled QA insenerina kasutanud?
Miks seda küsimust küsitakse:
See küsimus aitab aru saada, kas kandidaadil on praktiline kokkupuude erialaga. Intervjueerija soovib näha, et kandidaat ei tunne ainult teooriat, vaid on kasutanud ka tööriistu, mida QA protsessides päriselt kasutatakse.
Millest vastuses rääkida:
Kasutasin erinevaid tööriistu sõltuvalt ülesandest. Ülesannete ja bugidega töötamiseks kasutasin YouTracki: see võimaldab jälgida ülesandeid, luua bug reporte ja kontrollida nende staatusi. API testimiseks kasutasin Postmani ja Swaggerit: Swaggeri kaudu uurisin API dokumentatsiooni ning Postmanis saatsin päringuid ja kontrollisin vastuseid, status code’e ja andmeid.
Mul oli kogemus ka Playwrightiga testautomaatikas, kus kirjutasin kontrolle kasutajastsenaariumidele brauseris. Andmebaasidega töötamiseks kasutasin SQL-i ja DBeaverit, näiteks selleks, et kontrollida, kas andmed salvestati tabelitesse korrektselt. Lisaks kasutasin Giti versioonihalduseks ja koodiga töötamiseks.
16. Mis on smoke testing?
Miks seda küsimust küsitakse:
Kontrollitakse, kas kandidaat mõistab, kuidas kiiresti hinnata toote või uue build’i põhistabiilsust enne sügavamat testimist. Junior QA jaoks on oluline mõista, et testimine ei alga alati kõigi stsenaariumide detailse kontrolliga. Mõnikord tuleb kõigepealt veenduda, et põhifunktsioonid üldse töötavad.
Millest vastuses rääkida:
Smoke testing on rakenduse kõige olulisemate funktsioonide kiire kontroll. Selle eesmärk on aru saada, kas edasine testimine saab jätkuda või kas build on liiga ebastabiilne.
Näiteks kui testime e-poodi, võib smoke testing sisaldada kontrolli, et veebileht avaneb, login töötab, tooteotsing töötab, toodet saab lisada ostukorvi ja tellimust saab vormistada. Kui selles etapis login ei tööta või veebileht ei avane, ei ole mõistlik kohe liikuda väiksemate stsenaariumide detailse testimise juurde.
Näidisvastus:
Smoke testing on toote põhifunktsioonide kiire baaskontroll. See aitab aru saada, kas build on stabiilne ja kas sügavam testimine saab jätkuda. Näiteks kontrolliksin, kas rakendus avaneb, kas login töötab, kas peamised lehed töötavad ja kas kõige olulisemad kasutajastsenaariumid toimivad.
17. Mis on regression testing?
Miks seda küsimust küsitakse:
Kontrollitakse, kas kandidaat mõistab, et pärast toote muudatusi tuleb kontrollida mitte ainult uut funktsionaalsust, vaid ka süsteemi olemasolevaid osi. Päris töös tekivad bugid sageli mitte ainult uues koodis, vaid ka vanas funktsionaalsuses, mis varem töötas korrektselt.
Millest vastuses rääkida:
Regression testing tähendab olemasoleva funktsionaalsuse uuesti kontrollimist pärast rakenduses tehtud muudatusi. Selle eesmärk on veenduda, et uued muudatused, bug fix’id või uuendused ei ole rikkunud seda, mis varem töötas.
Näiteks kui arendajad muutsid makselahenduse loogikat, peaks QA kontrollima mitte ainult uut maksestsenaariumi, vaid ka vanu stsenaariume: edukas makse, viga vale kaardiandmetega, makse tühistamine, tellimuse staatuse kuvamine ja muud seotud funktsioonid.
18. Mis vahe on functional ja non-functional testing’ul?
Miks seda küsimust küsitakse:
Kontrollitakse, kas kandidaat mõistab erinevaid testimise tüüpe ja erinevust funktsionaalsuse kontrollimise ning toote üldiste kvaliteediomaduste kontrollimise vahel.
Oluline on näidata, et testimine ei tähenda ainult küsimust “kas funktsioon töötab või ei tööta?”. Lisaks funktsionaalsetele nõuetele on tootel ka mittefunktsionaalsed nõuded: jõudlus, kasutusmugavus, turvalisus, stabiilsus, töökindlus ja arusaadavus kasutajale.
Millest vastuses rääkida:
Functional testing kontrollib, mida süsteem teeb. Teisisõnu kontrollitakse, kas funktsionaalsus vastab nõuetele.
Näiteks: kasutaja saab registreeruda, sisse logida, lisada toote ostukorvi, vormistada tellimuse ja muuta parooli.
Non-functional testing kontrollib, kuidas süsteem töötab. See tähendab toote omaduste hindamist: jõudlus, kasutusmugavus, turvalisus, stabiilsus, ühilduvus erinevate brauserite ja seadmetega.
Näiteks: kas leht laeb kiiresti, kas vormi on mugav kasutada, kas süsteem peab vastu suurele koormusele ja kas rakendus töötab korrektselt erinevates brauserites.
19. Mis on positive ja negative testing?
Miks seda küsimust küsitakse:
Kontrollitakse, kas kandidaat oskab mõelda mitte ainult ideaalse stsenaariumi peale, vaid ka olukordadele, kus kasutaja sisestab valed andmed või käitub ootamatult. QA jaoks on oluline kontrollida nii edukaid kui ka veastsenaariume.
Millest vastuses rääkida:
Positive testing tähendab süsteemi kontrollimist korrektsete andmete ja oodatud kasutajategevustega. Kontrollime, et rakendus töötab õigesti siis, kui kasutaja teeb kõike “nii nagu peab”.
Näiteks: kasutaja sisestab õige e-posti ja parooli ning logib edukalt sisse.
Negative testing tähendab süsteemi kontrollimist valede andmete või valede tegevustega. Kontrollime, kuidas rakendus käsitleb vigu ja kas kasutajale kuvatakse arusaadavad teated.
Näiteks: kasutaja jätab väljad tühjaks, sisestab vale parooli, kasutab vale e-posti formaati või proovib saata vormi vigaste andmetega.
20. Mis on API ja mida saab Postmaniga kontrollida?
Miks seda küsimust küsitakse:
Kontrollitakse, kas kandidaat mõistab API testimise põhiideed ja kas ta tunneb tööriistu, mida QA-s sageli kasutatakse. Isegi Junior Manual QA jaoks on kasulik mõista, et testida saab mitte ainult kasutajaliidese kaudu, vaid ka päringute tasemel kliendi ja serveri vahel.
Millest vastuses rääkida:
API on liides, mida backend pakub suhtluseks süsteemi teiste osade või väliste rakendustega. API kaudu saab frontend, mobiilirakendus või teine teenus saata backend’ile päringuid ja saada vajalikke andmeid või operatsiooni tulemuse.
Näiteks kui kasutaja vajutab kasutajaliideses nuppu, saadab frontend API päringu backend’ile. Backend töötleb päringu ja tagastab vastuse: andmed, operatsiooni staatuse või veateate.
Postman on tööriist, mis aitab saata API päringuid ja kontrollida serveri vastuseid. Sellega saab kontrollida endpoint’i, request method’it, status code’i, response body’t, andmeid, vigu ja süsteemi käitumist erinevate sisendandmetega.
Näiteks saab saata login-päringu ja kontrollida, et korrektsete andmetega tagastab server eduka staatuse ja token’i, kuid vale parooliga tagastab autoriseerimisvea.
Kuidas Tallinn Learning aitab ettevalmistusega?
Tallinn Learningus käsitletakse neid küsimusi põhjalikult nii kursuse enda kui ka karjääritoetuse mooduli raames. Õpilased õpivad mitte ainult QA teooriat, vaid ka päris olukordi, millega Junior QA võib tööl kokku puutuda: kuidas analüüsida nõudeid, kirjutada checklist’e ja test case’e, koostada bug reporte, töötada tööriistadega, suhelda tiimiga ja selgitada oma otsuseid.
Õpilased õpivad mitte lihtsalt valmis intervjuuvastuseid pähe õppima, vaid mõistma küsimuste loogikat: miks tööandja konkreetset küsimust küsib, mida ta tegelikult kuulda soovib ja kuidas õigesti näidata oma teadmisi, praktilist kogemust, motivatsiooni ja valmisolekut areneda.
Ettevalmistuse käigus arutavad õpilased tüüpilisi Junior QA intervjuuküsimusi, harjutavad vastuste sõnastamist ning räägivad oma õpikogemusest, praktikast, tiimitööst ja praktilistest ülesannetest. See aitab neil tunda end esimestel intervjuudel kindlamalt ning vastata rahulikult, selgelt ja struktureeritult.
Tallinn Learningus käsitletakse neid küsimusi põhjalikult karjääritoetuse mooduli osana. Õpilased õpivad vastuseid mitte pähe õppima, vaid mõistma küsimuste loogikat ja läbima oma esimesi QA intervjuusid enesekindlamalt.
Kokkuvõte
Junior Manual QA intervjuu muutub palju arusaadavamaks, kui kandidaat mõistab mitte ainult küsimusi endid, vaid ka nende eesmärki. Kui on selge, miks intervjueerija midagi küsib ja millist vastust ta ootab, muutub intervjuu vähem stressirohkeks.
Hea ettevalmistus aitab kandidaadil enesekindlamalt rääkida oma teadmistest, praktikast, tööriistadest, tiimitööst ja valmisolekust QA valdkonnas areneda.